# BattleTech (Tesla 4 / rel 4.10) — Source Status & Reconstruction

**Purpose:** brief for a meeting with an original BT programmer. What source we have, what was
missing, where each piece came from, and how we're patching the gaps to get BT running on modern
Windows. **The most useful thing you can tell us is at the bottom (§7).**

**One-line status:** the port now **compiles, links, and boots to a window**, and is running into the
mission/spawn simulation. The engine/renderer/audio came from an existing Windows port (Red Planet);
the BT *game logic* was lost and is being **reconstructed from the shipped binary** + the surviving
headers + Red Planet's parallel code.

---

## 1. The situation in one picture

| Layer | Have it? | Source |
|---|---|---|
| **MUNGA engine + L4 HAL** (renderer, mover, math, scene, net, audio) | ✅ complete | The **Windows port** ("WinTesla", Red Planet 4.11 source) — already bypasses the Division IG board with Direct3D 9 (`L4D3D`) and replaces HMI SOS audio with OpenAL. |
| **BT headers** (`.hpp`: class layouts, vtables, signatures) | ⚠️ **partial** | ~14 survived in the BT source archive (`410srczipped`); the **core ~28 (`mech`, `heat`, `powersub`, weapons, `btplayer`, `hud`, gauges…) were lost** — see §3. |
| **BT game logic** (`mech`, subsystems, weapons, HUD, app…) `.cpp` | ❌ **LOST** | Reconstructed from the shipped binary `BTL4OPT.EXE` (decompiled). |
| **Deployed content** (models, skeletons, skins, animations, missions/eggs) | ✅ present | The pod machine disk image. |

Where a header survived it's an *answer key* for class layout/vtable order (then the binary just
supplies the bodies). Where it didn't (the core mech/weapon/player classes), the layout itself is
inferred from the binary's vtables + `this+offset` usage, cross-checked against the Red Planet analog —
a harder reconstruction, and the part most worth validating against original source if any exists.

---

## 2. Where everything lives (the four archives, in the repo root)

| Archive | What it is | Key contents |
|---|---|---|
| `410srczipped.zip` | **BT source tree** | All `.hpp` headers, geometry/material defs, **428 animations**, and a *partial* set of `.cpp`. Build manifests `CODE/BT/BT/BT.MAK` + `CODE/BT/BT_L4/BTL4.MAK` (the authoritative file lists). |
| `Tesla4NovellTechPC-*.zip` | Pod **technician/test PC** image | The compiled game `btrel410.exe`, Division VPX board diagnostics, shared textures. |
| `Tesla4PodPCNovell-*.zip` | The pod **game machine** image | The full **deployed content tree** at `…/CopyofNovellDisk/REL410/BT/` — per-mech skeletons/skins, models, textures, gauges, **and the mission eggs** (`TEST.EGG`, `LAST.EGG`). Also a copy of the game binary. |
| `Elsewhen RP411 Source-*.zip` | **The Windows port** ("WinTesla", VS2008) | Modernized engine: `WinTesla.sln`, MUNGA + MUNGA_L4 (incl. `L4D3D.cpp` = IG→Direct3D), OpenAL/libsndfile audio, and the **complete Red Planet game logic**. The solution references a `BT410_L4` target **but the BT game source folder is absent** — confirming BT was mid-port and its code isn't here. |

The shipped binary `btrel410.exe` is a PKZIP self-extractor; unwrapped it yields **`BTL4OPT.EXE`**
(1.24 MB, clean PE32) — that's our decompilation + behavioral oracle.

---

## 3. What was missing, precisely (from `BT.MAK` + `BTL4.MAK` = 53 modules)

Every module in the original build manifests is accounted for as follows:

### 3a. Survived as real source (~10) — used as-is
From `CODE/BT/BT/` and `CODE/BT/BT_L4/`:
`BTMSSN` (mission), `BTREG` (registry), `BTTEAM`, `BTSCNRL` (scenario role), `BTCNSL` (console),
`BTTOOL`, `GAUSS` (Gauss rifle), `PPC`, `BTL4ARND` (arena), `BTL4MODE` (mode manager).

### 3b. Lost → reconstructed from the binary (~43 modules)
The heart of the game. **Two cases, depending on whether the header also survived:**

