RP412INPUTSCRIPT names a timeline file - one row per change, throttle,
stick X and Y, pedals, held until the next row's time - and the pod
drives it instead of listening to the controls. Times are SIMULATION
seconds from the green light, evaluated per step in the one place every
mapper funnels through (VTVControlsMapper::InterpretControls), so the
same script is the same lap at any frame rate. Rows hold rather than
interpolate on purpose: interpolation would sample differently at
different physics rates, and nothing on this path is allowed to.
The script shares the green-light anchor with RP412PHYSTRACE - its
clock starts at the instant the vehicle is stopped dead - because a
timeline that starts when the loader happens to finish is a different
lap every run.
A race is only deterministic if somebody DRIVES it, and a human cannot
drive the same lap twice. The first scripted lap - full throttle, a
steer, a crash at speed - earned the harness immediately:
- The drive, the crash, the death and the respawn teleport were all
BIT-EXACT between identical runs, through t=13.5. Collisions with
world geometry and the damage path are step-deterministic, which is
better news than the code reading suggested.
- The first divergence is the step AFTER the respawn: the DropZoneReply
that stands a dead pod back up is posted at wall-clock Now()+1.0
(RPPLAYER.cpp), so the reset lands on a different sim step every run
and everything after is time-shifted. The crash is deterministic; the
RECOVERY is not. That is the next fix, and it is now a measurement,
not a theory.
Values are clamped at load, once and visibly, so a script asking for
throttle 2.0 cannot trip the mapper's own range Verifies. Off unless
the environment names a file; it would be a cheat in a real race.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
CydandClaude Fable 5
af52476603