Chat/Channel Block

[Captain Tankman]

You mean remote troll across the universe? :p

 

[wanzer]

I hear exploits and evil and scams
its outrageous, its prone to undesired consequences!

I LOVE IT
I WANT
drool Q.Q

 

[Valck]

This is a game though. Its so much easier for the game to give it to everyone in a set of sectors/systems based on the transmitter then to do a union of every antennae on every entity everywhere to test for reception. While cool, I think trying to determine array size is too much for each mode (tx or rx) and does not add that much in terms of game-play.

I agree with keeping it accessible, that does not mean we have to oversimplify things.

I think a somewhat realistic approach wouldn't hurt, the basic concept is easy enough to understand ("moar antenna = moar range, big antenna > small antenna"), and nobody expects you to memorize the formula or do the math in your head. It might even be considered educational...
If you want to know the gritty details, they can be made available in the antenna block's description, or on the wiki. Does everybody intuitively understand how power generation or weapon slaves/effects work without having to look it up at least once?
[doublepost=1476649960,1476648913][/doublepost]

Have to agree. Having spent time as a signals operative for a while back in the 90s I can fully appreciate wanting authenticity in the signal dynamics, but at a certain point we're either going to have to approximate with acceptance of compromise, or accept a pretty large server & coding load just for scanners and comms because simulating realism for those would involve simulating electromagnetism, materials conductivity and all the various forms of interference, shadows, wave harmonics, etc... where is the line drawn?

Absolutely. However comparing my suggestion with calani's, I'd say it's simpler to estimate or actually do the math in your head for my example ( which was sqrt(antenna_a*antenna_b) times some factor ) than calculating the fourth root of antenna_size^5, which is effectively what the deceptively simple looking antenna_size^1.25 boils down to. I'd definitely want a calculator for this.

 

[calani]

While I agree that I'd like to see more accurate and realistic physics in-game...

Absolutely. However comparing my suggestion with calani's, I'd say it's simpler to estimate or actually do the math in your head for my example ( which was sqrt(antenna_a*antenna_b) times some factor ) than calculating the fourth root of antenna_size^5, which is effectively what the deceptively simple looking antenna_size^1.25 boils down to. I'd definitely want a calculator for this.

... basing the ability to receive a signal on the size of both antennas requires loading all ships/stations within the sending antenna's maximum range to query their antenna size, instead of simply sending a message to all entities in range.

(Also, performing a decimal exponent is relatively quick, likely taking only a few clock cycles. The increase in effort between calculating d^0.5 and d^1.25 is fairly negligible.)

Furthermore: when using this two-antenna method, a larger antenna much further out can also receive this antenna's weaker signal, meaning you realistically have to check every single antenna in the universe. Even if you have a convenient list of all antennas with their sizes and locations, you would still need to do distance calcs (and/or other operations) on every single one of them.

A simple radial check, while definitely expensive, is considerably less expensive than this two-antenna method.

 

[Valck]

... basing the ability to receive a signal on the size of both antennas requires loading all ships/stations within the sending antenna's maximum range to query their antenna size, instead of simply sending a message to all entities in range.

I don't think so, wireless logic isn't transmitted to unloaded entities, why would chat messages be?

(Also, performing a decimal exponent is relatively quick, likely taking only a few clock cycles. The increase in effort between calculating d^0.5 and d^1.25 is fairly negligible.)

Furthermore: when using this two-antenna method, a larger antenna much further out can also receive this antenna's weaker signal, meaning you realistically have to check every single antenna in the universe. Even if you have a convenient list of all antennas with their sizes and locations, you would still need to do distance calcs (and/or other operations) on every single one of them.

A simple radial check, while definitely expensive, is considerably less expensive than this two-antenna method.

You still have to do range checks on every potential (ie. loaded) receiver in the universe, even if you only consider one antenna.

Regarding calculative effort, I was referring to doing the math outside the game, either exactly or as a rough estimate. Whether you do it in your head or with a pocket calculator (... app) doesn't matter. I still think that sqrt(x) is easier to guesstimate than x^1.25...

For the in-game calculations, I don't see a significant difference between (a*b)^0.5 and a^1.25, an additional multiplication seems like a small price to pay for physics that approach realism. Furthermore the results can be cached at least until a sector change occurs, and even then you can check if you actually changed systems before you need to recalculate.

 

[calani]

wireless logic isn't transmitted to unloaded entities, why would chat messages be?

Correct; i wasn't thinking.

