Half of IntegrateMotion's job, taken now because two findings made it safe:
THE GAIT SLEW RATE IS THE AUTHORED ACCELERATION. The binary's ctor sets
forwardCycleRate, gimpCycleRate and groundCycleRate all from the model's
maxAcceleration (rec+0x44 -- 30 for the Mad Cat) and airborneCycleRate from
superStopAcceleration. That closes both of yesterday's unsourced-rate
worries at once: the ctor default of 1.0 (which would have taken ~27 seconds
to reach speed) is retired, and replacing the explicit acceleration model
with the stride rate preserves drive feel EXACTLY -- same slew rate, same
demand, different (authentic) path for the value to travel.
SO: Simulate now takes currentBodySpeed = bodyStride / dt, the binary's own
relationship (IntegrateMotion @004ab1c8: local velocity z = -distance/dt).
The old acceleration model survives only as a [T3] fallback for a model with
no gait clips at all, so unverified fleet mechs stay drivable.
LIVE CURVE, arena run, no fault:
spd = 7.32 stepping off (stand->walk clip)
spd = 26.67 22.16 27.31 30.54 ... the run cycle around the demanded 26.9
The old model pinned spd at exactly 26.9022 every frame. Now the mech steps
off slow and its hull speed oscillates within each stride -- heel-strike vs
mid-swing. Cadence in the motion is not noise; it is the point. The mech is
carried by its animation, which is what "the gait IS the locomotion" meant in
the 1995 design.
Also queued a correction from the raw decomp: IntegrateMotion's replicant
branch writes +0x598 with a VECTOR op, so motionEventName is likely a Point3D
rather than the CString the BT411 member map suggested -- flagged in the
sidecar for the dead-reckon increment rather than churned now.
Still staged from IntegrateMotion: the airborne pick, the dead-reckon fold,
the orientation integration, the turn-in-place dispatcher.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
CydandClaude Fable 5
c578a9b790