arcattackandClaude Opus 4.8
f914fc040a
Full migration of the 2236-line monolithic CLAUDE.md into the progressive-context knowledge graph (per spark-lesson / expert-seed.md), so the deep RE knowledge loads on-demand instead of every session. ZERO CONTEXT LOST: - docs/PROGRESS_LOG.md = the complete old CLAUDE.md, VERBATIM (byte-identical) -- the lossless safety net + the "full detail" quick-lookup fallback. - 18 context/*.md topic files (1343 lines) digest every section (§1-3 -> project-overview, §4 -> content-archives, §5 -> asset-formats/bgf-format, §5a -> source-completeness, §5b/§8 -> wintesla-port, §7/§10 -> locomotion, §10a -> build-and-run, §10b -> reconstruction-method, §10c -> combat-damage + reconstruction-gotchas, §10d -> subsystems, render notes -> rendering, gauges -> gauges-hud, MP -> multiplayer, §9 -> open-questions). - reference/glossary.yaml (53 terms). decomp-reference.md = the offsets/ClassIDs/addresses hub. CLAUDE.md (160 lines) = router: identity, answer/reason protocols, quick-lookup table, evidence tiers (T0 engine-truth / T1 decompiled+verified / T2 reconstructed+runtime / T3 guarded / T4 hypothesis), conventions + DO-NOT (the systemic bug classes), structure. Retains the load-bearing work directives (build recipe pointer, "keep current" mandate). Knowledge graph validates CLEAN (scratchpad/checkctx.py -- all [[links]] + quick-lookup + docs refs resolve; [[name]] -> topic file or glossary term). docs/*.md ledgers stay as the detailed logs; context/*.md are the curated digests that route into them. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
52 lines
3.0 KiB
Markdown
52 lines
3.0 KiB
Markdown
---
|
|
id: source-completeness
|
|
title: "Source Completeness — the gating blocker + the decompilation route"
|
|
status: established
|
|
source_sections: "PROGRESS_LOG.md §5a; docs/BT_SOURCE_STATUS.md"
|
|
related_topics: [wintesla-port, reconstruction-method, decomp-reference, open-questions]
|
|
key_terms: [BTL4OPT, decomp, oracle, WinTesla, BT]
|
|
open_questions:
|
|
- "Get the missing BT .cpp from Nick (gating for Route A)"
|
|
---
|
|
|
|
# Source Completeness — the gating blocker
|
|
|
|
The archive has the **engine and all headers, but NOT the BT game's implementation `.cpp`.**
|
|
This is THE gating fact that shapes the whole project. Full map: `docs/BT_SOURCE_STATUS.md`.
|
|
|
|
## What's present vs missing (verified across all 3 zips + the WinTesla archive)
|
|
- **MUNGA engine** (shared): ~183 `.cpp` — largely complete (renderer, MOVER/JMOVER, math, scene). [T1]
|
|
- **All BT game `.hpp` headers** present — every class/interface defined (the reconstruction's "answer key"). [T1]
|
|
- **BT game logic `.cpp`: MISSING** — `mech`, `mech2/3/4`, `mechsub`, `mechmppr`, `mechtech`, `heat`,
|
|
`sensor`, `gyro`, `torso`, `myomers`, `hud`, `mechweap`, `powersub`, `btplayer`, and the main app
|
|
`btl4` are all absent. Only ~10 BT `.cpp` survive (BTCNSL/BTMSSN/BTREG/BTSCNRL/BTTEAM/BTTOOL +
|
|
GAUSS/PPC + BTL4ARND/BTL4MODE). [T1]
|
|
- **RP can't backfill BT** — RP's game source is gutted the same way. The per-game source for BOTH
|
|
titles is missing; only shared *engine* game-logic survives. A complete repo likely exists
|
|
elsewhere (Nick). [T1]
|
|
|
|
## Consequence — routes forward
|
|
Route A (recompile original source) is **impossible as-is** — the code that IS the game isn't here.
|
|
Paths: (1) **get the missing `.cpp` from Nick** [gating, top priority]; (2) run `btrel410.exe` under
|
|
DOSBox by emulating the VPX/IG board (blocked — needs board emulation); (3) **decompile
|
|
`BTL4OPT.EXE` + reconstruct from headers** — the chosen route (in progress). [T2]
|
|
|
|
## The binary is a near-ideal decompile target
|
|
`btrel410.exe` is a PKZIP self-extractor; inside is **`BTL4OPT.EXE`** (1.24 MB, clean uncompressed
|
|
PE32, Phar Lap TNT). It retains **class names, `Class::Method` strings, and source-file paths in
|
|
asserts** (`d:\tesla_bt\bt\mech.cpp`) — confirming the missing modules ARE in the binary. No COFF
|
|
symbol table (naming comes from those strings). Extracted to `reference/decomp/`. [T1]
|
|
|
|
## Why reconstruction is viable (THREE anchors)
|
|
1. **All BT headers** = exact class layouts, vtable order, signatures (the answer key).
|
|
2. **The working WinTesla engine** to compile against ([[wintesla-port]]).
|
|
3. **Red Planet's parallel implementations** as a live reference (`VTV`≈mech, `VTVMPPR`≈mechmppr,
|
|
`WEAPSYS`≈mech weapons, `RP_L4` app≈BT app).
|
|
Plus `BTL4OPT.EXE` as a behavioral **oracle** (run under cdb / read the decomp). Result =
|
|
behavior-equivalent **reconstruction**, NOT original source. [T2]
|
|
|
|
## Key Relationships
|
|
- Feeds: [[reconstruction-method]] (the loop that fills the gap), [[decomp-reference]].
|
|
- Gated on: [[open-questions]] (get the source from Nick).
|
|
- Built atop: [[wintesla-port]].
|