How we measured CS2 movement and grenade physics

By Memorin · Updated 28 September 2026

Why not just use the numbers everyone quotes?

Because a number that feels right is the most dangerous kind. It looks fine in play. If it is wrong, a practice moment teaches a habit that fails in the real game.

So the project runs on one rule: no gameplay value is estimated. Community pages count as a guess until they cite game files. If we cannot source a value, we do not ship it. We write down why it is unknown instead.

A second rule sits under the first: only 2026 demos count. An older demo is a different build of the game, with different netcode, models and physics tuning. This rule has already caught a real mistake. A derivation on a 2023 demo "corrected" the head bone index from 7 to 6. A 2026 demo gave 7 on 76 of 76 headshots. The old demo was simply a different game.

Where does a CS2 physics number come from?

Every value traces to one of three sources. We call them tiers.

Demos have a special role. They record the server's exact output every tick: positions, velocities, impacts. That makes them the test, not the source. We use a demo to prove a port is exact, never to fit a curve that only looks similar.

How do you prove a constant instead of just fitting one?

Every mechanic goes through the same loop.

1. Extract. Pull the raw data for one system out of 2026 demos into a corpus. Each file records which demo, map and game build it came from.
2. Derive. Measure the candidate value with a method that respects the data's noise. Demo positions are rounded to 1/32 of a unit, so naive methods measure the rounding, not the physics.
3. Prove. Replay the whole corpus through our deterministic float32 simulation with only truly unknown values left free. The error must stay at the rounding level and must not grow with flight length. An error that grows means the model is wrong, however small it is.
4. Promote. Record the value with its source and tier, and keep the replay as a permanent test.

Each result carries a label: VERIFIED (measured and replayed across two or more demos and maps), CAPTURE-VERIFIED (tick-exact against controlled current-build recordings), TRANSCRIBED (T3) (ported from compiled code) or MEASURED (converged, without the replay proof). The Mechanics Reference explains each.

What was measured, and what was read from the code?

The tier column is copied word for word from our ground-truth records, as printed on each reference page. A page never claims more certainty than the record behind it.

What surprised us?

A jump-throw locks in 0.1 s after the jump, not at the top

The popular story says the game releases the grenade at peak height. It does not. A fresh jump schedules a snapshot of your aim, eye position and velocity for exactly 0.1 s after the jump. A throw uses that snapshot if you release anywhere from 6 ticks before the jump to 12 ticks after it. That is a window of about 297 ms.

So every jump-throw inherits the same upward speed: 298.86838 − 800 × 0.1 = 218.86838 u/s. Three real jump-throws in a 2026 demo gave 218.658, 218.888 and 218.888. The peak is about 0.358 s away, so the demo disproves the peak story on its own. This is why a hand-timed jump-throw lands the same as a bound one. Details: jump-throw physics.

Air-strafing comes from two different speed limits

CS2 still uses the classic Source air-acceleration rule, with sv_airaccelerate 12 and sv_air_max_wishspeed 30. The trick is where each limit applies. The test for "may I still speed up" uses the capped 30 u/s. The size of the push uses the full, uncapped wish speed. Turn almost sideways to your motion and the test keeps passing while the push stays large. Air-strafing is not a bug. It follows from those two lines. Details: air acceleration.

The obvious gravity measurement gives the wrong answer

Take the per-tick change in a jumping player's vertical speed and read the median. You get 768 u/s². It is stable and false: 86.8% of airborne heights sit on a 1/64 unit grid, so the median snaps to the grid. Fitting whole jump arcs gives 800.003 over 454 arcs. Two separate current-build recordings give 799.93 and 800.26. Details: movement constants.

Grenade bounce does not depend on the surface

An early pass on coarse old data read about 0.53 for concrete. We recorded it as unresolved instead of shipping it. On 983 bounces from 2026 demos, the normal part came out at 0.4500 and the sideways part at 0.4517. Both scale by one number. The bounce rule read from the game's code has no surface term at all, and it replays 90 controlled throws tick-exactly. Details: grenade bounce.

Grenades are not thrown along your crosshair

There are only three throw speeds: 202.5, 438.75 and 675 u/s. The direction gets a bias of +10° upward when you aim level, fading to zero straight up or down. Your own movement adds 1.25 × your velocity, not the 1.0 × an earlier fit suggested. That older fit was pulled low by noise in the measured velocity. Details: throw speed and release.

Some facts cannot come from match demos at all

A grenade's flight is computed in two half-tick steps. Which order those steps run in cannot be read from recorded positions, because every order fits equally well. It took controlled recordings on the current build to settle it. Only one order replays the recorded values bit for bit. Details: grenade gravity.

What is still unknown?

Each reference page lists its open questions next to its facts. The main ones:

• Crouch-jump throws. They lock in 3.1250 u/s higher, and we measured it. Why is not established.
• Commands per tick. Tournament demos carry the one command the server ran per tick, not how many the client sent.
• Stamina. The constants are exact. The order the game applies them in is still being worked out.
• The 1.25 × inheritance. It comes from the code. Demos agree with it but cannot pin it on their own.
• Smoke timing and flash duration. The delay between a smoke coming to rest and the cloud appearing is not captured. Flash blind duration has only a rough range, so it gets no page at all.

Can I check these numbers myself?

Yes. Every reference page shows each value with its unit, its tier, how it was derived and the evidence, and needs no JavaScript to read. This write-up explains the method and the results. It does not publish our source code.

You can also feel the result. Browser Deathmatch and Replay Moments run on the same movement, shooting and grenade rules. See what you can play in a browser.

Sources: Memorin's CS2 Mechanics Reference and the project's ground-truth records. Measurements dated July 2026, on 2026 tournament demos and controlled recordings on CS2 build 1.41.6.8/10847.