arcattackandClaude Opus 4.8
4215b98655
The user held the MFD PROGRAM button and nothing happened (weapons kept
firing). Diagnosis, verified end-to-end:
- The cockpit mouse handler DID register the click ([cockpit] CLICK addr=0x8
press) and 0x8 IS a streamed PROGRAM element (EVENT msg 0x9 -> weapon,
Mfd1 quad page mask).
- But every launch ran the DEV platform profile (no BT_PLATFORM) ->
L4CONTROLS=KEYBOARD -> no PadRIO instance -> PadRIO::SetScreenButton
no-ops (activeInstance NULL) -> the press never entered the RIO queue ->
ConfigureMappables (id 9) never dispatched -> the mode never flipped ->
fire keys kept firing. The config machinery itself was never broken.
- With BT_PLATFORM=glass (the GLASS profile: L4CONTROLS=PAD -> PadRIO), the
full chain now proves out headlessly:
[btntest] PRESS 0x8 -> [cfgmap] ENTER session on ERMLaser_1
mode 0x450421 -> 0x448421 (NonMapping 0x10000 -> Mapping 0x8000)
[btntest] RELEASE 0x8 -> [cfgmap] EXIT (mode restored)
Landed:
- mechweap.cpp: [cfgmap] BT_FIRE_LOG diagnostics in the real
ConfigureMappables/ChooseButton handlers (they were silent -- the G-key
harness had logs but the authentic button path had none).
- L4PADRIO.cpp: BT_BTNTEST="addr,pressPoll,releasePoll" scripted screen-
button harness through the REAL click seam (EmitButton -> RIO queue ->
manager drain -> buttonGroup mapping) for headless verification.
- play_solo.bat: prefer the glass build when present AND set
BT_PLATFORM=glass so PadRIO exists and cockpit clicks work.
Side finding (the user's keymap "flip-flop"): CONTROLS.MAP (btinput, DEV/pod
profile) and bindings.txt (PadRIO, GLASS profile) are two parallel binding
engines; which one runs depends on the platform profile, so the felt keymap
changes with the boot flavor. Unification pending (user decision).
Awaiting live verification of the full hold-PROGRAM + tap-fire regroup flow.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
45 lines
1.7 KiB
Batchfile
45 lines
1.7 KiB
Batchfile
@echo off
|
|
rem BT411 -- single-player practice (no network, no operator).
|
|
rem Edit the -egg below for other maps (ARENA2/DBASE/FOGDAY/...).
|
|
cd /d %~dp0
|
|
rem Prefer the GLASS build when present (dev checkout): it carries PadRIO, the
|
|
rem click-to-button seam that makes the cockpit surround's MFD red buttons,
|
|
rem radar rails and joystick buttons mouse-clickable (trigger config needs
|
|
rem this). The pod build renders the same cockpit but its clicks are a no-op
|
|
rem (PadRIO is not compiled there); player zips ship only build\.
|
|
set GAME=build\Release\btl4.exe
|
|
if exist "build-glass\Release\btl4.exe" (
|
|
set GAME=build-glass\Release\btl4.exe
|
|
rem The GLASS platform profile is what creates PadRIO (L4CONTROLS=PAD):
|
|
rem without it the boot falls to the DEV profile (KEYBOARD only) and every
|
|
rem cockpit click is silently discarded -- trigger config dead, keymap on
|
|
rem the btinput/CONTROLS.MAP engine instead of PadRIO/bindings.txt.
|
|
set BT_PLATFORM=glass
|
|
)
|
|
if not exist "%GAME%" goto badpath
|
|
if not exist "content\OPERATOR.EGG" goto badpath
|
|
set BT_START_INSIDE=1
|
|
set BT_DEV_GAUGES=1
|
|
set BT_LOG=join.log
|
|
cd content
|
|
..\%GAME% -egg ARENA1.EGG
|
|
echo.
|
|
echo The game has exited. If it closed unexpectedly,
|
|
echo send the operator content\join.log.
|
|
pause
|
|
exit /b
|
|
:badpath
|
|
echo.
|
|
echo ==================================================
|
|
echo ERROR: this file is not in the right place.
|
|
echo.
|
|
echo It must sit in the EXTRACTED game folder, next to
|
|
echo the 'content' and 'build' folders.
|
|
echo.
|
|
echo Fix: right-click the .zip - Extract All, open the
|
|
echo extracted folder, and run this file from THERE.
|
|
echo (Do NOT run it from inside the zip.)
|
|
echo ==================================================
|
|
echo.
|
|
pause
|