You still have to do range checks on every potential (ie. loaded) receiver in the universe, even if you only consider one antenna.

Why?
Say your antenna is at (0,0,0) and has length 15, thereby a maximum range of 15^1.25, or 29.519 systems (29 when floored). Why would you need to check past 30 systems? or the current galaxy? For range 2, why would you need to look farther away than a 3x3x3 area?

An example solution:
You can drastically reduce the lookup expense by breaking the universe into groups, and keeping track of which group an entity belongs to, and only considering those within range. Shuffling entites between groups would add fairly minimal overhead during sector changes. By expanding this to using groups of groups, you can increase the efficiency of larger lookups as well.

Every n sectors is a group, every n groups is a larger group, every n larger groups is another (up to e.g. a galaxy). When doing a radial search, you determine the group size that can best encompass the full area, and iterate over those. This limits the overhead to the cost of iterating over the actual lookup area plus whatever overshoot. Additionally, if you only look for loaded entities within those sectors, it reduces the cost yet further. There are more complex optimizations (i.e. circle-within-square) that reduce this even more, but likely not all would prove beneficial for this usecase.


tl;dr version:
Optimizing radial searches reduces their expense to usable levels and adds only minimal overhead.

 

[MacThule]

An example solution:
You can drastically reduce the lookup expense by breaking the universe into groups, and keeping track of which group an entity belongs to, and only considering those within range. Shuffling entites between groups would add fairly minimal overhead during sector changes. By expanding this to using groups of groups, you can increase the efficiency of larger lookups as well.

Every n sectors is a group, every n groups is a larger group, every n larger groups is another (up to e.g. a galaxy). When doing a radial search, you determine the group size that can best encompass the full area, and iterate over those. This limits the overhead to the cost of iterating over the actual lookup area plus whatever overshoot. Additionally, if you only look for loaded entities within those sectors, it reduces the cost yet further. There are more complex optimizations (i.e. circle-within-square) that reduce this even more, but likely not all would prove beneficial for this usecase.

This kind of indexing sounds like chunking the sectors the same way we chunk the voxels in 32x32x32 cubes. Pretty optimal, except... any idea of anything adding even a fractional weight to sector loads makes me wince - the jarring micro-lags between every sector are already disruptive and disorienting. Personally. I'd be willing to bend over backwards for every fraction of a second shaved off of sector transitions and would submit myself to watching an entire election speech if it meant an end to the little de-orientations from sector to sector.

Valck your equation is simpler. I think my hesitance arises not from the mathematical load the formula is creating, but the fact that making reception a function of the systems of 2 entities instead of one seems like it inevitably requires performing additional checks beyond that formula. Instead of simply checking each entity to determine the footprint of their transmission, both entities must be consulted and compared, then the results of the formula evaluated before even determining if the entities are in contact. Unless all loaded entities are being checked against all other loaded entities every cycle [ ]I'm not sure how this could function with only the formula you mention. I could be missing something, a way that one simple formula could be executed alone to determine reception of entities across an entire busy MP server, but if so you'll have to guide me to it.

 

[Valck]

You still have to do range checks on every potential (ie. loaded) receiver in the universe, even if you only consider one antenna.

Why?
Say your antenna is at (0,0,0) and has length 15, thereby a maximum range of 15^1.25, or 29.519 systems (29 when floored). Why would you need to check past 30 systems? or the current galaxy? For range 2, why would you need to look farther away than a 3x3x3 area?

Correct; guess I wasn't thinking either.

tl;dr version:
Optimizing radial searches reduces their expense to usable levels and adds only minimal overhead.

I don't argue that a simple radial search is faster, I argue that it may be worth experimenting with it while the game is in alpha; if the performance hit is untenable, it shouldn't be too much effort to go to the scaled-down model. Maybe it could even be an option for say smaller community servers with few concurrent users and NASA's server farms with lots of processing power... everything inbetween could use the simplified model as they see fit.
[doublepost=1476705453,1476705219][/doublepost]Also these checks (whichever ones get used) may be predestined to parallelize; chat usually isn't that time critical and could well run asynchronously.

 

[nightrune]

Correct; guess I wasn't thinking either.


I don't argue that a simple radial search is faster, I argue that it may be worth experimenting with it while the game is in alpha; if the performance hit is untenable, it shouldn't be too much effort to go to the scaled-down model. Maybe it could even be an option for say smaller community servers with few concurrent users and NASA's server farms with lots of processing power... everything inbetween could use the simplified model as they see fit.
[doublepost=1476705453,1476705219][/doublepost]Also these checks (whichever ones get used) may be predestined to parallelize; chat usually isn't that time critical and could well run asynchronously.

The basic way I imagined it without irc as a backer was a FIFO per each channel per sector, On transmit, You do the radial search as calani suggested and just push the message on to each FIFO, when you receive you grab the last message in your sector. This makes it very cheap and scalaeble. There would even be options for range that if you had a long enough range it would only search systems and post them there.

In your model it gets really complicated to figure out the last message to get when you need to do unions on two sets constantly. Even if you took my model of transmission. Then you could possibly have ~n^3 messages to sift through on receive. The number of checks balloons quite quickly.

I think it would be really cool but I don't have faith that its feasible for what people would use it for. As a side note this model also lets you shard at the sector level later on (a personal goal of mine for starmade) but have been told that's probably not going to happen.

 

[Valck]

The basic way I imagined it without irc as a backer was a FIFO per each channel per sector, On transmit, You do the radial search as calani suggested and just push the message on to each FIFO, when you receive you grab the last message in your sector. This makes it very cheap and scalaeble. There would even be options for range that if you had a long enough range it would only search systems and post them there.

In your model it gets really complicated to figure out the last message to get when you need to do unions on two sets constantly. Even if you took my model of transmission. Then you could possibly have ~n^3 messages to sift through on receive. The number of checks balloons quite quickly.

I think it would be really cool but I don't have faith that its feasible for what people would use it for. As a side note this model also lets you shard at the sector level later on (a personal goal of mine for starmade) but have been told that's probably not going to happen.

I like the idea of FIFOs, would one per ship/entity work, instead of per system? You check the range, and if OK, queue the message for the receiver. Prefix a channel tag, and you're good to go.

 

[nightrune]

I like the idea of FIFOs, would one per ship/entity work, instead of per system? You check the range, and if OK, queue the message for the receiver. Prefix a channel tag, and you're good to go.

As far as implementation goes I'm not sure. I feel like that might be unnecessary memory duplication since most of this would be server side anyway. Both may be valid. If/when they do this schema would decide anyway :D


As far as gameplay goes you might want a feature to test for unused channels as well. I've also wondered about having scanners find used channels public channels and also note whether or not there is faction activity as well.

 

[nightrune]

Anyone else have ideas on scanning channels?

 

[Lukwan]

First. (Firstly is not a word) I think this could be realized with a single antenna for transceiver. I do like the size/range scaling though.

Second. Don't most large vessels have a full time Comm-Officer? I like the idea of some basic functionality that a lone captain could get some use of, but additionally, this is begging for a dedicated 'station' for the Communications or Tactical Officer to sit at. Schine likes things block-based so I am imagining a 'switchboard' of linked Comm-channel blocks that have to be operated manually. The Tactical station could combine the roles of communications, scanning, and defensive ECM & ECCM.

 

[Madman198237]

Vessels meant for spying would have a EW/ECM officer, responsible for communication interceptions, tracking, decoding (Or, rather, his subordinates on a large vessel), and everything in between. On a small, stealthy spy vessel meant to monitor comms traffic, messages would be retransmitted and decoded elsewhere. Anyway, Lukwan, you're right. Only a vessel with a dedicated system for intercepting and decoding messages (Including dedicated crew members) could get anything out of the system, since a lone pilot should be worried about a lot of things (Distraction and lack of time dedicated to communications).

A capital warship should be able to simultaneously fight, maneuver, intercept, decode, jam, launch vessels, recover vessels, initiate boarding actions, and make the admiral a cup of tea, because it's got enough crew to do so. A two-man gunship? Forget it.

 

[ScorpionInc]

Links:

Link #1:

Chat/Channel Block​

Link #2:

'Local' chat channel​

Link #3 -> Link #5

Alliance Chat
Alliance Chat
http://star-made.org/content/new-alliance-chat-function​

Header:

Before I start I apologize as this is rather long-winded. I was unsure if this should be it's own thread as it related more to Link #2's Idea with more of a Link #1's approach, but I decided to post it here as most all referenced threads are rather old. If this is incorrect please let me know so that I may correct it when next I login (Not often sorry 0.0).​

Suggestion:

Well the suggestion I had for the implementation communication blocks was quite similar to Link #1 and several from Link #2. The connecting of logic based upon input from a chat block should null and void so long as the chat has the option to be public. This would require each block to monitor all chat on it's channel to determine if it should fire, using server resources. While it may be useful for long range control of blocks it would only work if either both sectors were loaded anyway or the server was instructed to simulate the sectors in question, which again would require more resources once many players started implementing it (especially if it's on a clock cycle).​

