---
id: glass-cockpit
title: "Glass Cockpit — the desktop developer layer (BT_GLASS / BT_STEAM)"
status: living
source_sections: "plan 2026-07-17; CMakeLists.txt gates; BT412 prior art (reference only)"
related_topics: [pod-hardware, build-and-run, multiplayer, gauges-hud]
key_terms: [PadRIO, miniconsole, glass-cockpit]
open_questions: []
---
# 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): pending. Architecture: the console stays a WIRE PEER — an in-process
  worker-thread console client over loopback; no engine-loop hooks.
- Step 4 (Steam): pending.

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