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
First reproduction of #137 in a bench. The reset path is exonerated and the
real defect is located, though not yet explained.
DECOMP RE-READ (what the reset actually does):
Mech::Reset @0049fb74 walks the roster from index 2 calling vtable +0x28
(slot 10 = ResetToInitialState), then @0049f788.
Myomers::RTIS @004b8aa4 -> PoweredSubsystem::RTIS @004b0e6c -> ALWAYS
HeatSink::RTIS @004ad760, whose first act is
param_1[0x45] = param_1[0x4f] // currentTemperature = startingTemperature
(byte 0x114 = 0x13C). Our port matches AND additionally resets heatEnergy,
which it must, since HeatSinkSimulation derives
currentTemperature = heatEnergy / thermalMass.
The freeze itself is the derating curve @004b8ac0:
temp >= degradation(@0x118) -> falls off
temp >= FAILURE(@0x11C) -> 0.0 -> chain MAX 0 -> speedDemand *= 0.
Nothing in the reset chain touches Myomers::speedEffect (@0x31C).
MEASURED (scratchpad/night14/myofreeze.sh -- hot mech, repeated self-kill):
at-reset Myomers T=77 deg=1000 fail=2000 speedEffect=0 <- stale
post-reset Myomers T=77.14 speedEffect=1 <- 1 frame
post-reset Myomers T=9297.8 fail=2000 speedEffect=0
post-reset Myomers T=11620.4 fail=2000 speedEffect=0
So, in order:
* THE RESET WORKS. T is exactly startingTemperature at the reset. My
original bench was right about that much; it just stopped looking there.
* THE STALE speedEffect IS REAL BUT HARMLESS -- it survives the reset (no
RTIS writes it) yet self-heals on the very next tick. Not the bug.
* THE MYOMERS THEN RUN AWAY: 77 -> ~11,600 against a FAILURE point of 2,000,
nearly 6x over, in seconds. That is not heat earned by running; that is a
runaway, and it is what pins speedDemand at 0 until it cools -- exactly
Oracle's "maxed heat bar ... unable to move until it cools off".
* Rate: 7 of 105 census samples over the failure temp (~6.7%), against the
field's 5-of-61 respawns (~8%). Same order, so the bench is reproducing
the field condition and not a bench artifact.
* The myomers link to Condenser5 (mass=250000 k=190000) -- literally Oracle's
"loop 5 and generator D heating up as all the excess heat goes into the loop".
NOT YET ESTABLISHED, and the reason this is a checkpoint and not a fix: whether
the runaway is CAUSED by the respawn or is a heat-model calibration problem that
merely CORRELATES with it (you die when you overheat, so respawns cluster around
hot periods). The bench drives at 95% throttle with continuous missile autofire,
which is abusive, and the [heat-t] census has no pre-first-reset samples to
compare against. Next step is to instrument the heat INPUT and diff a
respawn-adjacent window against a steady-running window.
Probe added: [myofreeze] prints T / degradation / FAILURE / speedEffect per
myomers plus the chain MAX the mover multiplies by, AT the reset and for ~4 s
after (armed by Mech::Reset, sampled where the multiplier is formed). The
post-reset window is what nothing was watching -- sampling only at the reset is
what made this look innocent and got the ticket wrongly closed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018SgmXGNMXavXiafKXf9MDC
Closed 5 confirmed-fixed (#52#108#140#141#142), commented 3 (#135#146#147), REOPENED#137, filed #149-#158.
#137 reopened because I closed it wrongly. Field scan of all four logs: 5 of
61 respawns froze (throttle up, speedDemand pinned at 0) across THREE machines
-- ~8%, which is why a bench that reset cleanly every time never saw it. The
myomers come up Overheating in the same breath as Mech::Reset, before any
running could earn the heat. Oracle's 'unable to move' was the detail that
disproved my 'it earns the heat by respawning under throttle' explanation.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018SgmXGNMXavXiafKXf9MDC