The blocks should not be able to communicate on the global channel and only on one channel at a time to reduce the IRC server workload and prevent spam messages. I liked the Idea of having a message forwarding ability however this should be limited in the amount of blocks that can send information to the same sector at once, this is to prevent popular block channels from becoming too flooded with information that it's just going to be repeated anyway. However doing so is generally pointless as the amount of time and resources wouldn't be worth it when instant communication with anyone is available regardless of distance (while not very realistic as even radio waves are limited to the speed of light).​

I'd suggest having a Short-Range Radio Block with using a predefined channel name scheme based upon the sector the block currently occupies at the time of broadcast regardless of the entity hosting it, E.G. '#2,2,2Local'. The block should affix a server configurable prefix to any message sent to inform players that this is an automated response, E.G. '[AUTO]: '. The block should only transmit in the sector's local channel while the sector/block is loaded by a player to prevent the server from having to broadcast automated messages in a sector where no one can hear it. I agree with OP Link #1 with the rate limit for broadcast frequency. All of this however would only be worth implementing if upon entering a new sector player's were automatically (configurable by player(?)) joined to the local broadcast channel while maintaining their other channels.​

(Kinda of topic how is it Link #3 -> Link #5 isn't a thing yet I love it. The only time the members who would be auto-joined to the channel would change is when a member or faction changes relations. I wonder if it should consider faction's personal enemies... Sorry off topic). Back to the point of logic, anything that can be logically controlled locally, can be achieved via wireless logical blocks anyway so again the radio block should be output only. In regards to the concept of controlling ships remotely from across the galaxy, which can already be done via fleet commands (Still not quite realistic but useful) which allows certain commands without having to load in the sector/ship to determine the logic blocks that are to be ran, I will grant that they are limited in commands but it would put to much strain on the server to simulate every ship that could have blocks to monitor the channel and simulate the affected logic blocks.​

In regards to encrypted/protected communications locally I don't believe that it would be worth it. Logically if you can communicate with anyone at any distance so attuning to a specific sector channel regardless of distance should be well within the abilities of your laws-of-physics-breaking radio. Encrypting (with the arguable possibility of a stream-based cypher) would produce additional work for a server(and all the fun new errors that can come with encryption) that is not needed. When communicating something that should be secured it should be sent via a P.M. hence the 'P' (Mentioned previously by another forum member). As far as espionage goes and hacking into someone else s remote systems, I'd recommend adding that to functionality to wireless logical modules as that wouldn't require the server to load previously unloaded sectors to use said logic with the modules being in range. Perhaps slave a display or a hacking computer with modules?​

P.S. In regards to Link #2 Post on determining galaxies based upon sector position for use in a galaxy chat don't they maintain an average distance from each other with a similar number of void sectors between the two? While allowing a certain leeway in regards to middle void sectors I'd think you would only need a modulus operation to calculate it correctly for most players. E.G. 12 % Galaxy size, 2 % galaxy size, ect. Although some phanagaling of the negative values may be in order.​

Conclusion:

Thank you for your time. ​

 

[nightrune]

Links:

Link #1:

Chat/Channel Block​

Link #2:

'Local' chat channel​

Link #3 -> Link #5

Alliance Chat
Alliance Chat
http://star-made.org/content/new-alliance-chat-function​

Header:

Before I start I apologize as this is rather long-winded. I was unsure if this should be it's own thread as it related more to Link #2's Idea with more of a Link #1's approach, but I decided to post it here as most all referenced threads are rather old. If this is incorrect please let me know so that I may correct it when next I login (Not often sorry 0.0).​

Suggestion:

Well the suggestion I had for the implementation communication blocks was quite similar to Link #1 and several from Link #2. The connecting of logic based upon input from a chat block should null and void so long as the chat has the option to be public. This would require each block to monitor all chat on it's channel to determine if it should fire, using server resources. While it may be useful for long range control of blocks it would only work if either both sectors were loaded anyway or the server was instructed to simulate the sectors in question, which again would require more resources once many players started implementing it (especially if it's on a clock cycle).​

The blocks should not be able to communicate on the global channel and only on one channel at a time to reduce the IRC server workload and prevent spam messages. I liked the Idea of having a message forwarding ability however this should be limited in the amount of blocks that can send information to the same sector at once, this is to prevent popular block channels from becoming too flooded with information that it's just going to be repeated anyway. However doing so is generally pointless as the amount of time and resources wouldn't be worth it when instant communication with anyone is available regardless of distance (while not very realistic as even radio waves are limited to the speed of light).​

I'd suggest having a Short-Range Radio Block with using a predefined channel name scheme based upon the sector the block currently occupies at the time of broadcast regardless of the entity hosting it, E.G. '#2,2,2Local'. The block should affix a server configurable prefix to any message sent to inform players that this is an automated response, E.G. '[AUTO]: '. The block should only transmit in the sector's local channel while the sector/block is loaded by a player to prevent the server from having to broadcast automated messages in a sector where no one can hear it. I agree with OP Link #1 with the rate limit for broadcast frequency. All of this however would only be worth implementing if upon entering a new sector player's were automatically (configurable by player(?)) joined to the local broadcast channel while maintaining their other channels.​

(Kinda of topic how is it Link #3 -> Link #5 isn't a thing yet I love it. The only time the members who would be auto-joined to the channel would change is when a member or faction changes relations. I wonder if it should consider faction's personal enemies... Sorry off topic). Back to the point of logic, anything that can be logically controlled locally, can be achieved via wireless logical blocks anyway so again the radio block should be output only. In regards to the concept of controlling ships remotely from across the galaxy, which can already be done via fleet commands (Still not quite realistic but useful) which allows certain commands without having to load in the sector/ship to determine the logic blocks that are to be ran, I will grant that they are limited in commands but it would put to much strain on the server to simulate every ship that could have blocks to monitor the channel and simulate the affected logic blocks.​

In regards to encrypted/protected communications locally I don't believe that it would be worth it. Logically if you can communicate with anyone at any distance so attuning to a specific sector channel regardless of distance should be well within the abilities of your laws-of-physics-breaking radio. Encrypting (with the arguable possibility of a stream-based cypher) would produce additional work for a server(and all the fun new errors that can come with encryption) that is not needed. When communicating something that should be secured it should be sent via a P.M. hence the 'P' (Mentioned previously by another forum member). As far as espionage goes and hacking into someone else s remote systems, I'd recommend adding that to functionality to wireless logical modules as that wouldn't require the server to load previously unloaded sectors to use said logic with the modules being in range. Perhaps slave a display or a hacking computer with modules?​

P.S. In regards to Link #2 Post on determining galaxies based upon sector position for use in a galaxy chat don't they maintain an average distance from each other with a similar number of void sectors between the two? While allowing a certain leeway in regards to middle void sectors I'd think you would only need a modulus operation to calculate it correctly for most players. E.G. 12 % Galaxy size, 2 % galaxy size, ect. Although some phanagaling of the negative values may be in order.​

Conclusion:

Thank you for your time. ​

Hello wall of text. I'm thinking this should be in its own thread. In your idea I think there are too many limitations. When it comes to server resources needed an input delay I think is sufficient and will be fine for the server. There would be little effect on performance especially if a player wasn't reading a channel you could keep it to 255 bytes for each message per channel. Basically only keeping the last message sent, and even time that one out depending on what kinda of game play you'd want. In keeping with immersion I'd actually like to have both from chat, and display block. I think they are both useful.

In reference to [AUTO] I think it should be left up to players and be come part of the game. Let them figure out if its automated or if you want to be nice let someone else know that it would be automated. This is the players choice and it matters. I like that.

I've never mentioned having sectors unloaded for this to work but fleets could interact with it if they so desired in an unloaded context.

The encryption is a side note and I think a fun one for factions to start running.

Radio blocks have been suggested and shot down for several reasons.
1) Its pretty easy to stand up your own voice chat outside the game and circumvent it. Something you could never enforce even if you wanted to.
2) Its particularly hard to do in game voice chat well, and its been solved in other areas. This puts it in the Nice to have but hard to implement category. Something a small team usually doesn't start to deal with unless its central to gameplay. Which I would argue is not in starmade.

As for a specific local broadcast channel, Nah, I would just leave it up to the players to figure that out between themselves. It creates cool silos of communication that can be used or listened or setup different. It also allows a cat and mouse game in a war of trying to find channels and constantly moving around or trying to hijack someones channel.

 

[PainNigouto]

Potentially exploitable in sold ships.

this is a good thing, like the RP variant of selling a ship with a virus, making it easy to hack by the ones who sold it

 

[calani]

this is a good thing, like the RP variant of selling a ship with a virus, making it easy to hack by the ones who sold it

Not disagreeing. Caveat emptor, and all ~