Public: anyone can read this; the crew can change it.

forked from trevato/cs · proposes

The range walks: its own movement tuning and hull through the engine’s solver #163

Merged opened this

Check · Review · Land · Live done — Landed and live in production.

Merged

A person now walks the range, on numbers that are the range's and not Counter-Strike's. `src/range/movement.ts` holds `RANGE_MOVE` and `RANGE_HULL` with a sentence per number: 180 u/s against the shooter's 250, 900 of gravity against 800 (a jump that clears exactly 40.5 units against 57), 7 of friction against 5.2, a quarter of the air acceleration and half the air cap — there is no strafe-jumping…

shipped production is serving it deploy ae07c2d

opened this

A person now walks the range, on numbers that are the range's and not Counter-Strike's. src/range/movement.ts holds RANGE_MOVE and RANGE_HULL with a sentence per number: 180 u/s against the shooter's 250, 900 of gravity against 800 (a jump that clears exactly 40.5 units against 57), 7 of friction against 5.2, a quarter of the air acceleration and half the air cap — there is no strafe-jumping at this range on purpose — a wider hull, a 12-unit step and a crouch that closes in an eighth of a second and drops the eye 22 units. One number is the same as the shooter's and was chosen rather than inherited: eyeStand 64, because that is where every plate's distance is measured from and where the pinned thirty seconds were shot from; EYE in targets.ts is now derived from it rather than written down twice. main.ts steps a body through RANGE_ROOM with the engine's move on every tick, body first and plates second, and the eye that eyeHeight puts on top of it is what the camera sees from, what the bullet leaves from, what the tracer is drawn from and what the 2D horizon projects from — so walking and crouching change what you can hit.

One pinch, and it was the tuning's rather than the solver's: accelerate × wishSpeed has to beat max(wishSpeed, stopSpeed) × friction or a stance bleeds speed for as long as you hold the key. The first draft's stopSpeed 70 lost that against a 60 u/s crouch, movement.test.ts caught it in the six-second settled-speed test, and stopSpeed moved to 60 with the arithmetic written down beside it. src/engine/physics.ts needed no change at all.

What to look at: /range walks — W down the lane, C to crouch, and the panel's new line prints where you are, how high your eye is and how fast you are going. Both pin digests are untouched, deliberately: the script stands at the firing line and fires from EYE, which is where a standing body's eye is, and pin.ts now says why the walker is outside the digest and what would put it in. bundle.test.ts's test that the range ships none of the mover said the opposite of the truth after this change, so it is inverted rather than deleted — it now reads the committed file for the solver's fields and for the range's own jump and top speed, and for the absence of 301.993 and maxSpeed:250. The range's ceiling is raised to 37,000/15,500 for the 4,531 raw / 1,404 gzipped bytes the mover and its wiring cost, logged in src/games.ts with the measurement.

What I left alone: the digest does not gain the body, and a drill still scores you for the plate and not for where you stood. Separately, src/client/main.test.ts's spectator test is flaky on main as well as here — createWorld seeds from Date.now(), so it plays a different match every run; I measured one failure in eight on a clean tree and did not touch it, since it is the shooter's and outside this issue.

🤖 Generated with Claude Code

Closes #63

commented

main is merged and pushed; bun test is 719 passing, 0 failing on the merged tree.

Both conflicts were the same argument from two sides: ceilings. main raised the app's to 88,000/40,500 for #142's grenade and left the range's at 33,000/14,000; this branch raised the range's to 37,000/15,500 and left the app's alone. The resolution keeps both raises and both log entries in src/games.ts, #142's paragraph then this pull's, with scripts/build.test.ts's pinned table matching.

One real code consequence of the merge, not just text: #142 made restitution a required field on MoveTuning, so RANGE_MOVE now writes its own 0 with a sentence saying why — a person does not bounce off concrete; the knob exists for a thrown grenade, and nothing at this range is thrown. That and the solver's two new branches put the range's bundle at 33,645 raw / 14,147 gzipped, 134 raw bytes more than before the merge and comfortably inside the raised ceiling; all three bundles are rebuilt and committed on the merged sources.

The prose moved where the merge made it wrong: the README no longer claims the solver has two tunings — it has three now, counting NADE_MOVE, and the line that says one solver holds the numbers of none of them is the claim that still holds. The range's module list in the README gains movement.ts.

🤖 Generated with Claude Code

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs