space-station-14 Add a crew monitoring server

Add a crew monitoring server

Open juliangiebel opened this issue 2 years ago • 13 comments

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.

Apr 13 '22 21:04 juliangiebel

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

Edit: diff updated after 45bc7cd2e4efb501b0575f53070b05df7f869129

Apr 13 '22 21:04 github-actions[bot]

Does this work when multiple stations are loaded.

Apr 14 '22 00:04 moonheart08

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.

Apr 14 '22 05:04 juliangiebel

I assume the ultimate goal would be distance based from server but i don't think that is cheap to process currently.

Apr 14 '22 06:04 Fishfish458

would there be a way to tie crew to the station grid they join in on

Apr 14 '22 06:04 Emisse

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.

Apr 14 '22 07:04 Macoron

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.

Apr 14 '22 07:04 juliangiebel

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.

Apr 14 '22 07:04 juliangiebel

This is ready for review

Apr 15 '22 10:04 juliangiebel

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.

Aug 07 '22 09:08 juliangiebel