**(i) Header AND `.cpp` lost → both reconstructed** (class layout/vtable inferred from the binary +
RP analog — these are the ones whose layout is *our inference*, not ground truth):
`mech`, `mech2`, `mech3`, `mech4`, `mechsub`, `dmgtable`, `heat`, `heatfamily_reslice`, `powersub`,
`gnrator`, `gyro`, `torso`, `myomers`, `searchlight`, `thermalsight`, `mechweap`, `emitter`,
`projweap`, `missile`, `projtile`, `ammobin`, `btplayer`, `mechmppr`, `btl4vid`, `btl4mppr`, `hud`,
`btl4gaug`, `btl4gau2`, `btl4gau3`.

**(ii) `.hpp` survived, only `.cpp` lost → implementation reconstructed against the real header**
(lower risk — layout is ground truth):
`mechdmg`, `mechtech`, `sensor`, `messmgr`, `mislanch`, `misthrst`, `seeker`, `btl4app`, `btl4mssn`,
`btl4rdr`, `btl4grnd`, `btl4pb`, `btl4galm`, `btdirect`.

(Surviving headers with no reconstruction needed — interface-only or their `.cpp` also survived:
`bt`, `btl4`, `btl4ver`, `btmssn`, `btreg`, `btteam`, `bttool`, `gauss`, `ppc`, `btl4arnd`,
`btl4mode`, `testbt`, `turret`.)

### 3c. Genuinely unaccounted-for (4) — **please confirm with us (§7)**
| Module | Our handling | Question for you |
|---|---|---|
| `btl4` (the `WinMain`/main app) | **Recreated** as `btl4main.cpp`, cloned from RP's launcher `RPL4.CPP`. | Is the real BT main app meaningfully different from RP's? |
| `path` | **Not reconstructed.** Not referenced on the current code path. | What is `path.cpp` — AI pathfinding? Is it needed for single-player bots? |
| `mechbld` | Assumed **offline tool** (mech/model builder), not runtime. | Correct? |
| `btl4tool` | Assumed **offline tool**, not runtime. | Correct? |

### 3d. Missing files, organized by the directory you'd look in

This is the concrete "check your backup drive" list. `BOTH` = `.cpp` and `.hpp` both gone;
`.cpp only` = header survived; `.hpp only` = implementation survived.

**`CODE/BT/BT/`  (game logic)**

| File (module) | What's missing |
|---|---|
| `mech`, `mech2`, `mech3`, `mech4`, `mechsub` | **BOTH** |
| `heat`, `powersub`, `gnrator` | **BOTH** |
| `mechweap`, `emitter`, `projweap`, `missile`, `projtile`, `ammobin` | **BOTH** |
| `gyro`, `torso`, `myomers`, `hud`, `dmgtable` | **BOTH** |
| `btplayer`, `mechmppr` | **BOTH** |
| `path` | **BOTH** (AI pathfinding — see §3c) |
| `mechdmg`, `mechtech`, `sensor`, `messmgr`, `mislanch`, `misthrst`, `seeker`, `btdirect` | `.cpp only` |
| `btcnsl` | `.hpp only` |

**`CODE/BT/BT_L4/`  (app / cockpit / L4 integration)**

| File (module) | What's missing |
|---|---|
| `btl4vid`, `btl4gaug`, `btl4gau2`, `btl4gau3`, `btl4mppr` | **BOTH** |
| `mechbld`, `btl4tool` | **BOTH** (assumed offline tools — see §3c) |
| `btl4` (main app), `btl4app`, `btl4mssn`, `btl4rdr`, `btl4grnd`, `btl4pb`, `btl4galm` | `.cpp only` |

**Present and intact (no help needed):** `CODE/BT/BT/`: `btmssn`, `btreg`, `btteam`, `bttool`,
`gauss`, `ppc`, `turret.hpp`, `bt.hpp` · `CODE/BT/BT_L4/`: `btl4arnd`, `btl4mode`, `btl4.hpp`,
`btl4ver.hpp`, `testbt.hpp`.

---

## 4. How the BT game logic is being reconstructed

`BTL4OPT.EXE` is a near-ideal target: class names, `Class::Method` strings, and **original source
paths in asserts** (`d:\tesla_bt\bt\mech.cpp`) are left in the binary. Per module:

1. Locate the module's function cluster in the decompiled output (asserts + address contiguity).
2. Map vtable slots → methods (vtable order = declaration order, from the surviving header).
3. Map `this+0xNN` offsets → named members (from the header layout).
4. Rewrite the Ghidra pseudo-C into compilable C++, **cross-checking the Red Planet analog** for
   idioms — `VTV`≈`Mech`, `VTVMPPR`≈`mechmppr`, `RPPLAYER`/`BLOCKER`≈`btplayer`, `WEAPSYS`≈weapons,
   `RPL4*`≈the `BT_L4` app layer.
5. Verify behavior against the binary as an oracle.

Result is a **behavior-equivalent reconstruction**, not the original text. Reconstructed files carry a
header banner citing the originating `@ADDR` and the cross-references used.

---

## 5. How it's assembled & patched into a running build

- **Engine:** the WinTesla MUNGA + MUNGA_L4 (193 files) compiles green to `munga_engine.lib`
  (modern MSVC, Win32, targeting the legacy DirectX SDK June 2010 for `d3dx9`/`dinput`).
- **BT game lib (`bt410_l4`):** the 43 reconstructed `.cpp` + the ~10 surviving BT `.cpp` + a small
  `btstubs.cpp` (see below) + a header-forwarding shim (the DOS-era code uses `.hpp` include names;
  WinTesla renamed engine headers to `.h`).
- **Launcher:** `btl4main.cpp` (`WinMain`, cloned from `RPL4.CPP`), drives `BTL4Application`.
- **Link:** `bt410_l4` + `munga_engine.lib` + OpenAL/libsndfile + D3D9/d3dx9/dinput8 → **`btl4.exe`**.

### The patch points we know about (the bring-up worklist)
These are deliberately isolated and flagged `// TODO(bring-up)`:
- **`btstubs.cpp`** — first-link placeholders for: a handful of engine data globals not pulled from the
  static lib (`allPresets`, `FrameTimeScale`); the BT renderable pipeline (`BT*Renderable`); the 2D HUD
  layer (`dpl2d_*`, which libDPL provided and `L4D3D` hasn't yet re-implemented); a few `Mech`/subsystem
  accessors. Each is inert until given a real body.
- **Two stubbed video data files** — `VIDEO\REPLACEMATS.tbl` / `MATREPLACETABLE.tbl` (WinTesla-era
  material-substitution tables, absent from the 1995 content) created empty so video init proceeds.
- **A few reconstructed `BTPlayer`/`Mech` methods** still missing real bodies (currently being
  recovered, in dependency order driven by what the running game asks for next).

---

## 6. Current runtime state (live)

`btl4.exe` boots cleanly: opens `BTL4.RES`, parses the `-egg TEST.EGG` mission (BattleTech / cavern /
freeforall / night), creates the application, initializes the D3D video renderer, **opens its window**,
and enters the mission simulation. The **player-spawn pipeline now executes end-to-end** —
`HuntForDropZone → DropZone reply → BTPlayer::CreatePlayerVehicle → MakeAndLinkViewpointEntity →
Mech::Make → Mech::Mech` (all reconstructed from the binary + RP analog this session).

**Current frontier = the `Mech` object-layout + resource-streaming reconstruction.** The Mech
constructor runs but doesn't yet *stream* its model/subsystems/skeleton: in the reconstruction the
resource layer (`ResourceFind`/`ResourceStream`) is still a no-op placeholder, and ~145 raw
`this[0xNN]` field accesses in `mech.cpp` are backed by a shared scratch bank instead of named members.
This is the single biggest remaining reconstruction task — and, notably, it's **exactly the module
whose original `.hpp` *and* `.cpp` were both lost** (`mech`, see §3d). Recovering the real `mech.*`
would short-circuit this entire pass.

---

## 7. What would help most from you

1. **The real BT game source** — if a backup/dev drive has `CODE/BT/BT/*.cpp` (the lost `mech`,
   subsystems, weapons, HUD, app), it would replace the entire reconstruction. Even a partial set
   shrinks the work dramatically.
2. **`path.cpp`** — what is it (AI pathfinding?), and is it needed for single-player bot missions?
3. **`mechbld` / `btl4tool`** — confirm these are offline tools, not runtime modules.
4. The **mission/egg flow** for standalone (non-networked) play — anything special about how a pod
   launched a single mission vs. the multiplayer console handshake.
5. The **2D HUD / `dpl2d_*` layer** — how the cockpit gauges/radar were drawn, since that's the part of
   libDPL the Direct3D port hasn't reproduced yet.
6. Confirmation that the pod disk image is the **complete content master**, and whether the full
   walk/run **animation set** exists beyond what shipped in the source archive.

---
*Reference docs in this repo: `CLAUDE.md` (overall project), `btbuild/RECONCILE.md` (the detailed
reconstruction + bring-up ledger), `decomp/README.md` (decompilation method).*