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>
5.2 KiB
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)
- A mech renders on screen (camera pass done).
- There is a world/environment to be in (terrain/cavern renders — Tier 1).
- 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/RTC1uninit 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.cmdsingle-file checks (preferred) but don't run fullcmake --buildconcurrently.
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.