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>
Round six raced all three machines (staging fix confirmed) and then
exposed what happens when a pod leaves mid-mission - which arcade pods
never did.
The B crash dump named it exactly: VTV::TakeDamageMessageHandler
resolved message->inflictingEntity to NULL (the entity belonged to the
departed owner) and dereferenced it - Verify is compiled out in
release. Collision damage from an entity that no longer exists is now
ignored.
And the race B and C were left in was a zombie: the owner (console)
had aborted, so the mission clock would count up forever and the
death/respawn flow hung with nobody to arbitrate. Lobby-member races
now set gConsoleLossEndsMission: losing the console mid-mission posts
StopMission locally, the pod tears down, and lands back in the lobby
room. Arcade -net pods keep the re-listen-and-wait behavior.
Loopback hosted race still green.
For the drivers: the ampersand key is the arcade mission-abort - that
was every crash-on-keypress so far; and a sleeping Bluetooth pad wakes
on the Xbox button and hot-connects within 3 seconds (PadRIO
re-probes).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Imports the current Win32 source for the pod-racing game 'Red Planet',
built on the MUNGA engine and its L4 (Win32/DirectX) platform layer:
- MUNGA / MUNGA_L4: cross-platform engine core and Win32 backend
- RP / RP_L4: Red Planet game logic and Win32 application
- DivLoader, Setup1: asset loader and installer project
- lib, MUNGA_L4/openal, MUNGA_L4/sos: third-party audio dependencies
Removed stale Subversion metadata and added .gitignore/.gitattributes.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
CydandClaude Fable 5