vwemirror/RP412
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

The death cycle is deterministic

Browse Source 
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>
This commit is contained in:
Cyd
2026-08-09 21:42:04 -05:00
co-authored by Claude Fable 5
parent af52476603
commit c479cd48e9
4 changed files with 335 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
RP/RPPLAYER.cpp
+111
View File
@@ -382,6 +382,96 @@ void RPPlayer::ResetAfterDeath(DropZone::ReplyMessage *message)
ForceUpdate();
SetSimulationState(DropZoneAcquiredState);
dropZoneLocation = message->dropZoneLocation;
//
//------------------------------------------------------------------
// Fixed-step: the RECOVERY goes on the vehicle's own step grid.
//
// The event queue runs on wall clock, so a Reset fired from it
// lands between different sim steps on every run - the crash was
// measured bit-identical between runs and the first divergence was
// the step after the pod stood back up. The vehicle applies the
// teleport itself at the first step one SIM second after now; the
// message still makes its round trip below, but only for the
// player-state bookkeeping - the handler leaves the physics to the
// schedule it can see is pending.
//------------------------------------------------------------------
//
if (Simulation::FixedStep() > (Scalar) 0 &&
playerVehicle != NULL && playerVehicle->GetClassID() == VTVClassID)
{
VTV *vtv = (VTV *) playerVehicle;
//
// Anchored to the DEATH and quantized to a half-second grid.
//
// This handler runs when the drop-zone reply finally comes off
// the event queue, and the whole death-to-here chain is wall
// clock - the fry retries repost at Now()+2.0, and the measured
// arrival is about five sim-seconds after death, give or take a
// few STEPS of queue jitter. An anchor of death+1.0 is long past
// by then, so "fire at the next step" inherited the jitter
// whole.
//
// The death stamp is the last step-exact event in the chain, so:
// take the measured gap, add the second the old code waited, and
// round UP to the next half-second AFTER THE DEATH. The jitter
// is hundredths; the nearest grid boundary is tenths away; every
// run lands in the same cell and fires on the same step. The
// felt delay is the same six-ish seconds it has always been.
//
Time due;
Time death_mark;
if (vtv->ConsumeDeathClock(&death_mark))
{
Scalar gap = vtv->GetLastPerformance() - death_mark;
const Scalar quantum = (Scalar) 0.5;
int cells = (int)((gap + (Scalar) 1.0) / quantum) + 1;
due = death_mark;
due += quantum * (Scalar) cells;
}
else
{
due = vtv->GetLastPerformance();
due += 1.0f;
}
vtv->ScheduleRespawn(
message->dropZoneLocation, due,
(goalEntity != NULL)
? goalEntity->localOrigin.linearPosition
: Point3D(0.0f, 0.0f, 0.0f),
(goalEntity != NULL) ? True : False);
respawnScheduled = True;
//
// Under the trace, say what was scheduled in run-comparable
// terms: the pad (identity by position), and how far ahead of
// the vehicle's clock the due time sits. Two runs that disagree
// here diverge before the physics gets a vote.
//
{
static int diag = -1;
if (diag < 0)
{
const char *setting = getenv("RP412PHYSTRACE");
diag = (setting != NULL && atoi(setting) != 0) ? 1 : 0;
}
if (diag)
{
char buffer[160];
sprintf(buffer,
"PhysTrace: respawn #%d scheduled, pad %.2f,%.2f "
"due in %.4f sim-s\n",
deathCount,
(double) message->dropZoneLocation.linearPosition.x,
(double) message->dropZoneLocation.linearPosition.z,
(double)(Scalar)(due - vtv->GetLastPerformance()));
DEBUG_STREAM << buffer << std::flush;
}
}
}
Time when = Now();
when += 1.0f;
application->Post(HighEventPriority, this, message, when);
@@ -422,6 +512,7 @@ void
}
AlwaysExecute();
deathCount = 0;
respawnScheduled = False;
}
//
@@ -467,6 +558,26 @@ void
{
VTV *vtv = (VTV*)playerVehicle;
Check(vtv);
//
// A SCHEDULED respawn means the vehicle already holds - or has
// already applied - its teleport and goal-flip, on its own step
// grid. Resetting it AGAIN here, at whatever wall instant this
// message came off the queue, would re-teleport it mid-step and
// put the nondeterminism straight back.
//
// The flag, not "is fixed stepping on": this same leg also runs
// for the FIRST spawn of the mission, where the Reset below is
// what wakes a Mover out of its initial stasis. Gating on the
// mode alone skipped that wake-up and parked the pod, frozen at
// exactly its spawn point, for an entire race.
//
if (respawnScheduled)
{
respawnScheduled = False;
Check_Fpu();
return;
}
vtv->Reset(message->dropZoneLocation, VTV::RegularReset);
}