How AimFinder measures your CS2 sensitivity
Most sensitivity finders ask what feels better. AimFinder measures where your flicks actually land. This page documents the full method — the camera math, the metric, the search algorithm, the validation step and the demo pipeline — along with its limits.
1. A camera that is exactly CS2
Any measurement is worthless if the test environment scales differently from the game, so the in-browser scene reproduces CS2’s camera one-to-one:
- Yaw constant 0.022 — each raw mouse count turns the camera 0.022° × sensitivity, the same formula CS2 uses.
- CS2’s field of view — 90° horizontal at 4:3 with hor+ scaling, i.e. the identical vertical FOV at any aspect ratio.
- Raw input — pointer lock with unadjusted movement, so the browser applies no acceleration or smoothing to the counts.
A 180° flick in AimFinder is therefore the same hand movement as a 180° flick in-game, at the same DPI and sensitivity.
2. The metric: first-submovement bias
Rapid aimed movements decompose into a large ballistic submovement — pre-programmed, executed without visual feedback — followed by small corrective ones. AimFinder splits each flick’s trajectory into submovements and compares the endpoint of the first one against the angle the target actually required.
The result is a signed bias: positive when the first movement flies past the target (overshoot), negative when it stops short (undershoot). Individual flicks are noisy; the systematic bias across a block of flicks is the signal. A consistent overshoot means your motor calibration expects a lower gain than your current sensitivity provides; consistent undershoot, the opposite.
3. The search: an adaptive staircase
You play short blocks of wide flicks. After each block, the staircase reads the mean bias and moves your sensitivity in the direction that reduces it — expressed in cm/360 so steps are physically meaningful — with step sizes that shrink as the search closes in. When the measured bias stays within noise across reversals, the search has converged on the sensitivity where your ballistic flicks land on target.
This is the same class of procedure (adaptive staircases) that psychophysics uses to find perceptual thresholds — it spends your flicks where they carry the most information instead of testing a fixed grid of values.
4. Validation: a blind A/B check
Sensitivity opinions are extremely placebo-prone, so the session ends with a blind comparison: you play short rounds on the recommended value and on a decoy without knowing which is which, and the scores decide. If the recommendation does not outperform, the report says so — the point is a number you can trust, not a number that flatters the algorithm.
The output is given as in-game sensitivity for your DPI, eDPI and cm/360, with your full trial data exportable as JSON from the history page.
5. The demo pipeline
The demo analyzer applies the same idea to real matches. Your uploaded .dem file (also accepted: .bz2, .gz, .zip) is parsed server-side into per-tick view angles and events. For every kill, the pipeline reconstructs the engagement: the angle from your pre-fight crosshair position to the target, the first ballistic movement you made, its overshoot or undershoot, the corrective movements after it, movement state at the shot, and timing.
Kills aggregate into the same bias statistic as the finder, segmented where the sample allows it — the headshot-only segment, for instance, requires at least 8 headshot kills before it reports anything. The aggregate bias, referenced against the sensitivity you declared for that match, produces a cm/360 proposal you can then verify in the controlled in-browser test.
The demo file itself is deleted right after parsing; only the per-kill numbers are kept (see the privacy policy).
6. Honest limitations
- Day-to-day variance. Aim fluctuates with sleep, warmup and stress. The finder needs one session; trust grows with two or three, and the history page tracks the trend.
- Demos are tick-sampled. ~64 samples per second of camera angles, not your mouse. Sub-tick detail is reconstructed, not observed — which is why the in-browser test (raw input, millisecond timing) is the confirmation step.
- A browser is not the game client. Rendering and input latency differ from CS2 itself. The camera math is identical, but absolute scores are only comparable within AimFinder, never to in-game stats.
- A recommendation is a starting point. Muscle memory adapts over days. Play the recommended value for at least a week before judging it, and re-measure rather than re-guess.