Reverse thrust was dead on the desktop (user report): wire the 0x3F throttle-handle button
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
This commit is contained in:
co-authored by
Claude Opus 5
parent
6c3fca2f67
commit
23229e573e
@@ -763,7 +763,29 @@ void
|
||||
}
|
||||
}
|
||||
throttlePosition = (key_throttle >= 0.0f) ? key_throttle : -key_throttle;
|
||||
reverseThrust = (key_throttle < 0.0f) ? 1 : 0;
|
||||
//
|
||||
// REVERSE THRUST -- the pod's red throttle-HANDLE button (RIO unit
|
||||
// 0x3F, LALT on the keyboard), NOT a lever sweep through zero. The
|
||||
// authentic wiring is BTL4.RES's "L4" streamed record [2]:
|
||||
// `Button Throttle1 (0x3F) -> attr 6 ReverseThrust@0x124`, and the
|
||||
// 1995 manual says HOLD it (release = forward) -- see
|
||||
// context/pod-hardware.md.
|
||||
//
|
||||
// This line used to read ONLY the negative-throttle case, which is
|
||||
// unreachable on the desktop: L4PADRIO clamps the Throttle channel to
|
||||
// [0,1] (see its "low = 0.0f" clamp), so key_throttle never goes
|
||||
// negative -- and because the bridge owns reverseThrust EVERY frame,
|
||||
// it also zeroed the flag right back out even when the streamed
|
||||
// button mapping had set it. Net effect: Alt did nothing.
|
||||
// (User-reported 2026-07-24, "i cant seem to reverse".)
|
||||
//
|
||||
// The negative-throttle term stays for the headless harnesses, which
|
||||
// drive forcedThrottle directly and CAN go negative.
|
||||
//
|
||||
{
|
||||
extern int gBTReverseHeld; // L4PADRIO::EmitButton (any 0x3F source)
|
||||
reverseThrust = (gBTReverseHeld || key_throttle < 0.0f) ? 1 : 0;
|
||||
}
|
||||
// (task #68) look-behind: hold 'V' = the pod's rear-view button.
|
||||
// (The other look buttons stay unbound on the keyboard rig.)
|
||||
{
|
||||
@@ -867,6 +889,35 @@ void
|
||||
<< mech->forwardThrottleScale << " -- healed to 1.0" << "\n" << std::flush;
|
||||
mech->forwardThrottleScale = 1.0f;
|
||||
}
|
||||
//
|
||||
// REVERSE THRUST on the DESKTOP. The authentic wiring is BTL4.RES's "L4"
|
||||
// streamed record [2]: `Button Throttle1 (0x3F, the red button on the throttle
|
||||
// handle) -> attr 6 ReverseThrust@0x124`, held for reverse / released for
|
||||
// forward (context/pod-hardware.md, manual-verified). PadRIO publishes that
|
||||
// button's hold state from EmitButton -- the one chokepoint every desktop
|
||||
// source funnels through (keyboard LALT, gamepad, DirectInput joystick, glass
|
||||
// panel click) -- but our streamed BUTTON mappings are not consumed yet
|
||||
// (MechControlsMapper::AddOrErase is still the unreconstructed Fail stub), so
|
||||
// the event never reaches attr 6 on its own. Apply it here, gated on the pad
|
||||
// RIO being the live device so REAL POD hardware is untouched (there
|
||||
// BTPadRIOActive() is 0 and the streamed mapping owns the flag).
|
||||
//
|
||||
// This is why LALT did nothing: the only writer was the keyboard bridge's
|
||||
// `key_throttle < 0` test, which (a) is bypassed entirely whenever a RIO is
|
||||
// operational -- which the pad RIO always is -- and (b) can never fire anyway,
|
||||
// because L4PADRIO clamps the Throttle channel to [0,1].
|
||||
// [T3 accommodation, marked: delete this block once streamed button mappings
|
||||
// land, at which point record [2] drives attr 6 by itself.]
|
||||
//
|
||||
{
|
||||
extern int BTPadRIOActive(void);
|
||||
extern int gBTReverseHeld;
|
||||
if (BTPadRIOActive())
|
||||
{
|
||||
reverseThrust = gBTReverseHeld ? 1 : 0;
|
||||
}
|
||||
}
|
||||
|
||||
if (reverseThrust < 1)
|
||||
{
|
||||
speedDemand =
|
||||
|
||||
Reference in New Issue
Block a user