From df1b4651b3bc911934ab1626913d013e2a57bc4a Mon Sep 17 00:00:00 2001 From: Joe DiPrima Date: Sun, 9 Aug 2026 12:22:15 -0500 Subject: [PATCH] #137 CALIBRATION SETTLED: the myomer heat math is faithful -- constants read byte-exact Read the integrator's constants from .rdata rather than inferring them. Row ` 4b8ee0 5dc30000 0000003f 00000000 0000803f` gives: _DAT_004b8ee4 = 0.5f the kinetic half (work = mass * |v|^2 * 0.5) _DAT_004b8ee8 = 0.0f the Abs() idiom zero _DAT_004b8eec = 1.0f the (1 - efficiency) complements + gear clamp floor All three are exactly what the port computes, and the logged terms reproduce from the authored tuning to the digit: work = 75000 * 54^2 * 0.5 = 109.3e6 complement = 1 - VelocityEfficiency(0.995) = 0.005 termKinetic = 109.3e6 * 0.005 * (dt*28 = 0.728) = 398e3 (logged 399003) THE ONE DEVIATION IS DELIBERATE AND IS THE FAITHFUL CHOICE. The binary applies NO time_slice to the kinetic term (`fVar5 * fVar1`) while climb and accel both carry param_2 -- a per-frame energy add at the pod's FIXED ~28 Hz. The port's `work * (time_slice * 28)` is identical at 28 Hz (dt*28 = 1.0) and holds the same heat-per-SECOND at any frame rate. Transcribing it literally would add the full term once per frame, so at Oracle's measured 170 fps it would inject ~6x the heat the pod ever did. Preserving behaviour beats preserving the artifact of a fixed timestep. BT_MYO_HZ still brackets the reference rate. SO #137 IS NOT A CALIBRATION DEFECT. Heat is QUADRATIC in speed, so v~50 on open ground after a respawn is ~9x the input of v~10-18 in a fight -- which is why the overshoot correlates with respawns without being caused by them. It is also self-limiting: effectiveness reaches 0, the mech stops, speed falls, it cools. That is the authentic governor. Whether the cliff is too punishing for players is a DESIGN call for the operator, not a fidelity bug. Recorded in context/subsystems.md so the next reader does not re-litigate the dt-normalisation as a bug. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_018SgmXGNMXavXiafKXf9MDC --- context/subsystems.md | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/context/subsystems.md b/context/subsystems.md index aa62e87..c2b4441 100644 --- a/context/subsystems.md +++ b/context/subsystems.md @@ -299,3 +299,30 @@ the `BTGetSubsystemAuxScreen` bridge. See `docs/VEHICLE_SUBSYSTEMS.md` + [[gauge - Data: [[decomp-reference]] (ClassIDs/hierarchy). Bugs: [[reconstruction-gotchas]]. - Feeds: [[combat-damage]] (weapons/damage), [[gauges-hud]] (attribute state). - Plan: `docs/SUBSYS_PLAN.md`. + +## Myomer drive-heat calibration — VERIFIED FAITHFUL (2026-08-09, #137) [T1] +The integrator `@004b8d18` accumulates into `pendingHeat@0x1C8`: +`gear² × (1 + X) × [ (1−velEff)·|vy|·m·g·dt + (1−velEff)·work + (1−accEff)·|v|·|a|·m·dt ]` +with `work = mass · |v|² · 0.5`. Its constants, read byte-exact from `.rdata` +(`section_dump.txt` row ` 4b8ee0 5dc30000 0000003f 00000000 0000803f`): +**`_DAT_004b8ee4` = 0.5f** (the kinetic ½), **`_DAT_004b8ee8` = 0.0f** (the `Abs()` idiom), +**`_DAT_004b8eec` = 1.0f** (the `1 − efficiency` complements and the gear-ratio clamp floor). +All three match what the port computes — the formula and its authored inputs +(VelocityEfficiency 0.995, AccelerationEfficiency 0.8, thermalMass 2.5e5, myomers linked +Condenser5) are reconstructed correctly. + +**The one deliberate deviation, and why it is the faithful choice.** The binary applies **no +`time_slice`** to the kinetic term (`fVar5 * fVar1`) while the climb and accel terms both carry +`param_2` — it is a per-frame energy add at the pod's **fixed ~28 Hz**. The port uses +`work × (time_slice × 28)`, which is *identical* at 28 Hz (`dt·28 = 1.0`) but holds the same +heat-per-SECOND at any frame rate. A literal transcription would add the full term once per +frame, so at 170 fps it would inject ~6× the heat the pod ever did. `BT_MYO_HZ` overrides the +reference rate for bracketing. + +**Consequence for #137:** the heat model is not miscalibrated. Myomers running away past +`failT=2000` at sustained top speed is the authentic governor — heat is **quadratic in speed** +(`work = m·v²·0.5`), so v≈50 on open ground after a respawn is ~9× the input of v≈10-18 in a +fight. It is self-limiting: effectiveness hits 0, the mech stops, speed falls, it cools. What +players read as "respawned with the heat bar maxed" is that acceleration to top speed, not a +failed reset ([[combat-damage]] · the reset itself is verified: `T == startingTemperature` at +every reset). Whether the cliff is too punishing is a DESIGN call, not a fidelity defect.