public sealed class TickLeadControllerMoves the client's tick lead to whatever the server says it needs to be.
No guide page documents this yet — the page shows what the code says about itself.
Remarks
The feedback loop prediction was missing. Everything else was in place: the buffer measures, TickManager.LeadBias adjusts, and nothing carried one to the other — so a client's lead was whatever the round-trip estimator produced for interpolation, which is an estimate of a different quantity.
One tick at a time, and never on one report. Changing the lead moves every input the client has not sent yet, so a controller that reacted to a single starved tick would spend its life oscillating — and each oscillation is a visible correction, because a shifted lead means inputs arriving for ticks the server has already simulated. It waits for a run of reports agreeing, then moves by one.
It is asymmetric on purpose. Starvation is corrected quickly and depth is given up slowly, because being too far ahead costs a little input latency and being too far behind costs corrections the player sees. Cheap mistake, expensive mistake.
Fields and properties (6)
public int TargetDepthHow deep the buffer should be. Matches InputBuffer.TargetDepth.
public int PatienceToGrowHow many reports must agree before the lead moves.
public int PatienceToShrinkHow many must agree before it is given up.
public int MaxBiasThe most the bias may be pushed either way.
public long GrewCountTimes the lead was increased.
public long ShrankCountTimes it was decreased.
Methods (2)
public int Apply(TickManager ticks, in PredictionHealth report)Takes a report and adjusts the clock.
public void Reset()Forgets what it was waiting for, after a snap or a reconnect.
Used by (1)
- PredictionWiringTestsVixen.Net.Tests