[17.50] Possible determinism issue involving belts, worms and lag

[Dev-iL]

Consider the scenario of standing on a circular belt next to some worms and/or spitters. If standing at the correct radius, one can just stand there indefinitely w/o being hit, as shown below:



As a non-server player participating in MP games, I've encountered a strange phenomenon when lag (be it due to network conditions, the local PC not keeping up, or a combination thereof) is introduced into the mix. What happens is the character appears to stay in one place for more than one tick, causing the worms to shoot directly at the circle, as if the player is in fact standing in place. I noticed this also happens sometimes when standing on the belts and shooting, where the act of shooting appears to decrease the character's movement speed on the belt - allowing the worms to adjust their aim and hit.

It is as though, if player input isn't received in time, they are considered not to move at all (i.e. ignoring the fact they stand on a moving belt). I claim that this is a determinism issue, because no player input is required to know the belt will influence the player's position on the next tick if he's currently standing on it - and this assumption appears to be broken.

Unfortunately I have no idea how to simulate lag locally, so I cannot test whether my explanation is the correct cause of my observations (and whether it's enough to reproduce it), but there's definitely something fishy going on.

[Stevetrov]

If this was an issue, then it would cause desyncs every time a player who was lagging slightly stood on a belt without immunity.

It appears that players moving on belts is treated as a player input rather than something that happens automatically. I dont know why this is, but I expect there is a good reason.

[EnigmaticAussie]

I don't think this is a determinism issue at all.
It's simply the worms/spitters trying to "guess" where you will be if you continue to move at the current speed and direction. And they aim there.

Since the player is "constantly moving" while being stationary on a belt (still moving relative to the enemy), they will never aim at the belts/player directly.

[Theikkru]

I don't think this is a determinism issue at all.
It's simply the worms/spitters trying to "guess" where you will be if you continue to move at the current speed and direction. And they aim there.

Since the player is "constantly moving" while being stationary on a belt (still moving relative to the enemy), they will never aim at the belts/player directly.

The whole point is that they DO shoot at the player directly sometimes under laggy circumstances.

[Rseding91]

Thanks for the report. As it works now when you fall behind the game simulation or your latency changes the game stops belts from moving your character while you catch up.

It's non-trivial to change that and I'm not even sure if we want to change it. It makes for a nice side effect of not moving the camera while you're catching back up to the server.

[Dev-iL]

Thanks for the report. As it works now when you fall behind the game simulation or your latency changes the game stops belts from moving your character while you catch up.

Ok, thanks for confirming my suspicions.

[Dev-iL]

Some technical clarifications related to this issue are now available as part of FFF #302:

the server and the latency queue need to properly inject a special Input Action called StopMovementInTheNextTick when the above mechanisms come into play. This prevents your character from running by himself (e.g. in front of a train) while experiencing connection problems.

... and also be moved by belts, right?

what you need to know is that since Version 0.17.54 released yesterday, multiplayer will be more stable and latency hiding will be much less glitchy (less rubber banding and teleporting) when experiencing temporary connection problems. I also changed how latency hiding is handled in combat, hopefully making it look a bit smoother.

At least the shooting part was improved in 0.17.54. Although his work is probably unrelated to my bug report, I'm fine with this sort of wontfixing