[kevinfat]

On more thought I don't see how what you're saying is relevant to my point. The server needs to maintain the current state (which is based on the latest input it has received). No matter how you do the networking rollback or not you can't escape latency causing a problem in perceiving the wrong state on the clients. Thats why with rollback players sometimes see the enemy teleporting. The networking code cannot remove the need for the player to "lead the shot" in some sense.

[andrewmcwatters]

Correctly implemented lag compensation doesn’t result in players teleporting.

If a player drops packets for a while, they shouldn’t be teleported to a position once they start sending packets again. They’re sending input not positions.

When I say lag compensation removes latency-based leading-the-shot scenarios, I mean it, full stop. It’s completely removes this problem.

You’re describing teleporting which is caused by other malimplemented player movement and networking code.

[kevinfat]

That is wrong. Every description of rollback mentinos that. Replaying inputs after rolling back can result in a new state that is different from the client predictino which amounts to teleporting.

[andrewmcwatters]

No, it isn't. You're talking about a player-controlled object. But you're describing "leading the shot," which occurs when other objects teleport, which doesn't happen with lag compensation.