In CS2, when a player is sliding/surfing against some geometry, it's possible that they lose all their momentum/velocity. This is usually called wallbug/rampbug. While the name was inherited from Source 1 games (such as CS:GO, CS:S, TF2,...), rampbugs in CS2 behave much differently from its predecessor. In contrast to source 1 games, it's also possible have the velocity redirected to another direction instead of losing all momentum.

This bug doesn't seem to be common in all source 2 games (HL:A for instance, does not have this bug), and was orignially not present in the very early versions of CS2 Limited Test. Rampbugs become more and more frequent over time, with the Call to Arms update effectively doubling the frequency of these bugs, which is a significant problem for custom gamemodes heavily depending on geometry collision (eg. surf).

Keep in mind that while the player collision hitbox is a box, the images shown below will represent the player as a dot instead for simplicity.

As of September 18, jump inputs using scroll are treated very weirdly compared to using a normal key. By enabling cl_showusercmd 1 (hidden cvar) and with some extra hackery, I managed to figure out a bit about how the jump input cooldown works.

Basically, the cooldown of 0.015625s (or whatever sv_jump_spam_penalty_time's value is) starts when the player stop pressing the jump button. Whether you can jump again or not depends on when you release the next jump input (or until the end of that tick).

There are two common ways player can jump: Either with a keypress (condition 1 in the examples) or with a scroll step (2). This cooldown functionality works fine with method 1, but gets really confused if players use the wheel to jump.

Example 1: On low timescale, I very quickly pressed spacebar to jump, twice.

cl: 54894 ===========================

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 `AirAccelera