Controlled A/B on the same bench, only the load differs:
0.95 throttle + continuous missile autofire : 4 respawns, 17 frozen samples,
T climbs 77 -> ~11,600
0.50 throttle, no weapons : 2 respawns, ZERO post-reset
freezes; T stays ~77
So the respawn is exonerated on measurement, not on argument:
* the reset works -- T == startingTemperature at every reset, both runs;
* the stale Myomers::speedEffect (@0x31C, which no RTIS writes) is real but
self-heals on the next tick (T=77.13 -> speedEffect=1);
* with ordinary load the myomers never approach failT=2000 after a respawn.
WHAT PLAYERS ARE ACTUALLY SEEING. Overheat while running hard -> myomers pass
failT=2000 -> derating curve @004b8ac0 returns 0.0 -> chain MAX 0 ->
speedDemand *= 0 -> bogged down -> die (often BECAUSE bogged down). Respawn
correctly resets to 77. Resume high throttle + firing and it climbs back over
the cliff within seconds, which reads as "respawned with the heat bar maxed".
That is why it looks like a reset bug and why it is intermittent (~8% of
respawns in the field): it tracks how hard you were driving, not the respawn.
THE REMAINING DEFECT is the CLIMB RATE, not the reset. Blowing ~6x past a
cliff the design treats as coolant-managed (degradeT=1000 governor onset,
failT=2000) is not a lever a player can work with. Suspect under review: the
kinetic term. The binary (@004b8d18) applies NO time_slice to it --
`fVar5 * fVar1` -- while the climb and accel terms both carry param_2, i.e. it
is a per-frame energy add at the pod's fixed ~28 Hz. Our port rate-normalises
it (`work * (time_slice * 28)`), which agrees per-second at any frame rate, so
that is NOT yet a proven discrepancy -- it needs a term-by-term dump against
the authored tuning (VelocityEfficiency 0.995, AccelerationEfficiency 0.8,
thermalMass 2.5e5, myomers linked Condenser5 = Oracle's "loop 5").
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018SgmXGNMXavXiafKXf9MDC
