BT411/context/glass-cockpit.md

id, title, status, source_sections, related_topics, key_terms, open_questions

id	title	status	source_sections	related_topics	key_terms	open_questions
glass-cockpit	Glass Cockpit — the desktop developer layer (BT_GLASS / BT_STEAM)	living	plan 2026-07-17; CMakeLists.txt gates; BT412 prior art (reference only)	pod-hardware build-and-run multiplayer gauges-hud	PadRIO miniconsole glass-cockpit

Glass Cockpit — the desktop developer layer

Purpose: developer tooling so game developers can test their work WITHOUT booting a Tesla II pod — and stay far enough out of the game that nothing a real pod requires can break. NOT a consumer product (GDI-grade UI is the ceiling). Pod fidelity outranks desktop convenience in every trade-off.

The compile gates (the ONLY compile-time feature gates in the tree)

Gate	Default	Adds
BT_GLASS	OFF	PadRIO input (XInput+keyboard), on-screen cockpit button panel, desktop plasma window, glass platform preset, miniconsole mission launcher
BT_STEAM	OFF (requires BT_GLASS)	Steam transport (ISteamNetworkingSockets) + ISteamMatchmaking lobby

• A no-flags configure is the pure pod game — the build of record. cmake options are cached, so a developer configures a build/ with -DBT_GLASS=ON once.
• Build dirs: build-pod/ (defaults, purity), build/ (dev, glass ON), build-steam/ (ON/ON).
• Convention: BT_GLASS/BT_STEAM are compile gates; every other BT_* name is a RUNTIME env gate (BTEnvOn) — do not add compile gates without updating this file.
• No weak-linkage/optional symbols — /FORCE turns unresolved externals into runtime AVs (reconstruction-gotchas); gated calls must be structurally present-or-absent at compile time.

Plan of record (2026-07-17)

Working branch glass-cockpit (from master e2c21c4). Steps: (1) gates+scaffolding [THIS], (2) PadRIO glass cockpit, (3) miniconsole self-launch, (4) Steam transport+lobby. Full plan: the approved plan file; running detail: docs/GLASS_COCKPIT.md. The retired BT412 trees (C:\VWE\BT412; local branch local-abandoned-20260717) are read-only reference — no code is copied from them.

Status

• Step 1 (gates + scaffolding): DONE 2026-07-17. CMake options + defines; 3-config configure matrix + negative test + defaults build verified.
• Step 2a (.CTL id audit): DONE 2026-07-17 [T2]. The streamed .CTL positional ids landed every MechControlsMapper record ONE MEMBER LATE (our chain starts at 2, the binary's at 3) — a latent REAL-POD bug (RIO throttle would drive pedalsPosition), masked on dev boxes by the keyboard bridge. Fixed ungated: ids pinned to binary numbering + id-2 pad + static_assert locks (mechmppr.hpp/.cpp); torso/weapon chains were already aligned. Permanent env-gated diagnostic: BT_CTRLMAP_LOG=1 dumps every streamed record's resolved member offset (L4CTRL.cpp CreateStreamedMappings). Full evidence: docs/GLASS_COCKPIT.md §2a.
• Step 2 (PadRIO glass cockpit): DONE 2026-07-17 [T2]. RIOBase seam (L4RIO.h, unconditional) + gated L4CONTROLS=PAD → PadRIO (L4PADRIO.* XInput+keyboard, L4PADBINDINGS.* content\bindings.txt); bridge stand-downs auto-yield to a live device (BTRIODevicePresent, BT_KEY_BRIDGE unset=auto/0=off/1=on); on-screen panel L4PADPANEL.* follows vRIO (C:\VWE\vrio CockpitLayout/PanelCanvas — 104 controls incl. the two hex keypads → real KeyEvents; right-click latch); desktop plasma L4PLASMAWIN.* (L4PLASMA=SCREEN, buffer is top-down); -platform glass preset + run.cmd token. Secondary displays reuse the EXISTING dev-gauge modes (dock / BT_DEV_GAUGES_WINDOW=1 window / _DOCK=1 overlay — gauges-hud); no new MFD code, no L4VB16.cpp exposure. Button-trap guard: base ConfigureMappableMessageHandler no longer abort()s by default (BT_BUTTON_TRAP=1 restores) — each [FAIL] log = a missing L4 override to reconstruct. Verified: authentic-path input (engine push → streamed .CTL → mapper), panel-click survival, 2-node loopback MP un-regressed on the pod build. Detail: docs/GLASS_COCKPIT.md.
• Step 3 (miniconsole): DONE 2026-07-17 [T2]. game/glass/btl4fe.* (menu + console-shape egg writer, golden-tested vs MP.EGG) + btl4console.* (the marshal: a worker-thread console CLIENT speaking the btconsole.py wire verbatim; content\marshal.log). ZERO engine hooks — the engine runs the stock console ladder. Per-mission process relaunch; BT_FE_* env arms the marshal (menu relaunches clear it). Verified: solo cycle (menu→mission→60s clock→stop→menu) and menu-hosted 2-node LAN.
• Step 4 (Steam): CODE COMPLETE 2026-07-18 [T2 single-machine]. See steam-networking — the wire seam + L4STEAMNET identity-token transport + btl4lobby. Live 2-account cross-machine session pending (docs/STEAM_TEST.md).

Key Relationships

• Extends: pod-hardware (RIO input path) · Uses: gauges-hud dev-gauge modes · Feeds: multiplayer (miniconsole hosting, Steam transport) · Build: build-and-run