Clients send their inputs to the listen server host and those inputs get buffered (NetworkPredictionService_Input.inl). I’m seeing a buffer of sometimes 10-13 inputs. The listen server will consume those inputs one at a time each simulation update. We’re using a fixed tick rate of 33ms and I think that accounts for our extra ~0.4 second delay on the listen server.
The listen server also sends it’s updates to the client and those are buffered for interpolation, but we have made some changes to the NPP fixed tick interpolation of simulated proxies to speed up or slow down interpolation when the buffer grows too large or too little. So clients typically have a much smaller buffer of ~3 frames of server state to interpolate between.
Are there any plans to handle when the number of buffered inputs grows large enough to create a noticeable delay for the listen server host?
Have the listen server host jump and note how long until it takes for their simulated proxy to jump for the connected client. In my tests, this is around 0.5 seconds.
Have the connected client jump and note how long until it takes for their simulated proxy to jump for the listen server host. In my tests, this is around 0.9 seconds.
Repeat and notice that there’s consistently a much larger delay for the listen server simulated proxies. In my tests, it’s usually an extra ~0.4 seconds.
[Attachment Removed]
You’re in luck - we’ve integrated a simulation time dilation mechanism in UE 5.8 for Network Prediction’s Fixed Tick mode. The server will suggest clients slow down or speed up their simulation rate until achieving the smallest input buffer size without underruns.
When network lag gets bad, a client starts predicting farther ahead of the server to account for a long RTT. This results in a longer time between the client’s actions and when other players see them. Once network conditions improve, latency is reduced and more pending inputs than necessary end up being buffered. The server detects this and will tell the previously-lagging client to reduce how far ahead it’s predicting. Over a short amount of time, the time between one player’s actions and other players seeing the result will be reduced.
This is enabled by default in the 5.8 release. The speeds and limits of dilation adjustment can be tuned with a variety of CVars: np.TimeDilation.****
This fixed tick time dilation mechanism sounds like just what we need. We’re planning on upgrading to 5.8 in a couple of weeks. Awesome to know that a solution is already ready to go
