3 ms·

There's something I always wondered about the gamestate rewind thing: Is it correct that the gamestate rewind only works for hitscan weapons (instant hit bulle

There's something I always wondered about the gamestate rewind thing: Is it correct that the gamestate rewind only works for hitscan weapons (instant hit bullet)? What about slow moving projectiles or physically accurate bullets? Can the server spawn the projectile 200ms in the past at the time you pressed the button? But then other clients would receive the information about 400ms later after the initial keypress, which does not seem right...

vvanders 10y ago
The projectile issue actually is much better. Since as a player you're trying to shoot the projectile to "predict" where it will intersect you're actually playing to the strength of latency and dead reckoning(that's the SubSpace case above). You want to segregate your action into twitch(reactionary: hitscan, parry, etc) and predictive(slow projectile, > 250ms ttl, etc) and only rewind/replay for the twitch case. There's also the case that when you rewind and do confirm a gamestate change you need to gracefully handle resolving it on all clients. That's why you'd see people warp back around corners when shot in Counter-Strike. Their player movement speed slowed after being hit and the server reconciles it and then the clients interpolate the result.
clevernickname 10y ago
In Source Engine games, there is no lag compensation for projectiles. The lower your ping, the faster the projectile is spawned on the server. You can see this very clearly when playing on high ping: you click mouse1, you hear the rocket fire, but the rocket doesn't appear for a good fraction of a second. Since TF2 is very heavily based around projectiles (Soldier's rockets, Demo's pills and stickies, etc) many competitive players play with their cl_interp (determines how many ticks worth of game state are delayed before being displayed, interpolated, to the player) set lower than default (which is 2 ticks at 66 ticks per second by default). This results in jerky movement if packets are lost, but it ensures that they see threats as soon as possible so that they can fire their projectiles with minimal (real time) delay. I think it might also have some effect on client side input buffering; not sure, but that would be an even bigger reason for projectile users to want low interp.

vvanders 10y ago

The projectile issue actually is much better. Since as a player you're trying to shoot the projectile to "predict" where it will intersect you're actually playing to the strength of latency and dead reckoning(that's the SubSpace case above). You want to segregate your action into twitch(reactionary: hitscan, parry, etc) and predictive(slow projectile, > 250ms ttl, etc) and only rewind/replay for the twitch case. There's also the case that when you rewind and do confirm a gamestate change you need to gracefully handle resolving it on all clients. That's why you'd see people warp back around corners when shot in Counter-Strike. Their player movement speed slowed after being hit and the server reconciles it and then the clients interpolate the result.

clevernickname 10y ago

In Source Engine games, there is no lag compensation for projectiles. The lower your ping, the faster the projectile is spawned on the server. You can see this very clearly when playing on high ping: you click mouse1, you hear the rocket fire, but the rocket doesn't appear for a good fraction of a second. Since TF2 is very heavily based around projectiles (Soldier's rockets, Demo's pills and stickies, etc) many competitive players play with their cl_interp (determines how many ticks worth of game state are delayed before being displayed, interpolated, to the player) set lower than default (which is 2 ticks at 66 ticks per second by default). This results in jerky movement if packets are lost, but it ensures that they see threats as soon as possible so that they can fire their projectiles with minimal (real time) delay. I think it might also have some effect on client side input buffering; not sure, but that would be an even bigger reason for projectile users to want low interp.