space-station-14
space-station-14 copied to clipboard
Add a crew monitoring server
About the PR
- Adds crew monitoring servers
- Only one is active at a time. If the one that is currently active loses power or gets removed / destroyed another available server will take over
- Changes suit sensors to not broadcast anymore
- Adds a random offset to each suit sensors update time
Suit sensors don't just broadcast their status anymore! Instead they retrieve the currently active crew monitoring servers address from the crew monitoring system and send their status directly to that server.
That server is then periodically broadcasting the status of all "connected" suit sensors in one packet on a different frequency.
So we went from a huge amount of broadcasting devices to just one.
Changelog
:cl:
- add: The crew monitoring server. It relays the status of suit sensors to crew monitors.
RSI Diff Bot; head commit 45bc7cd2e4efb501b0575f53070b05df7f869129 merging into cf509c1e385f6ddf24be3ed8a583d441b87ae63a This PR makes changes to 1 or more RSIs. Here is a summary of all changes:
Resources/Textures/Structures/Machines/server.rsi
State | Old | New | Status |
---|---|---|---|
variant-crew | ![]() |
Added |
Does this work when multiple stations are loaded.
It doesn't break but you still see all crew members regardles of what station they are on.
I could restrict all of the monitoring equipment to only send and receive only for the grid they are on and have one active server per grid. I would only need to figure out how to make sure suit sensors work of station too. A frequency offset might work but that will break with to many stations.
I assume the ultimate goal would be distance based from server but i don't think that is cheap to process currently.
would there be a way to tie crew to the station grid they join in on
I understand this solution for performance reasons, but have some feedback gameplay-wise:
- When you leave 500 tiles range from a server, your suit sensor won't work. And even if you build another one on your grid it won't help, because all crew monitorings are connected to one world server. So if you have two stations with 500 tiles distance between them - one station won't be able to use their crew monitoring devices.
- There is no way to build a server. You probably need construction graph and circuit.
- Mappers should map it asap after this PR merge.
- Crew monitoring devices should show something like "Can't connect to the server..." in UI when they can't hear from the server for a long time
Heresy idea: Maybe don't use device net for suit sensors and replace them just by C# function call? C# function calls should be much cheaper than packet serialize/deserialize +raising events.
I understand this solution for performance reasons, but have some feedback gameplay-wise:
When you leave 500 tiles range from a server, your suit sensor won't work. And even if you build another one on your grid it won't help, because all crew monitorings are connected to one world server. So if you have two stations with 500 tiles distance between them - one station won't be able to use their crew monitoring devices.
There is no way to build a server. You probably need construction graph and circuit.
Mappers should map it asap after this PR merge.
Crew monitoring devices should show something like "Can't connect to the server..." in UI when they can't hear from the server for a long time
Heresy idea: Maybe don't use device net for suit sensors and replace them just by C# function call? C# function calls should be much cheaper than packet serialize/deserialize +raising events.
I'll make this one server per station/grid. Having a range makes some sense then but I should propably increase the range.
I forgot to add construction. I will add construction and the "Can't connect to the server.." text after I get back from work today.
packet serialize/deserialize
It's not serialization. You don't even need to split your data into seperate fields in the packets payload, you can just slab your data in as is. (Look at how CrewMonitoringServerSystem.cs) does it. It's just that if it's not a primitive type or it doesn't have some custom logic players won't be able to see the contents of that field.
In the case of suit sensors it's about reusable code. If I write a check for what station the sender and receiver is on you can use it for other devices too instead of having that in the entity system of each of the monitoring devices.
The suit sensor code for creating a device net packet is a bit missleading tbh. Especially with it calling the process serialization/deserialization.
I can even give crew monitoring it's own device net id so incrementing the frequency for each new station would be possible instad of a check if receiver and sender are on the same grid. At that point I can also change the code that creates the suit sensors packet to just put the data in one field as players will be unnable to see that packet anyway.
This is ready for review
I addressed the reviews and made it use station system. Now there can be one active server per station and the suit sensors get assigned to a station on component init.
This pull request has conflicts, please resolve those before we can evaluate the pull request.
This pull request has conflicts, please resolve those before we can evaluate the pull request.
This pull request has conflicts, please resolve those before we can evaluate the pull request.
This is ready to be merged again
This pull request has conflicts, please resolve those before we can evaluate the pull request.
I finally got around to fixing up this PR.
This pull request has conflicts, please resolve those before we can evaluate the pull request.
@mirrorcult I implemented your suggestions