Skip to content

Instantly share code, notes, and snippets.

@zer0k-z
Last active September 15, 2023 05:25
Show Gist options
  • Save zer0k-z/808bc8bfc494e0bbb5a423c2b1ca6685 to your computer and use it in GitHub Desktop.
Save zer0k-z/808bc8bfc494e0bbb5a423c2b1ca6685 to your computer and use it in GitHub Desktop.
CSGO (and CS2) deadstrafe explained

In CSGO/CS2, deadstrafe period is the term created by the KZ community which refers to the period where the player's airstrafe capacity (and therefore turning capacity) is significantly lowered. For the simple explaination, see this video by RedMooN.

The cause of this involves two functions, CGameMovement::CategorizePosition and CGameMovement::AirAccelerate.

To be more specific, the main culprit is this line of code in CategorizePosition, which reduces the player's surface friction to 0.25 (originally 1) when the player is in the air and has a vertical velocity between 0 and +140.0.

Inside AirAccelerate, the acceleration amount is multiplied by this friction value, even though the player is in the air and it doesn't make a lot of sense to have "friction" with any surface in this scenario.

The result of this is that on typical settings (64 tick, 250 max speed, sv_airaccelerate 12), the maximum amount of speed gain changes from 30 (capped by sv_air_max_wishspeed = 30, 12 * 250 * 0.015625 * 1 = 46.875 otherwise), to 11.71875 (12 * 250 * 0.015625 * 0.25) for a while, then back to 30 again. The player's air movement becomes very awkward, as this means airstrafing behavior usually changes 25% into the jump, and back to normal again once the player starts falling. This is the equivalent of having sv_airaccelerate 12 at the start, suddenly going down to 3, then back to 12 again.

While the friction value multiply is also present in GoldSrc based games, this friction value is always at 1 in the air because its CategorizePosition equivalent does not modify the surface friction in the air, so this behavior is not present in the original implementation of CS airstrafe.

I suggest either removing this multiplier off the air acceleration calculation, or adding a ground check in CategorizePosition to make sure it does not get set to 0.25 while in the air.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment