Even Footing

Two follow-ups to the v0.5.12 playtest, both from watching another match: the Speed rebalance only half-worked at full team sizes, and the dragoon's Jump still didn't land where Joe wanted it.

Changed — Speed now matters the same at 5v5 and 8v8 as it does in a duel (ct_system::tick)

v0.5.12 compressed the Speed curve to ~1.5x at the extremes and pinned it with a two-unit test. But the CT loop granted at most one turn per wall-clock tick, and once a roster's total CT gain per tick exceeded the threshold — which it does from 5v5 up — several units crossed at once, one acted, and the rest of their overshoot was discarded on the reset. Over a full board that equalised everyone regardless of Speed: measured, a 16-unit roster read 1.04x between the fastest and slowest units while a duel read ~1.5x. Speed was close to inert at exactly the team sizes where the game is busiest.

The scheduler now advances the virtual clock to the next single crossing each tick (jump dt steps, where dt is the fewest until someone reaches the threshold) instead of a fixed step. Demand is one turn per tick at any roster size, so the turn share tracks the Speed curve whether there are two units or sixteen. Measured after: 2u 1.60x, 10u 1.60x, 16u 1.61x — dead flat.

The wall-clock fire rate — the thing that actually paces the game — is untouched, and the caller still sees "a tick may or may not produce a turn", so the server/client loops and the charged-ability countdown needed no change. The client's HUD turn-order forecast was updated to mirror the same dt-jump, or it would have promised an order the engine won't deliver on the biggest boards.

Pinned by speed_spread_is_the_same_at_any_roster_size, which measures the sp-12↔sp-5 ratio at 2, 10 and 16 units and fails if they diverge. Verified by reverting the scheduler to the fixed step: the 5v5 number collapses to 1.06x and the test names the cause.

This is the fix I flagged as "your call" last release — it turned out to be a contained scheduler change, not the threshold-and-tick-period rework I'd feared, so no wall-clock pacing changed.

Changed — the dragoon's Jump returns to where it leapt from (abilities::resolve_queued_cast)

Reported as "the jumped unit lands 1-tile ahead of where it jumped, but its supposed to return back to its original jumping-from Tile."

Jump used to land the dragoon on the aimed tile (or, when that was occupied, the nearest free neighbour — which is the "1 tile ahead" Joe saw). It now strikes the aimed tile and comes back down where it leapt from, the FFT-style aerial strike that returns to its own line. This also makes the self-hit fixed in v0.5.12 structurally impossible — the dragoon is never the occupant of the tile it struck.

Fixed — an airborne dragoon is hidden, not parked at the top of the screen

Reported as "not totally out of the screen like it should (you can still see them at the top of the screen)."

The unit rose nine world-units to "clear the frustum", but the player controls the camera zoom, so no fixed height is safe and it hung in view up in the sky for the whole charge. It now rises and then vanishes — the whole unit root is hidden at the top of the leap and reappears on landing (which always happens, since an airborne unit can't be damaged, so the cast never interrupts).

Note on the build environment

cargo builds this session had to be run through vcvars64.bat: vswhere stopped reporting the local Visual Studio install (a transient VS-updater state), which breaks cargo's MSVC linker auto-detection. The linker itself is fine; only its discovery was. Also, the full test suite has to run -j 2 on this machine — compiling all ~28 test binaries at once exhausts the paging file. Neither is a code issue.