A scripted lap - full throttle, a steer, a crash at speed, the burn,
the tumble, death, respawn, a second crash, a second respawn - now
plays out bit-identical between identical runs and across 30 and 144
fps under RP412PHYSICSHZ. Ninety of ninety samples exact in the repro
pair, sixty of sixty across frame rates, max difference 0.000000. The
crash was already deterministic; this makes the RECOVERY deterministic,
and it took five pieces, every one found by measurement:
- The respawn teleport moves onto the vehicle's own step grid.
VTV::ScheduleRespawn stores it and BeginStep applies it at the first
step whose clock reaches the due time, teleport and turn-toward-goal
together, because the goal flip reads the POST-reset heading. The old
path applied the Reset from the event queue, which runs on wall
clock, and identical runs diverged on the first step after the pod
stood back up.
- The handler keeps its Reset for the FIRST spawn of a mission, gated
by a flag rather than by mode. A Mover is born in StasisState and the
first Reset is what wakes it; gating on "is fixed stepping on" - the
first attempt - skipped that wake-up and parked the pod frozen at its
spawn point for an entire race. The scripted-lap harness caught it in
one run.
- The vehicle stamps its own death clock, at the single site that sets
BurningState - inside the step machinery, which is why the crash
measured exact. The schedule anchors to the death, the last
step-exact event in the chain.
- The due time is quantized to a half-second grid ANCHORED AT THE
DEATH. The instrument showed the naive anchor was four seconds stale
by scheduling time: the fry chain reposts itself at wall-clock
Now()+2.0 and the drop-zone reply lands about five sim-seconds after
death, jittered by a few steps of queue timing. Firing "next step"
inherited that jitter whole. Rounding up to the next half-second
after the death puts hundredths of jitter against tenths of headroom,
so every run lands in the same cell - and the felt delay stays the
six-ish seconds it has always been.
- The out-of-world tumble draws from a per-vehicle random stream seeded
by creation order. The global Random is shared with the frame loop's
consumers - particles, mostly - so its position at the moment a
burning pod drew from it depended on how many frames had rendered,
and the kick went straight into angular velocity. Last wall-clocked
input in the whole death cycle.
The respawn scheduling and firing log under RP412PHYSTRACE in
run-comparable terms - pad identity, due offset, lateness - because
those lines are what cracked this: "due in -4.06 sim-s" said more in
one glance than three rounds of hypothesis.
Still outside the claim: multi-vehicle contact (DynamicBounce writes
the victim's state from the striker's step) and network play. That is
the lockstep frontier, and it now has a harness waiting for it.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>