Files
BT412/docs/WAVE_PLAN.md
arcattackandClaude Opus 4.8 7b7d465e5e Initial commit: bt411 -- standalone Windows BattleTech (Tesla 4.10 port)
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>
2026-07-05 21:03:40 -05:00

64 lines
5.2 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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 16 (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.