When a player controls a VehicleSeat, a large amount of data is sent to the server just from input changes. This quickly becomes the main source of network traffic in my project, on par with the amount of data used to replicate multiple active cars in my vehicle replication system. This effectively more than halves the game’s network budget and therefore the total player count per server.
An easy way to replicate this is to simply create a Baseplate with a VehicleSeat, sit on it then mess with wasd with the Ctrl Shift F3 menu open, observing the Out Data values. It currently ranges 4–6 kbps, maybe more in some scenarios. From what I’ve observed, an even number of inputs is fine, odd numbers are not. I also observed sitting on the seat for a very long time makes the bug go away.
Here’s how I believe it should work instead:
- Only replicate SteerFloat and ThrottleFloat (the int properties are redundant, infer them from the floats and previous values)
- Quantise the floats to two decimal places (range 0–1)
- Only send updates when the value changes and at a low max rate (e.g. 8hz)
- Using a buffer, its max 2 bytes on the worst of days when batched together.
This would massively reduce bandwidth and make VehicleSeat’s viable again, however until this change is made, I cannot suggest anyone to use this instance in network sensitive projects.
A separate issue is disabling the HeadsUpDisplay property on a VehicleSeat is supposed to turn off the seat’s built-in UI, but the underlying UI updates still run in the background. This can be seen in the micro profiler and the developer console’s script profiler. The performance cost is minor but it’s still unexpected behaviour when I expect it to be fully disabled.
Image holding W key:
Image holding W + A key:
