vwemirror/BT411
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Build: the BT412 compile gate -- one tree builds the pod game and the Steam game

Browse Source 
option(BT412 ... ON) gates the steamification layer for the merge-back into
BT411, so the unified repo serves both fronts:

- Default (BT412=ON): pod/dev game + PadRIO / plasma / front end / lobby --
  all runtime-gated, so a -egg/-net launch still behaves as 4.11.
- Pod-minimal (-DBT412=OFF, build-pod/): compiles OUT L4PADRIO, L4PADBINDINGS,
  L4KEYLIGHT, L4PLASMASCREEN, L4STEAMTRANSPORT, btl4fe, btl4console, btl4lobby.
  Seam sites carry #ifdef BT412: L4CTRL.cpp PAD token (log + ignore), L4GREND.cpp
  L4PLASMA=SCREEN (log + ignore), L4VB16.cpp (inert PadRIO stub -- call sites
  identical in both flavors), btl4main.cpp (front-end/marshal/lobby blocks out;
  zero-arg launch = 4.11 behavior).
- The NetTransport seam ALWAYS compiles -- it is the wire for both flavors
  (WinsockNetTransport, verified byte-identical to the pre-seam arcade path).
- BT412_STEAM now requires BT412 (configure-time FATAL_ERROR; negative-tested).

Verified: OFF -- clean v143 link, solo DEV.EGG mission runs (31 subsystems
tick, gait, targeting). ON -- zero-arg launch engages the front-end menu.
STEAM -- links clean, ships steam_api.dll.

Also: README/context docs for the flavors + the merge-back; corrected the stale
Phase 3b DEFERRED note (the single-window cockpit landed 07-16) and the README's
leftover 0xBD3 valve-gate claim (it is a damage/explosion hub).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Cyd
2026-07-17 15:45:45 -05:00
co-authored by Claude Fable 5
parent 0434585566
commit 335396912e
10 changed files with 177 additions and 48 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+19 -5
View File
@@ -8,7 +8,14 @@ that reconstruction:
|------------|-------------|
| **BattleTech 4.10** | The original pod game — DOS-era MUNGA engine, serial RIO cockpit I/O, 7-monitor cockpit, operator console |
| **BattleTech 4.11** | The **Win32 port** — the BT game logic reconstructed from `BTL4OPT.EXE` on the shared RP411 Windows engine; DirectX 9, full single-player combat loop, two-instance LAN multiplayer |
| **BattleTech 4.12** | **This repo: the Steamification of 4.11** — the same engine, missions, and wire protocol, made distributable on Steam and playable over the internet with no pod hardware |
| **BattleTech 4.12** | **The Steamification of 4.11** — the same engine, missions, and wire protocol, made distributable on Steam and playable over the internet with no pod hardware |
**One tree, both lines (2026-07-17):** the 4.12 steamification was merged back into BT411, so the
same repo builds the **pod game** and the **consumer/Steam game**. The steamification layer
(PadRIO virtual cockpit, desktop plasma, in-game front end, Steam lobby/transport) sits behind the
**`BT412` compile gate** (CMake option, default ON) — see *Build flavors* below. Everything under
the gate is also runtime-inert without its env/arg triggers, so a default build still behaves as a
pod/dev 4.11 binary when launched the pod way (`-egg` / `-net`).
The plan and workstreams live in [docs/BT412-ROADMAP.md](docs/BT412-ROADMAP.md). The sister
project **RP412** (Red Planet's steamification, shipped end-to-end: lobby → Steam-sockets mesh →
@@ -71,6 +78,14 @@ cmake -S . -B build -G "Visual Studio 17 2022" -A Win32 ^
cmake --build build --config Debug
```
### Build flavors (the `BT412` compile gate)
| Flavor | Configure | What you get |
|--------|-----------|--------------|
| **Default** (`BT412=ON`) | as above | Pod/dev game **plus** the steamification layer: PadRIO (`L4CONTROLS=PAD`), desktop plasma (`L4PLASMA=SCREEN`), single-window cockpit (`L4MFDSPLIT=1`), zero-arg front end + LocalConsole marshal. All runtime-gated — a `-egg`/`-net` launch behaves as 4.11. |
| **Pod-minimal** (`-DBT412=OFF`, dir `build-pod`) | `... -B build-pod -DBT412=OFF` | The 4.11 pod image: PadRIO/plasma/KeyLight/front end/lobby/Steam transport are **compiled out**. The NetTransport seam stays (it is the wire for both flavors; `WinsockNetTransport` is byte-identical to the pre-seam arcade behavior). Gated env/args are ignored with a log line. |
| **Steam** (`-DBT412_STEAM=ON`, dir `build-steam`) | `... -B build-steam -DBT412_STEAM=ON` | Default flavor + the `ISteamNetworkingSockets` transport and lobby (vendored SDK at `extern/steamworks_sdk_164`); ships `steam_api.dll`. Requires `BT412=ON` (enforced at configure). Packaged by `pack-dist.ps1`. |
Must be **Win32** — the DirectX SDK link libs are `Lib/x86`. The link uses `/FORCE:MULTIPLE`: the
1995 headers define free functions/globals without `inline`/`extern`, so identical symbols appear
in many translation units (~124 `LNK2005`); `MULTIPLE` keeps the first. `UNRESOLVED` is gone as of
@@ -115,10 +130,9 @@ command. Entity + movement replication works; cross-pod combat is in progress.
The engine, renderer, audio, HAL, build, locomotion, collision, damage, render fidelity, the full
cockpit **gauge / MFD system** (every config binding resolves + every widget builds), and the
projectile / missile weapon families are done. Active fronts: per-subsystem polish (the gyroscope
integrator; the `0xBD3` message manager that gates the valve / status-message control routes) and
cross-pod MP combat. `reference/decomp/` holds the raw pseudocode every reconstruction is verified
against.
projectile / missile weapon families are done. Active fronts: the steamification (roadmap phases —
live multi-machine Steam test + packaging/release remain), per-subsystem polish, and cross-pod MP
combat. `reference/decomp/` holds the raw pseudocode every reconstruction is verified against.
**Start with `CLAUDE.md`** — it is the router into the progressive knowledge base: a quick-lookup
table pointing to the `context/*.md` topic files (loaded on demand), the evidence-tier and