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
@@ -118,6 +118,20 @@ The authentic pod throttle path — traced 2026-07 (task #50 throttle-fidelity q
|
||||
binary's 3) — every streamed record landed one member late (a real-pod landmine: the RIO
|
||||
throttle scalar drove `pedalsPosition`). Ids are now PINNED to the binary numbering with an
|
||||
id-2 pad + `static_assert` locks (`mechmppr.hpp/.cpp`); audit tool `BT_CTRLMAP_LOG=1`.
|
||||
**⚠ The streamed BUTTON mappings (like record [2]) are NOT CONSUMED yet** — the SCALAR records
|
||||
drive their attributes, but `MechControlsMapper::AddOrErase` (both overloads, @004b02b0/
|
||||
@004b02d4) is still the unreconstructed `Fail("Unhandled mapping!")` stub, so a streamed
|
||||
button never reaches its attribute. Consequence found the hard way (user report 2026-07-24,
|
||||
"i cant seem to reverse"): **REVERSE THRUST was dead on the desktop.** LALT→0x3F was bound and
|
||||
PadRIO pushed the RIO ButtonPressed event correctly, but nothing applied it to attr 6, and the
|
||||
only writer of `reverseThrust` was the keyboard bridge's `key_throttle < 0` test — which is
|
||||
(a) bypassed whenever a RIO is operational (the pad RIO always is, so the bridge is OFF on the
|
||||
desktop) and (b) unreachable anyway, since `L4PADRIO` clamps the Throttle channel to **[0,1]**
|
||||
(`low = 0.0f`). Fixed by publishing the 0x3F hold state from `PadRIO::EmitButton` (the single
|
||||
chokepoint keyboard/pad/joystick/glass clicks all share) and applying it in
|
||||
`InterpretControls`, **gated on `BTPadRIOActive()`** so pod hardware is untouched — marked
|
||||
[T3], delete when streamed button mappings land. Verified: hold LALT ⇒ `rev=1`,
|
||||
`speedDemand −61.5`; release ⇒ forward. Reverse is a **HOLD**, per the manual. [T2]
|
||||
Details: `docs/GLASS_COCKPIT.md` §2a; see [[glass-cockpit]].
|
||||
4. **Interpretation:** `L4MechControlsMapper::InterpretControls` @004d196c applies the ONLY software
|
||||
detent — snap to 1.0 when |t−1.0| ≤ 0.05 — then `MechControlsMapper::InterpretControls` @004afd10
|
||||
|
||||
Reference in New Issue
Block a user