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
