Clean, self-contained extraction of the BattleTech-specific work from the
reverse-engineering workspace -- engine + game + content + build, with nothing
from Red Planet or the raw archive dumps. Builds green (Win32) and runs the
single-player drive->animate->target->fire->damage->destroy loop out of the box.
Layout:
engine/ MUNGA + MUNGA_L4 shared 2007 engine, carrying our BT render/loader
work (bgfload/L4D3D/L4VIDEO: BSL bit-slice decode, LOD/ground/shadow
models) + image codec; the minimal rp/ headers the audio HAL needs
game/ reconstructed BT logic + surviving-original BT source + fwd shims
+ WinMain launcher
content/ full runtime tree (BTL4.RES, VIDEO/, GAUGE/, AUDIO/, eggs, BTDPL.INI)
docs/ format specs + reconstruction ledgers
reference/ raw Ghidra pseudocode (recon source-of-truth) + decomp exporter
tools/ MP console emulator + map/resource scanners
One top-level CMake builds munga_engine lib + bt410_l4 game lib + btl4.exe.
All paths relativized (186 fwd shims + ~437 CMake abs paths -> repo-relative);
DXSDK is the one external, overridable via -DDXSDK. Verified: builds to a
byte-identical 2.27MB exe and runs combat (TARGET DESTROYED, 0 crashes) against
the bundled content.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
64 lines
5.2 KiB
Markdown
64 lines
5.2 KiB
Markdown
# Parallel "Deepen the Systems" Wave — ready-to-fire plan
|
||
|
||
**Status:** STAGED. Do NOT launch until the TRIGGER below is met. Authored while the camera/visibility
|
||
pass is still running.
|
||
|
||
## TRIGGER (fire the wave only when all true)
|
||
1. A mech renders on screen (camera pass done).
|
||
2. There is a world/environment to be in (terrain/cavern renders — Tier 1).
|
||
3. The player mech moves/turns under control input with a following camera (Tier 2 — basic piloting).
|
||
|
||
Why wait: parallel reconstruction is only **compile-verified**; correctness shows up at **runtime**, and
|
||
we've repeatedly hit runtime-only bugs (vtable artifact, shadowed `subsystemArray`, null scenarioRole).
|
||
A pilotable build is the **test harness** that lets the serial integration pass validate the wave's output.
|
||
Firing earlier just piles up plausible-but-wrong code with nothing to check it against.
|
||
|
||
## SERIAL pre-work that must finish first (NOT part of the wave)
|
||
- **Tier 1 — world/terrain render:** fix `DPLRenderer::MakeEntityRenderables` `/RTC1` uninit bug
|
||
(`L4VIDEO.cpp:5211`) + load the cavern environment so non-mech entities draw. (btl4grnd.cpp + engine.)
|
||
- **Tier 2 — locomotion:** wire control input → mech per-frame mover/Animate consumer → chase camera.
|
||
This touches `mech.cpp` + `mechmppr.cpp` (shared cores) so it's serial, done before the wave.
|
||
These two are the critical path to "pilotable" and must not run concurrently with the wave (shared-file
|
||
contention on mech.cpp / btl4vid.cpp / camera).
|
||
|
||
## THE WAVE — parallel agents, partitioned by DISJOINT file ownership
|
||
Same model as the compile wave that worked (7 families, no collisions). Each agent: reconstruct the REAL
|
||
per-frame behavior of its subsystems (the streamed objects currently have only minimal `MechSubsystem`
|
||
base behavior) from the **binary oracle** (`decomp/recovered/all/part_*.c`, `vtables.tsv`, `functions_index.tsv`)
|
||
+ the **RP analog** (`...\trunk\RP\`, `WEAPSYS`/`VTV*`) + surviving headers. Verify by COMPILE
|
||
(`compile1.cmd <file>`), match the oracle, and flag cross-family needs (don't edit headers you don't own).
|
||
|
||
| # | Agent (track) | Owns (`decomp/reconstructed/`) | Reconstruct |
|
||
|---|---|---|---|
|
||
| 1 | **Heat/power** | heat.cpp/hpp, powersub.cpp/hpp, gnrator.cpp/hpp | HeatSink heat-flow/coolant per-frame, HeatableSubsystem thresholds, PoweredSubsystem voltage bus, Generator output. (Owns the subsystem BASE classes — coordinate first.) |
|
||
| 2 | **Energy weapons** | mechweap.cpp/hpp, emitter.cpp/hpp (+ survived GAUSS.CPP/PPC.CPP) | MechWeapon fire/cooldown/heat-cost, Emitter beam (PPC/Gauss) FireWeapon (vtable slot 18). |
|
||
| 3 | **Projectile/missile weapons** | projweap, mislanch, missile, seeker, projtile, misthrst, ammobin (.cpp/.hpp) | ProjectileWeapon/MissileLauncher fire, Missile/Seeker flight + homing, AmmoBin counts, MissileThruster. |
|
||
| 4 | **Sensors/targeting/tech** | sensor.cpp/hpp, mechtech.cpp/hpp | Sensor target acquisition/lock, MechTech repair/diagnostics. |
|
||
| 5 | **Movement subsystems** | gyro.cpp/hpp, torso.cpp/hpp, myomers.cpp/hpp | Gyro stability, Torso twist/aim, Myomers actuation. |
|
||
| 6 | **Damage/messaging** | mechdmg.cpp/hpp, dmgtable.cpp/hpp, messmgr.cpp/hpp | DamageZone TakeDamage → structure/armor, damage-table rolls, SubsystemMessageManager dispatch. |
|
||
| 7 | **HUD / 2D track** (independent, HIGHEST risk) | hud.cpp/hpp, btl4gaug/gau2/gau3/galm (.cpp/.hpp) + a NEW `dpl2d` over-D3D layer | The `dpl2d_*` 2D layer (no D3D equivalent exists — from-scratch over the D3D device) + gauge widgets reading real subsystem state + `.gim/.gat/.pcc` cockpit assets. The one genuine unknown; give it the most room. |
|
||
|
||
(Track 8 — world/terrain — is the SERIAL Tier-1 pre-work above, not a wave slot.)
|
||
|
||
## Ownership / contention rules (critical — agents run concurrently, no git worktrees)
|
||
- Edit ONLY your owned `.cpp` + `.hpp`. Need a base-class change in a header you don't own → REPORT it
|
||
("CROSS-FAMILY NEEDS"), don't edit it.
|
||
- Heat/power (agent 1) owns the subsystem base classes weapons/sensors/movement derive from → if its base
|
||
signatures change, let it settle first OR have it publish the final base surface up front.
|
||
- Do NOT touch `mech.cpp`/`mech.hpp`/`btl4vid.cpp` (cores + render) — those are serial-integration territory.
|
||
- Each agent runs builds against the SAME build dir → builds are serialized by the OS; that's fine for
|
||
`compile1.cmd` single-file checks (preferred) but don't run full `cmake --build` concurrently.
|
||
|
||
## After the wave: SERIAL integration pass
|
||
One bring-up loop (debugger-driven) runs the pilotable build with the deepened systems active and validates
|
||
behavior at runtime — fix interaction bugs, wire the cross-family needs the wave reported, confirm
|
||
weapons/heat/damage/HUD actually function together. This is where the parallel reconstruction gets its
|
||
correctness check. THEN: Tier 5 (enemy AI / `path.cpp` reconstruction) + mission objectives/scoring.
|
||
|
||
## Dispatch checklist (when triggered)
|
||
- [ ] Confirm pilotable (3 trigger conditions).
|
||
- [ ] Re-verify build GREEN + all 43 modules compile (baseline).
|
||
- [ ] Launch agents 1–6 (combat) as one parallel batch; launch agent 7 (HUD) as its own long-running track.
|
||
- [ ] Collect reports → reconcile CROSS-FAMILY NEEDS → serial integration pass.
|
||
- [ ] `path.cpp` / enemy AI is its own pass after combat is validated.
|