Re-reading landed code against the decomp turned up a real defect.
Gyroscope::ApplyDamageTorque (binary @004b2de4) finished with
Vector3D::Negate, which flips all three components; the binary negates
ONLY x in place after zeroing y. So the z component of the body force
has carried the wrong sign on every damage shake and every collision
crunch since that function landed. Fixed. Flagged for the same
treatment: ApplyVerticalImpulse ends with bodyForce.y = bodyForce.x,
which wants its binary address found and checked.
The other half of the sitting is a decision NOT to land something. The
master perf's second census (@0049fe80) computes three damage means into
mech+0x354/8/c -- over the hull zones, over every subsystem's private
zone, and over the myomers' private zones (the same 0x51155c GUID the
mobility scan proved). A reader hunt found none: the apparent hits are
on OTHER objects at the same offsets, the gyro's damage multipliers and a
myomers cell, which is a good reminder that a bare offset grep proves
nothing when offsets are per-class. No attribute row binds them either.
Landing it would be three loops feeding dead memory, so it stays decoded
and recorded until a consumer turns up.
Regression soak: mobility scan, telemetry and drive all unchanged, zero
faults.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
CydandClaude Fable 5
f25abf1da5