Build: the BT_GLASS/BT_STEAM compile gates -- glass-cockpit dev-layer scaffolding

Step 1 of the desktop developer layer: option(BT_GLASS OFF) + option(BT_STEAM OFF)
(BT_STEAM requires BT_GLASS, configure-time FATAL_ERROR), defines flow to all three
targets via BT_DEFS. Defaults build = the pure pod game, verified: 3-config configure
matrix + negative test + defaults Debug build (known mech3 /FORCE externals only).
New topic context/glass-cockpit.md + ledger docs/GLASS_COCKPIT.md; router rows added.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Cyd
2026-07-17 21:48:35 -05:00
co-authored by Claude Fable 5
parent e2c21c4db2
commit 3f49915d76
5 changed files with 108 additions and 1 deletions
+54
View File
@@ -0,0 +1,54 @@
---
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: [".CTL positional-attribute off-by-one — audit pending (step 2a)"]
---
# 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): IN PROGRESS 2026-07-17.** CMake options + defines land with
this file; gated `target_sources` blocks are added as each TU lands.
- Step 2 (PadRIO + displays): pending. Secondary displays reuse the EXISTING dev-gauge modes
(dock-bottom `BT_DEV_GAUGES=1`, combined separate window `BT_DEV_GAUGES_WINDOW=1`, overlay
inset `BT_DEV_GAUGES_DOCK=1` — see [[gauges-hud]] + `docs/GAUGE_COMPOSITE.md`); NO new MFD
display code, never re-enter the `L4VB16.cpp` split-view region.
- 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]]