BT_FORCE_TORSO sweeps the twist BUTTONS -- the members the streamed direct
mappings write -- so the chain runs without a hand on the RIO. Live on the
pod: twist sweeps -0.015 to -0.891 rad and back as cmdL/cmdR alternate, at
the resource rate 0.873 rad/s, inside the authored +/-2.443 limits, with
jointtorso resolved. End to end: attribute id -> direct-mapping destination
-> TorsoSimulation integrator -> skeleton joint -> the canopy eye hanging off
that chain. 5.3.68's table and 5.3.71's integrator both confirmed against
real button semantics.
Two buffer overruns, one of them mine. Reading TORSO.CPP back caught the
ctor still zeroing dynamicsState[22] after I shrank the array to [16] by
carving the command members out of its front: 24 bytes past the end of every
Torso, on the heap, every mission, since 5.3.68. A sweep for the same shape
across BT/BT_L4/MUNGA found a pre-existing one -- MECHMPPR.CPP zeroing
reserved[22] against reserved[21].
Both now bound by ELEMENTS(). The rule for this tree: any array carved out
of a reserve block must have its initialiser bound by ELEMENTS, because the
carve is exactly the edit that silently invalidates a literal.
Neither explains the residual host fault (it predates 5.3.68 at 3/3), but
both were real corruption running in every mission -- and the Torso one was
introduced by the very fix that cut the fault rate, which is worth
remembering whenever a rate MOVES instead of going to zero.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
CydandClaude Fable 5
3c289ff10a
