I imagine it’s a common use-case to smooth movement based on time for a natural look. What options are available?
My only thought currently is to maintain a “copy” of Time.DeltaTime in a component that is passed in as a UserData Parameter Component. Seems potentially error prone. Any better options?
Storing the delta time is not necessary and can’t really control the way the value is going to be smoothed.
There reason is that the GhostPredictionSmoothngSystem is used to fix for prediction error (not smoothing in general the movement or whatever).
The smoothing is called inside the prediction loop only for full ticks, given the way it work, and it try to adjust the error in between the current predicted value (based eventually on the new receive data from the server), and and last prediction backup.
If there is no prediction error, the delta in between the predicted and the current backup is 0. Otherwise, an adjustment to reduce the error is done.
This adjustment is performed only when the current NetworkTick equals the tick of the last backup, so either a rollback must have occurred.
The adjusted new value of the component data is then stored in the backup and will be used as new start prediction point for the subsequent new simulation ticks. As such, the smoothing does not occur until a new update from the server are received and new adjustment will be made.
It does not run every frame or partial ticks, so storing the delta time would equals store a fixed value of 1f/SimulationTickRate.
Ah, makes sense. Thank you for the clarification. I’m still wrapping my head around what tools/interfaces/Singletons/concepts are available for helping hide network latency. The more I think about it, smoothing movement based on a server correction instead of teleporting should really only occur in a worst-case scenario. The majority of latency correction will be hidden inside animations/forced input latency/action lock windows.
I just found some singletons like ClientServerTickRate, ClientTickRate, NetworkSnapshotAck, and NetworkTimeSystemData. These seem rather important to understand before being able to hide latency precisely. If you know of any resources/previous threads that give an overview of these concepts, that would be very helpful. If not, thank you for the previous answer to help set me on the right path!
Are you saying if the player has a high FPS, in that it reruns the prediction and only does progress on a partial tick, it will not run this system multiple times? I don’t see that in the systems logic, can you elaborate where this is comming from? If not, the quality of the smoothing is highly depdendent on the FPS and the frames delta time should be used? If this is not the case I feel like this system is flawed in its design.
Yes, it is somewhat flawed. And not only for that reason. It also has the problem that the error reduction is tight to how often packet are received. If the send rate is low, or that specific entity has low updates for any reason, the adjustment is not done as frequently as it should be.
Yeah, I was gonna come to this. This doesn’t look very “smooth” when you’re predicting other players and it has to correct on low tick rate. Are there any plans in the close future to improve on this?
Yes, there are plans to change this. I don’t have an ETA yet