Hi, I have a situation with a networked moving platform. The player and platform are predicted and work fine. Other players are interpolated and are lagging behind on the platform. If I predict them, the platform logic is fine but their predicted movement is jittery as can be expected.
I want to implement a solution where other players are interpolated but their offset from the platform is also tracked (if on a platform). Their position will be “predicted” by that offset and the current position of the predicted platform. All other aspects will be interpolated normally so should not be jittery.
I understand this would be problematic when they are entering and exiting platform, but I am willing to live with that for the moment.
My question is how do I achieve that, is it as simple as having a ghost variable for the offset and modifying interpolated ghosts in system simulation group?
I see there is ghost prediction system group, is there something like that for modifying ghost interpolation?
Yes, you need to add a ghost variable to the ghost for that offset.
The offset should be calculated way before the player is “on the platform”, ideally when they are “close enough” to it (on the owner side). On the “non-owner” side, the offset calculation is done only when the character is detected staying on the platform to smooth the transition.
There is no way at the moment to customize the interpolation of ghost fields, but it is possible to implement such customized behaviour in case you actually “predicting” the other player position on the platform.
The simplest option is to run a system after the GhostUpdateSystem or PredictedSimulationSystemGroup, but before the TrasnformSystemGroup, that override the transform position using the interpolated offset and the current platform position.
Because you have predicted ghosts, you can also try to modify the position of the interpolated character in the prediction loop, but it may get complex handling rollbacks. You need to implement you own system to track, store and rollback the positions or all the players based on the latest received tick.
We have something already in the sample that show how to implement something like that (HelloNetcode/05_Advanced/ClientOnlyState). I don’t see immediate advantages on doing.
Another options is to use PredictionSwitching and predict the other players only nearby the platform but interpolated otherwise. It also has its gotchas when entering/leaving the platform, but then the timeline is more consistent and they can interact with other predicted object on the platform or physics objects as well (if you need).
In is also extermely important to understand the consequence of using an offset for the player position when they are on the platform in case you need to use LagCompensation.
Because the server store the collision state each tick (the broad phase of the physics world) when it rewind to check for hit collisions, he need to compensate now for the fact the player wasn’t seeing on screen for Tick X the state of the player (if on the platform) for Tick X, but instead something adjusted by the offset at that tick.
It is non trivial to make the server raycast in the past work in that scenario, because you need to compensate for that difference in position. That would imply ideally to re-build the collision broadcast for the dynamic objects, or other strategies should be devised.
All
1 Like