Lag Compensation

This is the server's mechanism, and the one whose errors cost a player their life — in favour of whoever has the worse connection. Everything on this page is shaped by that asymmetry.

The question it answers is narrow: what did the shooter actually see? An action may carry a view time, the tick the actor was looking at when they acted, and the platform restores the targets' poses at that tick so the shot is judged against what was on their screen.

The view time is a claim, not a fact

It arrives from the client, so it is an assertion by the caller and is treated as one. Two consequences:

The compensation window is bounded, and outside it the platform refuses. It does not extrapolate to be helpful: a refusal is a decision you can see, a silent extrapolation is one you cannot.
Reading a target's past state still obeys visibility. Asking about a historical tick is not a way around Visibility — what you could not see then, you cannot read now.

And "the hit did not count" is a verdict, not an error: a successful answer with a machine-readable reason.

What rolls back is declared, and it is not everything

Rolling back everything produces double kills: two players shoot each other, both are rewound to a moment when both are alive, both hit. Rolling back nothing cancels lag compensation itself. The boundary between them is a declared list.

The rewind itself belongs here rather than to the modules being rewound. The history ring restores the poses of the tick under dispute and Collision is then asked its ordinary overlap question about those poses — collision keeps no history of its own and nothing in it knows what a view tick is. The ring itself is the entity's history track, not a second store.

The decision is taken on the past; the effect applies in the present

Lag compensation answers a question about the shooter's moment of view. The consequences — damage, death, the award — apply to the current state. What happened between the moment of view and the moment of decision is not cancelled and not recomputed.

A player can shoot after being killed

A player can get a shot off after having been killed by someone else's rewound shot. This is intended: cancelling it would mean replaying the world on top of a rewind that doesn't promise reproducibility, which creates divergence instead of removing it.

Server-side re-simulation is out of scope. Recomputing consequences against a new truth needs a fixed reference point that floating-point state does not give us. What stays is everything the module rests on: a client replaying its own unconfirmed inputs (Predicting Your Own Motion), and lag compensation as reading the past for one decision. That is how favour-the-shooter works in practice.

If you are arriving from somewhere else

Favour-the-shooter lag compensation as shipped in most competitive shooters: the same mechanism, and this page is it.
Full rollback netcode. The rewind is here; the replay of the world afterwards is not, and the paragraph above is why. If your design depends on consequences being recomputed after the fact, that dependency is the thing to raise with us early rather than discover late.

Also worth knowing

The implementation is overridable. If your game needs a different compensation rule, you can replace ours, and the replacement declares which of the declarations it honours.
There are no extension points on the prediction and correction path. Those run at tick rate.
None of this applies under external authority. Lag compensation exists for rooms our simulation runs. When the tick belongs to a studio's game server or a master-client, compensation belongs to whoever runs it — see Who runs the tick.