Reworked clientside movement prediction handling #2538
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously the movement prediction would calculate the full distance but with lerping enabled would only move the player partially towards their destination. I'm guessing this was to reduce mismatches due to all of the variables present in Doom, but the result was extremely stuttery when playing online at high latency unless using a high scalar value. The thing is, this feature should always be disabled because in low latency, chances for a misprediction are small and in high latency, rubberbanding is much more common. Rather than assuming the player is wrong, prediction should be assuming the player is right and only correcting when truly wrong.
This rework removes the lerping and instead replaces it with a proper rubberbanding solution. If a movement mismatch is detected, it will now interpolate the player towards their corrected predicted position, smoothing out the snaps from a misprediction. Since lerping has been removed,
cl_predict_lerpscale
andcl_predict_lerpthreshold
have been deprecated. Instead they're now succeeded by three new cvars:cl_rubberband_scale
: This determines how aggressively the interpolator should try to correct the player over their misprediction distance. Setting this to 0/1 is equivalent to having no interpolation and instead instantly snaps the player, otherwise moving them by a portion of the difference.cl_rubberband_minmove
: When correcting, this is the minimum distance it will interpolate. This is to prevent small movements during smaller corrections and ensure the interpolator can correctly reposition the player on their end.cl_rubberband_threshold
: Only differences larger than this distance should be considered for interpolating. This makes it so small mispredictions simply move the player to the right spot instantly, making it less noticeable in lower latency situations.