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

#137 CALIBRATION SETTLED: the myomer heat math is faithful -- constants read byte-exact

Browse Source 
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) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018SgmXGNMXavXiafKXf9MDC
This commit is contained in:
Joe DiPrima
2026-08-09 12:22:15 -05:00
co-authored by Claude Opus 5
parent 6a122f6cdf
commit df1b4651b3
1 changed files with 27 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
context/subsystems.md
+27
View File
@@ -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.