LALT -> button 0x3F was bound in both binding layers and PadRIO pushed the RIO
ButtonPressed event correctly, but nothing ever set the mapper's ReverseThrust:
- the authentic route is BTL4.RES 'L4' streamed record [2] (Button Throttle1
0x3F -> attr 6 ReverseThrust@0x124), but our streamed BUTTON mappings are
not consumed at all -- MechControlsMapper::AddOrErase is still the
unreconstructed Fail stub, so the event never reaches the attribute;
- the ONLY writer of reverseThrust was the keyboard bridge's
'key_throttle < 0' test, which is bypassed whenever a RIO is operational
(the pad RIO always is, so the bridge is OFF on the desktop) AND is
unreachable regardless, because L4PADRIO clamps the Throttle channel to
[0,1]. Net: Alt did nothing and the flag was re-zeroed every frame.
FIX: publish the 0x3F hold state from PadRIO::EmitButton -- the one chokepoint
every desktop source funnels through (keyboard, gamepad, DirectInput joystick,
glass-panel clicks via SetScreenButton) -- and apply it in InterpretControls
gated on BTPadRIOActive() so real pod hardware is untouched (there the streamed
mapping owns the flag). Marked [T3]; delete once streamed button mappings land.
Reverse is a HOLD (manual: hold the red throttle button, release = forward).
Verified with scratchpad/revtest.py (keybd_event injection, BT_KEY_NOFOCUS):
forward = rev=0 dmd +61.501; LALT held = rev=1 dmd -61.501; release edge logged.
KB: pod-hardware.md now records the streamed-button-mapping gap + this seam.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0166KTsC7ADm7VXEi1HF1jNg
