#137 FIXED: restore the binary Reset's +0x58c re-seed -- the respawn freeze was a

teleport-poisoned finite difference, not heat, not the reset, not velocity

The one-line fix is the binary's own SECOND Reset instruction, dropped in
transcription:  FUN_00408440(mech+0x58c, param_2)  ==
    accelPrevPos = origin.linearPosition;
+0x58c is the previous-position memory of the AccelerationLastFrame ring feed
(+0x81c/0x824/0x828/0x82c).  The port reconstructed the ring faithfully (ctor
part_012.c:9836, derivative :15169) but Reset never re-seeded its cache, so the
first post-respawn sample computed |newPos - prevPos|/dt = TELEPORT DISTANCE/dt
(~1e5) into the velocity ring; the ring-mean derivative spiked
AccelerationLastFrame (pure forward, with an opposite-sign echo ~15 frames later
as the sample rotated out of the 15-ring); and the myomer integrator @004b8d18
turned it into a one-tick pendingHeat deposit of ~3e9:
    termAccel = (1-accEff) * |v| * |a| * m * dt
      = 0.2 * 40 * 1.04e5 * 75000 * 0.044  =  2.75e9
snapping the freshly-reset myomers from T=77 to T~9000 against failT=2000 ->
speedEffect 0 -> speedDemand *= 0 -> "respawned unable to move until it cools".

WHY ~8% IN THE FIELD: the deposit needs |v| in the same 1-2 frames, so only
pilots whose throttle was still forward at the respawn -- physical lever /
HOTAS, exactly who reported it -- had gait-republished speed in the spike
frames.  Idle-throttle respawns deposit ~nothing.  (And frozen-subset-of-
died-hot: died hot == was running hard == lever still forward.)

MEASURED, same abusive bench (0.95 throttle + continuous autofire):
    before: deposits up to 3.35e9, every one 3-4 lines after a Mech::Reset;
            4-6 of 7 respawns frozen; post-reset myomers T 7700-12100
    after:  deposits >1e7: ZERO across 7 respawns; frozen: ZERO;
            post-reset myomers T 77-178 (vs degradeT=1000)

THEORIES KILLED ON THE WAY, each by operand data, in order:
  * stale pendingHeat carryover (bounded to 1 frame, +1.2K -- gates agent)
  * slow accumulation during the death window (consumers tick the wreck)
  * conduction from a hot neighbour (roster-wide snapshot: ALL partners 77;
    flow trap: zero e6 flows into the myomers, ever)
  * drag/impulse writers (both trapped: never fired)
  * my own earlier "velocity-driven, players accelerate to top speed" close of
    the ticket -- arithmetically impossible (input ceiling ~6.5e5/frame ~=
    60 deg/s; the observed snap was 1,100-21,000 deg/s) and corrected in
    context/subsystems.md, which carried the wrong paragraph.
  * the localAcceleration zero-fill (+0x1dc) restored along the way is KEPT --
    the binary does it -- but it was NOT the cause; the snapshot is rebuilt
    from the position difference one frame later.

Probes kept (all BT_HEAT_LOG-gated): roster-wide [myofreeze] at-death/at-reset/
post-reset (T + heatEnergy + pendingHeat per subsystem), the [heatflow]
conduction trap with full operands, the [myodep] deposit trap with mech
identity + acceleration components.  Engine MOVER.cpp traps reverted -- they
proved their negative (drag/impulse innocent) and do not belong in engine
source.

Gotcha #30 records the class: when the binary's Reset writes a cell you don't
recognize, that write IS the spec -- transcribe the whole zero/seed list; any
prev-value cell backing a finite difference must be re-seeded at every
teleport; and derived state (T) sampled at the reset proves nothing about the
backing producers.

The operator called the shape of this two days ago: "maybe the math gets screwy
in respawning while some systems are ticking while values are being reset."
That is precisely what it was.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018SgmXGNMXavXiafKXf9MDC
This commit is contained in:
Joe DiPrima
2026-08-09 16:19:36 -05:00
co-authored by Claude Opus 5
parent df1b4651b3
commit 0d6ed40db9
5 changed files with 163 additions and 27 deletions
+50 -20
View File
@@ -947,6 +947,26 @@ void
if (other != 0 && coolantAvailable != 0)
{
Scalar flow = ComputeHeatFlow(other, time_slice); // FUN_004ad9ec
// #137 FLOW TRAP (BT_HEAT_LOG): the myomers gains ~2e9 of energy within
// 30 frames of a respawn while every partner reads T=77 -- and the only
// writers into its pendingHeat are its (dead-at-spawn) integrator and
// THIS line. Any e6-scale single flow is the bug caught in the act;
// print the complete operand set so the arithmetic can be re-run by
// hand instead of guessed at.
if (getenv("BT_HEAT_LOG") != 0 && (flow > 1.0e6f || flow < -1.0e6f))
{
DEBUG_STREAM << "[heatflow] " << (GetName() ? GetName() : "?")
<< " -> " << (other->GetName() ? other->GetName() : "?")
<< " flow=" << flow << " dt=" << time_slice
<< " | this: T=" << currentTemperature << " E=" << heatEnergy
<< " pend=" << pendingHeat << " m=" << thermalMass
<< " mScale=" << massScale << " k=" << thermalConductance
<< " lvl=" << coolantLevel << " cap=" << thermalCapacity
<< " fScale=" << coolantFlowScale
<< " | other: T=" << other->currentTemperature
<< " E=" << other->heatEnergy << " pend=" << other->pendingHeat
<< " m=" << other->thermalMass << "\n" << std::flush;
}
other->pendingHeat += flow;
pendingHeat -= flow;
BalanceCoolant(time_slice); // FUN_004ada94
@@ -1523,28 +1543,38 @@ void BTReportMyomerFreeze(void *mech_v, const char *when)
Subsystem *s = mech->GetSubsystem(i);
if (s == 0)
continue;
Scalar f = BTMyomersSpeedEffectOf(s);
if (f < -0.5f)
continue; // not a Myomers
// ROSTER-WIDE now (2026-08-09): the myomers-only version proved the
// myomers is being COOKED FROM OUTSIDE -- +2.3e9 of energy arrives in
// <=30 frames while its own integrator reads near-zero v (our Reset
// zeroes localVelocity, matching the binary's +0x1c4 zero-fill, so
// termKinetic/termAccel are dead at spawn). ConductHeat flow is
// bounded by deltaT, so an e9 slug through it demands a NEIGHBOUR at
// extreme temperature. Print EVERY heat-bearing subsystem's T plus
// the two cells T is actually derived from (heatEnergy @0x158,
// pendingHeat @0x1C8) to NAME that neighbour.
if (!s->IsDerivedFrom(*HeatableSubsystem::GetClassDerivations()))
continue;
HeatableSubsystem *h = (HeatableSubsystem *)s;
// Every Heatable-positive roster member in this game IS a HeatSink
// (the Watcher branch -- Torso/HUD/Gyro -- rides HeatWatcher, which is
// not HeatableSubsystem-derived), so the downcast for E/pend is safe.
// Deliberately NOT IsDerivedFrom(HeatSink): that hand-built chain
// returns false for Condenser (the night-13 trap).
HeatSink *hs = (HeatSink *)s;
Scalar f = BTMyomersSpeedEffectOf(s); // >= 0 only for a Myomers
if (f > best) best = f;
Scalar t = -1.0f, tdeg = -1.0f, tfail = -1.0f;
if (s->IsDerivedFrom(*HeatableSubsystem::GetClassDerivations()))
{
HeatableSubsystem *h = (HeatableSubsystem *)s;
t = h->currentTemperature; // @0x114
tdeg = h->degradationTemperature; // @0x118
tfail = h->failureTemperature; // @0x11C
}
// The derating curve (@004b8ac0) is exactly:
// temp >= degradation -> falls off; temp >= FAILURE -> 0.0 (frozen).
// So printing the thresholds beside the temperature says immediately
// whether a 0 effectiveness is JUSTIFIED by the temperature (reset did
// not take / re-heated) or is a STALE cache (temp fine, effect still 0).
DEBUG_STREAM << "[myofreeze] " << when << " " << (s->GetName() ? s->GetName() : "?")
<< " T=" << t << " deg=" << tdeg << " fail=" << tfail
<< " speedEffect=" << f
<< (f <= 1.0e-4f && t < tfail ? " <<<< STALE (cold but zero)" : "")
<< "\n" << std::flush;
<< " T=" << h->currentTemperature
<< " E=" << hs->heatEnergy
<< " pend=" << hs->pendingHeat
<< " fail=" << h->failureTemperature;
if (f >= 0.0f)
{
DEBUG_STREAM << " speedEffect=" << f
<< ((f <= 1.0e-4f && h->currentTemperature < h->failureTemperature)
? " <<<< STALE (cold but zero)" : "");
}
DEBUG_STREAM << "\n" << std::flush;
}
if (best >= 0.0f)
DEBUG_STREAM << "[myofreeze] " << when << " CHAIN MAX=" << best