# BT compile-wave reconciliation notes

Cross-family header needs + link-time externs reported by family agents.
Resolve AFTER all 7 families report (Stage 1 reconciliation), then again at link (Stage 3).

## From controls/player (mechmppr, btplayer) — DONE, 0 errors

### Cross-family header changes needed
- **mech.hpp (mech-core family)**: expose on `Mech` — `tonnage` (+0x4bc), `damageBiasFactor` (+0x354),
  `owningPlayer` (+0x190, `BTPlayer*`). Currently reached via raw offset macros in btplayer.cpp.
- **ScenarioRole (engine SCNROLE.h)**: needs decrement of `returnFromDeath`
  (used `SetReturnFromDeath(GetReturnFromDeath()-1)`); no `returnDelay` field (role+0xf0) →
  `roleReturnDelay` stubbed to 0.
- **Player__VehicleDeadMessage**: BT build carried `killerName` (+0x1c) the engine base lacks; read via offset.

### Stubbed (no WinTesla analog) — revisit at integration
- BTPlayer ctor role/mission-registry resolution: `GetMissionRegistry()` / `GetRoleRegistry()->Lookup()` /
  `GetMission()->GetGameModel()` have no WinTesla analog → stubbed; base-set `scenarioRole` stands.

### Link-time externs to be PROVIDED by owning modules (Stage 3)
- `ToggleVoiceAssist`, `Is_Destroyed` (mechmppr)
- `Set_Alarm_Level` (GaugeAlarm has no `SetLevel` in WinTesla)
- `Notify_Objective_Reached`, `StatusMessagePool`
- `BTPlayerVTable`, `BTStatusMessageVTable`, `SelfDestructName`, `ResetDelay`, `TicksPerSecond`

## From gauges/HUD (btl4gaug, gau2, gau3, galm, hud) — DONE, 0 errors

### Cross-family header changes needed
- **mech family**: `LWord BT_GetSegmentFlags(Mech*)` — declared `extern` in hud.cpp (mirrors powersub's
  `BT_GetMessageManager` pattern); needs a real definition in the mech layer.
- **powersub/heat family**: HUD inherited watchdog accessors stubbed to return 0 — bind to real inherited
  members once exposed: heat-state level @0x140, watched-voltage alarm level @0x198, heat-watcher flag @0x40.

### Foundation fix worth doing properly
- `DebugStream` is double-defined incompatibly: `heat.hpp` (`std::ostream&`) vs `mechrecon.hpp` (`ReconStream`).
  Gauge .cpps work around it by pre-defining `BT_DEBUGSTREAM_DEFINED` to suppress heat.hpp's variant.
  → settle on ONE definition in the shared foundation. (NOTE: a `mechrecon.hpp` exists — investigate.)

### Stubbed (unrecovered .data) — revisit
- Gauge resource-pool config (rates/modes/colours/image-names) not recovered from the optimised image →
  typed placeholder statics. HUD `FindAttributeIndex` shim (no engine analog).

## From heat/power (heat, heatfamily_reslice, powersub, gnrator) — DONE, 0 errors

OWNS the subsystem base classes. Established the authoritative base virtual surface (HeatableSubsystem/
HeatSink/Condenser/Reservoir/PoweredSubsystem/Generator/Myomers/PowerWatcher/HeatWatcher) — see report:
GetClassDerivations()/DefaultData 4-arg idiom; HeatAlarm/HeatFilter/SubsystemConnection wrappers in heat.hpp.

### Cross-family header changes needed
- **mech family** — provide on `Mech` (declared as extern prototypes `BT_GetMessageManager/BT_IsBusLive/
  BT_ClearMyomers(Mech*)` in powersub.hpp so TUs link):
  - `Mech::GetMessageManager()` → subsystem message manager (`owner+0x190`)
  - `Mech::IsBusLive()` → power-bus-live flag (`*(owner+0x190)+0x274`)
  - `Mech::ClearMyomers()` → clears myomer back-pointer (`owner+0x374`)
  - Cockpit HUD gauge fields `field_438`/`field_5b4` used by `Condenser::MoveValve` (stubbed null).

## From btl4-app (btl4app/mssn/rdr/grnd/vid/pb/mppr, btdirect) — DONE (4 clean, 4 only cross-family residual)

btl4mssn/grnd/vid/direct = 0. btl4app=1, btl4mppr=2, btl4pb=3, btl4rdr=1 — ALL residuals are in
mech.hpp / mechrecon.hpp (not owned). Will clear when mech family + mechrecon are reconciled.

### Cross-family header changes needed
- **mech.hpp — add to `class Mech`** (offsets from binary oracle):
  - `void SetMappingSubsystem(Subsystem*);` (btl4app.cpp:567)
  - `void Reset();` + `void MissionReviewReset();` (btl4pb.cpp:555)
  - `Logical GetMissionReviewMode();` (reads mech+0x414, btl4mppr.cpp:366)
  - `void SetTargetRange(Scalar);` (writes mech+0x404, btl4mppr.cpp:407)
  - (non-blocking) egg fields `vehicleColor`/`vehicleBadge`/`vehiclePatch` (mech+0x848/0x844/0x84c)
- **mechrecon.hpp(89)** — declares `Random` as a FUNCTION, collides with engine `extern RandomGenerator
  Random;` (RANDOM.h:40). RENAME/REMOVE it — sole residual blocking btl4rdr.cpp. *Investigate what
  mechrecon.hpp is + who owns it (mentioned by gauges/HUD + btl4-app).*

## From mech-subsystems (gyro/torso/myomers/sensor/mechtech/searchlight/thermalsight/messmgr) — DONE, 0 errors

`mechrecon.hpp` confirmed = emergent SHARED COMPAT-SHIM header (provides ReconAlarm etc.); families lean
on it. → CONSOLIDATE + settle ownership in reconciliation (also the `Random`-function bug above).

### Cross-family header changes needed (locally shimmed; real homes are shared bases)
- **Mech/Entity/Subsystem**: `Word GetSegmentFlags() const` (used by 6 files); `Mech::ResolveJoint(const
  char*)`; segment-roster accessors; `Mech::GetSegmentCount()`.
- **HeatSink**: `HeatState HeatStateLevel() const`, `Logical HeatModelOff() const`, public `heatEnergy` accessor.
- **PoweredSubsystem**: `ElectricalState ElectricalStateLevel() const`.
- **PowerWatcher**: confirm `ResetToInitialState()`/`HandleDeathMessage(Message&)`/`UpdateWatch()`↔
  `Simulation(Scalar)`/`WatchedVoltageLevel()`/`HostShutDown()` signatures (now derives HeatableSubsystem).
- **Subsystem**: `GetExplosionID()`; renderer/clock globals for messmgr explosion submission.
- **powersub.hpp**: DELETE stale mislabeled `Myomers`; **RegisteredClass**: add `MyomersClassID == 0xBC6`
  (enum still has the 0xBC3 mislabel = really Sensor).

## From mech-core (mech/mech2/3/4/mechsub/mechdmg/dmgtable) — PARTIAL (4 of 7 clean)

CLEAN: mech2, mech4, mechsub, dmgtable. BLOCKED: mech.cpp, mech3.cpp, mechdmg.cpp.
**OWNS `mechrecon.hpp`** (the shared compat shim) → fix the `Random`-function collision HERE.
Added ~60 Mech members (gait/locomotion/clip/sim) to mech.hpp.

### The big remaining integration task — THE SUBSYSTEM FACTORY
mech.cpp ctor + mech3.cpp `CreateSubsystemStream`/`CreateSubsystemsStream`/`SubsystemDefaultData` dispatch
over ~21 sibling subsystem classes. Each needs, uniformly:
  `static <X> CreateStreamedSubsystem(NotationFile*, const char*, const char*, SubsystemResourceBlob*,
       NotationFile*, const ResourceDirectories*, int)`  AND  `static SharedData DefaultData`
Classes: HeatSink, Reservoir, Condenser, PoweredSubsystem, Myomers, Generator, HUD, Searchlight,
ThermalSight, Sensor, Gyroscope, Torso, Emitter, PPC, ProjectileWeapon, MissileLauncher, GaussRifle,
AmmoBin, MechControlsMapper, MechTech, SubsystemMessageManager (+ mech.cpp-only: Cockpit, HeatSinkSource,
Actuator, JumpJet, LegSubsystem, MechDisplay).
→ This is a dedicated follow-up pass AFTER all sibling headers are final (needs their headers included in
  mech.cpp/mech3.cpp + the uniform static signatures present). mech.cpp also has ~180 raw `this[0xNN]`
  pseudo-assignments to convert, and ChainOf<> default-ctor/SetOwner/iteration semantics.
- mechdmg.cpp: mostly reducible (Mech__DamageZone members structureLevel/graphicState/flags + word
  accessor; Read→ReadBytes); + Generator cross-family dep (powersub) + engine skeleton-walk types
  (SegmentRecord/SegmentIterator/DZRef).

## From weapons (mechweap/emitter/projweap/mislanch/missile/seeker/projtile/misthrst/ammobin) — DONE, 0 errors

No blocking cross-family needs (adapted to heat/powersub header changes live). Watch points:
- `mechweap.cpp` calls `PoweredSubsystem::GetClassDerivations()` — must track if powersub reverts.
- `ammobin.hpp` includes `<heatfamily_reslice.hpp>` (where HeatWatcher is actually defined), NOT
  `<heatfamily.hpp>` (forwards to heat.hpp, no HeatWatcher). Follow if HeatWatcher moves.
- Added per-class `X__UpdateRecord : Base::UpdateRecord`; `UpdateTargeting()` now returns `Logical`.

## ============ WAVE COMPLETE: 36/43 clean. Remaining: 4 btl4-app (reconcile) + 3 mech-core (factory) ============

## RECONCILIATION PASS 1 done → 40/43 clean
- mechrecon.hpp `Random()` template → renamed `RandomUnit()` (collided w/ engine `extern RandomGenerator
  Random`); updated dmgtable.cpp 2 call sites. btl4rdr now 0.
- mech.hpp: added Mech app/cockpit interface — `SetMappingSubsystem(Subsystem*)`, `GetMissionReviewMode()`,
  `SetTargetRange(Scalar)`, `Reset(const Origin&, int mode)`, and `enum ResetMode { MissionReviewReset=0 }`.
  CORRECTION: MissionReviewReset is a MODE CONSTANT (0), not a method (call site proved it).
  → btl4app/mppr/pb all 0. (Definitions of these Mech methods still owed by mech.cpp at link time.)

REMAINING: mech.cpp, mech3.cpp, mechdmg.cpp (the subsystem factory) → dedicated agent.

## RECONCILIATION PASS 2 + STAGE 2 PREP (overnight)
- Factory agent #1 stalled (stream watchdog) with mech.cpp at 67 (from >100); mech3/mechdmg untouched.
  It regressed hud.cpp (0→1) via a `ZeroVector` it added to mechrecon.hpp:181 → FIXED by renaming
  hud.cpp's local `ZeroVector`→`HudZeroVector` (kept mechrecon's for the mech files). hud.cpp back to 0.
- Resumed factory agent (a52bd3052af4ade1a) from transcript with file-by-file + verify-often guidance.
- STAGE 2 (executable) staged, all non-conflicting:
  - `btbuild/btl4main.cpp` = WinMain launcher cloned from RP_L4/RPL4.CPP, BTL4Application path, BTL4.RES,
    800x600 window, RP-only review/playback branch dropped. COMPILES CLEAN (0 errors).
  - `btbuild/CMakeLists.txt` now also defines exe target `btl4` (WIN32): links bt410_l4 + munga_engine.lib
    (enginebuild/build/Debug) + OpenAL32/libsndfile-1 (trunk/lib) + d3d9/d3dx9/dinput8/dxguid/DxErr
    (DXSDK Lib/x86) + winmm/dbghelp/shell32/user32/gdi32/ole32. CMake CONFIGURES clean (Win32 Debug).
  - Version bytes hardcoded {4,1,0} — TODO verify vs BTL4.RES header at runtime.

## NEXT (once factory lib is green): cmake --build → if lib green, link btl4.exe → triage undefined
   symbols (Stage 3) → define/reconstruct or stub-with-flag → iterate to a linked exe → attempt boot.

## ====== ALL 43 RECONSTRUCTED MODULES COMPILE (factory done by stopped-but-finished agent) ======
## FULL BUILD #1: 0 compile errors, 45 unresolved externals at link. Buckets:
##   - ~25 Winsock (L4NET) → FIXED: added ws2_32 to btl4 link.
##   - Surviving BT source not compiled in (BTMission/BTRegistry/BTL4ModeManager/Gauss/PPC/BTTeam/
##     BTScenarioRole/BTConsole) → FIXED: added BTMSSN/BTREG/BTTEAM/BTSCNRL/BTCNSL/GAUSS/PPC/
##     BTL4MODE/BTL4ARND .CPP to the bt410_l4 sources.
## FULL BUILD #2: surviving files have 12 compile errors (410-era ClassDerivations→GetClassDerivations
##   API drift; BTSCNRL needs btscnrl.hpp; BTMSSN Exit()). Link not reached yet.
## STILL-UNDEFINED (buckets 3+4, expected after survivors compile) — provide real def or flagged stub:
##   Mech::{GetMissionReviewMode,SetTargetRange,SetMappingSubsystem,Reset,IsAirborne,RaiseStatusAlarm},
##   Mech__DamageZone::LoadCriticalSubsystems, MechSubsystem::{TakeDamage,OnAlarmChanged,HandleMessage},
##   Is_Destroyed, ToggleVoiceAssist, Generator::{ClassDerivations,ForceShortRecovery},
##   FrameTimeScale, allPresets, BTL4MethodDescription, BTL4AudioRenderer ctor, BTL4VideoRenderer ctor.

## ====== FULL BUILD #3: ✅ btl4.exe LINKS (build/Debug/btl4.exe, 1,849,344 bytes, valid PE) ======
## 0 compile errors, 0 unresolved externals. Achieved via:
## TASK 1 (12 compile errors in surviving 410-era files — all FIXED):
##   - GAUSS.CPP/PPC.CPP: ClassDerivations/DefaultData now pass ADDRESSES (&Emitter::ClassDerivations,
##     &X::ClassDerivations) — matches reconstructed emitter.cpp member-idiom (Derivation ctor now takes
##     Derivation*). Headers unchanged (still `static Derivation ClassDerivations`).
##   - BTTEAM.CPP/.HPP: migrated to GetClassDerivations()/GetAttributeIndex() accessor idiom (mirrors
##     engine TEAM.cpp); TestInstance uses *GetClassDerivations().
##   - BTL4ARND.CPP:77: JointedMover::ClassDerivations → *JointedMover::GetClassDerivations().
##   - BTMSSN.CPP:53: Exit(AbortExitCodeID) → Fail(...) (WinTesla engine has no free Exit(); Fail is the
##     fatal-abort macro already used in this file). FLAGGED.
##   - btscnrl.hpp AUTHORED (decomp/reconstructed/) — minimal BTScenarioRole : ScenarioRole (BTSCNRL.CPP
##     is an empty TU; nothing else references the class).
## TASK 2 (link): three link waves. Wave A=21 unresolved, Wave B=34 (defining the BTL4VideoRenderer ctor
##   pulled btl4vid.obj fully in, exposing the unreconstructed BT renderable module + dpl2d + renderer
##   helpers), Wave C=6 (engine VideoComponent never implemented in WinTesla).
##   REAL fixes (co-located, not stubs):
##     - mechdmg.cpp:358 Generator::ClassDerivations → *Generator::GetClassDerivations() (idiom).
##     - btl4grnd.cpp: defined BTL4MethodDescription[] = { &BTL4ChainToPrevious } (minimal real table).
##     - btl4vid.cpp: defined BTL4VideoRenderer ctor/dtor/TestInstance (ctor adapts old IG calibration
##       args → DPLRenderer(GetActiveWindow(),800,600,false,...); FLAGGED window/size).
##   FLAGGED STUBS (new file decomp/reconstructed/btstubs.cpp; added to bt410_l4 in CMakeLists):
##     data globals: FrameTimeScale(=1.0f), allPresets[2][100], StatusMessagePool, BTPlayerVTable,
##       BTStatusMessageVTable.
##     free fns: Is_Destroyed, ToggleVoiceAssist, Set_Alarm_Level, Notify_Objective_Reached.
##     Mech: GetMissionReviewMode, IsAirborne, SetTargetRange, SetMappingSubsystem, RaiseStatusAlarm.
##     Mech__DamageZone::LoadCriticalSubsystems; MechSubsystem::TakeDamage/OnAlarmChanged;
##       Generator::ForceShortRecovery.
##     BT_GetMessageManager/BT_IsBusLive/BT_ClearMyomers (Mech<->subsystem bridge).
##     dpl2d_* (NewDisplayList/Begin/SetColor/Circle/Push/PopMatrix/MoveTo/End/Compile) +
##       dpl_SetMaterialNameCallback (libDPL 2D layer never ported to L4D3D).
##     BTL4VideoRenderer::GetScene/LoadObject/AttachToEyeDCS/AddDynamicRenderable/LoadMissionImplementation.
##     ENTIRE BT RENDERABLE MODULE (unreconstructed): BTWorldContainer/Root/DCSObject/Hinge/BallJoint/
##       BallTranslateJoint/Eye/DeathEffect/MarkerWatcher/Translocation/POVStartEnd/Tracer/EmitterBeam/
##       PPCBeam/LightConnection ctors (chain to BTRenderableBase) + BTReticleRenderable ctor/dtor/Execute.
##     ENGINE VideoComponent ctor/dtor/Add/Connect/ReceiveControl/Execute (declared in L4VIDRND.h but
##       NEVER implemented in WinTesla — superseded by VideoRenderable; stubbed to link).
##   LINK FLAG: target_link_options(btl4 PRIVATE /FORCE:MULTIPLE) absorbs ~124 LNK2005 / 200 LNK4006 —
##     1995 header-defined non-inline globals/free-fns (operator==(sockaddr_in&), EnumAxes/JoysticksCallback,
##     gOpNames, gReplacementData) compiled into multiple TUs. Identical defs → linker keeps first.
## ⚠ RUNTIME BRING-UP WORKLIST = every stub above (all carry TODO(bring-up) comments; grep btstubs.cpp).
##   The exe LINKS but the BT renderable pipeline + 2D HUD + several Mech accessors are inert until the
##   stubs get real bodies (from BTL4OPT.EXE oracle / RP analog). First boot will likely reach init/menu
##   but not render a mech.  NEXT: attempt boot; reconstruct the BT renderable module + dpl2d-over-D3D.

## MISSING-FILE LEDGER (from BT.MAK+BTL4.MAK = 53 modules): ~10 survived, ~43 reconstructed,
##   4 unaccounted: btl4(main→recreated as btl4main.cpp), path(AI pathfinding-not referenced in link),
##   mechbld(offline tool), btl4tool(offline tool). Nothing runtime-critical lost except possibly `path`.

## ============ STAGE 4: IT BOOTS. btl4.exe runs to a stable window. ============
FULL BUILD: 0 errors, 0 unresolved → btl4.exe (1.85MB PE32) LINKS.
Boot smoke-test (run/ dir: exe + stub OpenAL32.dll/libsndfile-1.dll + x86 debug CRT; cwd = pod content
tree tesla4pod_extracted/.../REL410/BT; arg `-egg TEST.EGG`):

PROGRESS LADDER (each was a real fix):
  1. exit 3, "no source for egg"     → wired L4Application::ParseCommandLine + ParseToken in btl4main.cpp
                                        (egg via `-egg <file>`; single-user mode = no real net needed).
  2. exit 3, "btl4.res v1.1.0.6 obsolete" → version check compares our version[i] vs file versionArray[i+1]
                                        (skips format byte). File=1.1.0.6 → set version[3]={1,0,6}. PASSES.
  3. NOW: boots → window "BattleTech" (800x600) appears → resources OK → ApplicationManager OK →
     BTL4Application constructs OK → **BLOCKS inside ApplicationManager::StartApplication** (idle, CPU~0,
     no crash, stable 16s+). Waiting on a mission/network state-machine event the inert stubs don't produce.

### RUN RECIPE (for morning / interactive)
  exe:  C:\git\nick-games\btbuild\run\btl4.exe   (+ stub DLLs + debug CRT already there)
  cwd:  C:\git\nick-games\tesla4pod_extracted\Tesla4PodPCNovell\CopyofNovellDisk\REL410\BT
  arg:  -egg TEST.EGG     (a BattleTech/cavern/freeforall/night mission)
  log:  btl4.log in the cwd (has the [boot] markers from btl4main.cpp).

### NEXT (bring-up, best done interactively + with a debugger):
  - Trace why StartApplication blocks: the mission/net state machine (InitializingState→WaitingForEgg→
    LoadingMission→...) likely waits for a step a STUB no-ops. Prime suspects = the btstubs.cpp list
    (BT*Renderable, dpl2d_*, BTL4VideoRenderer::Load*/GetScene, network/host local-establishment).
  - Replace stubs with real bodies from the BTL4OPT.EXE oracle / RP analog, in dependency order of the
    boot state machine. Each real body lets the state machine advance one step.
  - Audio is stubbed (no real OpenAL/libsndfile DLLs) — fine for now; swap real DLLs later.

## ============ STAGE 4 BRING-UP (debugger-driven, 2026-06-30) ============
Method: run under cdb (x86), catch fault/abort, fix, repeat. Run recipe unchanged
(run\btl4.exe, cwd=pod BT dir, -egg TEST.EGG; symbols via -y run\ + btl4.pdb).

PROGRESS LADDER (each a real fix; all advance the boot):
  1. HANG in video init: DPLRenderer(=D3D)->loadTables fread(NULL) -> CRT assert MessageBox.
     loadTables reads VIDEO\REPLACEMATS.tbl + VIDEO\MATREPLACETABLE.tbl (WinTesla-era, absent).
     FIX: created empty (numMats=0, 4 zero bytes) tables in pod VIDEO\. -> video init passes,
     monitor detection runs (windowed mode), StartApplication returns, enters RunMissions.
  2. AV in mission load: BTPlayer ctor -> ScenarioRole::GetReturnFromDeath on NULL (role lookup
     stubbed/commented at btplayer.cpp:630). FIX: null-guard btplayer.cpp:644 (default index 2).
  3. AV in frame loop: Entity::Execute->PerformAndWatch called NULL fn ptr; the BTPlayer's vtable
     was overwritten with the zeroed stub `BTPlayerVTable`. ROOT: btplayer.cpp:568/698 had decompiler
     artifact `*(void**)this = &BTPlayerVTable` (+447 status msg). FIX: removed those 3 artifacts
     (C++ ctor sets the real vtable). -> **D3D WINDOW APPEARS**, game simulates.
  4. abort() in frame loop: Player::HuntForDropZone (spawn logic) -> DropZone reply ->
     base Player::DropZoneReplyMessageHandler = Fail("...base player class!"). ROOT: BTPlayer never
     defines DropZoneReplyMessageHandler, so MESSAGE_ENTRY(BTPlayer,DropZoneReply) resolves to the
     inherited base Fail-stub.  <-- CURRENT FRONTIER.

NEXT: reconstruct BTPlayer::DropZoneReplyMessageHandler (the spawn handshake: place mech at dropzone +
create player vehicle) from the BTL4OPT.EXE oracle. Likely a small CLUSTER of missing BTPlayer/Mech
gameplay overrides will follow (now genuine game-logic reconstruction, not mechanical link fixes).

## ============ STAGE 4 BRING-UP (cont., 2026-06-30 session 2) ============
The SPAWN PIPELINE is now reconstructed end-to-end. Boot advances from the DropZoneReply abort all the
way INTO Mech construction. PROGRESS LADDER (each a real fix):
  5. abort() Player::DropZoneReplyMessageHandler base Fail.  ROOT: BTPlayer had no override.
     FIX (REAL reconstruction): reconstructed the whole spawn handshake -
       - BTPlayer::DropZoneReplyMessageHandler  <- binary oracle FUN_004bffd0 (handler table @00512fd8,
         msg id 0x15; confirmed VehicleDead=FUN_004c05c4 NOT 004c012c, and the real 6-entry table:
         DropZoneReply/VehicleDead/Score/ScoreUpdate/MissionStarting/MissionEnding). !playerVehicle ->
         CreatePlayerVehicle+InitializePlayerLink+SetPerformance(by classID: Mech 0xbb9 / CameraShip 0x45)
         +AlwaysExecute+deathCount=0; else-same-death -> MissionEnding ignore / !DropZoneAcquired ->
         VehicleDead(reset); then mech->Reset(dropZoneLocation,True).
       - BTPlayer::CreatePlayerVehicle(Origin)  <- vtable slot +0x40 (FUN_004bfcac, not in the
         assert-anchored decomp) modelled on RPPlayer::CreatePlayerVehicle: base CreatePlayerVehicle
         (camera ships) then make a Mech via MakeAndLinkViewpointEntity from playerMission->GetGameModel()
         ModelList resource, names = GetBadgeName/GetColorName/((BTMission*))->GetPatchName.
       - BTPlayer::InitializePlayerLink  <- FUN_004bfee0 / RPPlayer analog (PlayerLink dispatch).
       - Mech::MakeMessage ctor (mech.hpp) <- mirror of VTV__MakeMessage entity_ID form + 3 name strings.
       - Mech::Reset(const Origin&,int) (btstubs.cpp) <- MINIMAL of FUN_0049fb74: set localOrigin/
         localToWorld + ForceUpdate. TODO(bring-up): full ~50-field state + per-subsystem reset deferred.
     RESULT: HuntForDropZone->AssignDropZone->DropZoneReply->CreatePlayerVehicle->MakeAndLinkViewpoint->
       BTL4Application::MakeViewpointEntity->Mech::Make->Mech::Mech runs. Spawn pipeline FUNCTIONAL.
  6. AV mech.cpp:407 (Mech ctor) deref Wword(0xbb)+0xc, Wword(0xbb)=0 (engine segment record).
     FIX: guarded the NULL deref (heatLevel default 0). TODO(bring-up) - real value needs the segment
     record wired (see frontier below).
  7. AV mech.cpp:591 (Mech ctor) gyro<->sinkSource cross-link wrote through gyroSubsystem=0xcdcdcdcd.
     ROOT (REAL BUG): the ctor's subsystem-pointer zero-inits at mech.cpp:359-361 targeted the Wword
     SCRATCH BANK (Wword(0x14a/0x10e/0x16d)=0) instead of the real members, so gyroSubsystem/
     sinkSourceSubsystem/mechTechSubsystem were never zeroed -> debug-fill passed the !=0 guard.
     FIX (REAL): zero the real members gyroSubsystem/sinkSourceSubsystem/mechTechSubsystem/sensorSubsystem
     (matches binary @9873-9875). NOT a guard - a genuine init bug.
  8. AV mech.cpp:641 (Mech ctor Pass 2) model = ResourceFind(Wword(0x6f),0xf) -> NULL -> model->base deref.
     <-- CURRENT FRONTIER (ROOT, structural).

### THE FRONTIER = the Mech object-layout / resource-streaming "factory" (deferred big task)
ROOT CAUSE, definitively localised: in `decomp/reconstructed/mechrecon.hpp` the resource-streaming layer
is a set of NO-OP placeholder shims:
  - `ResourceFind(...) -> Recon()` (mechrecon.hpp:86)  [stubs ResourceFile::Find FUN_00407064]
  - `ResourceStream` (mechrecon.hpp:117-119) = template-ctor no-op; SegmentCount()=0 -> 0 subsystems
  - `ResourceFindByName`, `LoadSkeleton`, `WorldTransform`, `ResourceManagerHas` = same no-op shims
  - `Wword(i)` (mechrecon.hpp:188) = a single shared `static BTVal bank[0x400]` SCRATCH bank: every raw
    `this[0xNN]` in mech.cpp reads/writes a throwaway slot, NOT real object memory. ~145 sites in mech.cpp.
CONSEQUENCE: the Mech ctor compiles and runs but never streams its model (segment 0xf), subsystem list
(0x11), damage zones (0x14) or skeleton; `model` is NULL and the model-resource handle `Wword(0x6f)`
(set by the BASE ctor in the binary, an inherited field) is 0. So NO functional mech can be constructed.
Every further mech-ctor fault (407, 591, 641, ...) is one symptom of this same root - guarding them one
by one yields only a hollow, non-functional mech. This is exactly the "THE SUBSYSTEM FACTORY" + "~180 raw
this[0xNN]" item flagged for a dedicated pass (see CLAUDE.md mech-core / Roadmap Track 2).
NEXT (dedicated factory pass, NOT a fault-grind): (a) map the ~145 Wword(0xNN) sites + the segment-record
fields (0xba/0xbb) and model handle (0x6f) to REAL Mech/base members at the documented offsets; (b)
implement ResourceFind/ResourceStream/ResourceFindByName against the real engine ResourceFile::Find over
the BT .res segment format (0x11/0xf/0x14/0x1e/0x1d); (c) verify the ModelResource/SubsystemSegment field
layouts vs the binary; (d) then the per-class subsystem factory (CreateStreamedSubsystem/DefaultData)
actually instantiates subsystems. Oracle = Mech ctor FUN_004a1674 (part_012.c @9696, 5690 bytes).
Files touched this session: decomp/reconstructed/btplayer.{hpp,cpp}, mech.hpp (MakeMessage ctor),
mech.cpp (lines ~359-361 real zero-init, ~406 heat guard), btstubs.cpp (Mech::Reset). Build GREEN, 0 errs.

## ============ STAGE 5: MECH STREAMS + CONSTRUCTS (resource-streaming pass, 2026-06-30 sess 3) ============
GOAL of this pass: replace the no-op resource-streaming shims with REAL engine streaming + map the
raw object-layout fields to real members, then grind faults until the Mech is fully constructed.
RESULT: **the Mech now constructs end-to-end from real streamed resources**, the spawn pipeline +
control-mapping binding complete, and the game advances into mission-entity RENDER setup.

FAULT LADDER CLEARED (each = real reconstruction unless noted):
  8. mech.cpp:641  model = ResourceFind(...) == NULL  (THE documented frontier).  ROOT: mechrecon
     ResourceFind/ResourceStream were no-op shims (SegmentCount()=0).  FIX (REAL streaming): added
     MechFindResource() = application->GetResourceFile()->SearchList(creation_message->resourceID, type)
     -- the exact engine idiom the JointedMover base ctor + RP/VTV use.  Rewrote BOTH passes:
       - Pass 1 (subsystems, segment 0x11 SubsystemModelStreamResourceType): MemoryStream over the
         locked resource; header int = subsystem count; per-blob loop reads Subsystem::SubsystemResource
         via GetPointer()/AdvancePointer(subsystemModelSize).  (mirrors VTV::VTV @1379-1583)
       - Pass 2 (model, segment 0xf GameModelResourceType): model = res->resourceAddress (kept locked).
     `Wword(0x6f)` handle -> creation_message->resourceID (authoritative; base ctor already streamed
     the skeleton from it).  -> model non-NULL, subsystem stream real.
  9. mech.cpp:729  *(float*)(this + 0x15d) = ...  AV.  ROOT (decompiler artifact): typed-pointer
     arithmetic on Mech* (this + 0x15d == this + 0x15d*sizeof(Mech) == +0x89028).  FIX: route to the
     Wword(0x15d/0x15e) scratch bank (the decomp intent is word slot this[0x15d], an unnamed pose angle).
 10. **OBJECT-LAYOUT BUG (the big one):** mech.hpp re-declared `int subsystemCount; Subsystem **subsystems;`
     -- these SHADOWED the inherited Entity base members `subsystemCount` / `subsystemArray` that the
     engine reads in Entity::GetSimulation/GetSubsystem.  The ctor streamed into the shadow members, so
     the engine never saw the roster (GetSimulation returned NULL).  FIX (REAL layout mapping): removed
     the shadow decls; renamed all mech.cpp `subsystems` -> inherited `subsystemArray`; `subsystemCount`
     now resolves to the Entity base field.  this[0x49]/this[0x4a] === Entity::subsystemCount/subsystemArray.
 11. MechTech::MechTech (mechtech.cpp:213) AV walking owner->GetSubsystem(0..count): array TAIL was
     uninitialised heap garbage (loop only zeroed the current slot).  FIX: zero the WHOLE subsystemArray
     right after allocation (every not-yet-filled slot must read NULL for roster scans).
 12. MechTech roster walk AV: the streamed roster entries were HOLLOW stubs (RECON_SUBSYS = empty
     ReconSubsystemStub, no vtable) -> sub->IsDerivedFrom() faulted.  FIX (REAL base wiring): made
     ReconSubsystemStub DERIVE FROM the real MechSubsystem base (proven ctor -- MechTech uses it), so
     every streamed entry is now a genuine registered, vtable-valid Subsystem WITH a DamageZone.
     -> **Mech::Mech now RETURNS (full construction: model + 31 streamed subsystems + MechTech walk).**
 13. btl4app.cpp:554 Fail("Mech has no controls mapping"): primaryControlType==None on a dev box (no
     RIO/Thrustmaster joystick).  FIX (bring-up): default case falls back to MechRIOMapper (the pod's
     real L4 device) instead of Fail.  FLAGGED -- keyboard/gamepad remap is a pod Phase-8 task.
 14. mechmppr.cpp:327 (MechControlsMapper ctor) AV: torso-recenter reads a ptr at the BINARY byte
     offset owner+0x438 then derefs it -- invalid because the RECONSTRUCTED Mech layout != binary's
     0x854.  FIX (bring-up GUARD): skipped (the Mech ctor already identity-inits the torso aim, so it
     starts centered).  FLAGGED -- re-enable via a named accessor once cross-module layout is mapped.
 15. L4CTRL CreateStreamedMappings -> GetSimulation(0) == NULL -> GetAttributePointer on NULL.  ROOT:
     the streamed control-mapping resource binds DirectMappings to subsystemID 0 (the ControlsMapper
     slot, cf. VTV::ControlsMapperSubsystem==0), but Mech::SetMappingSubsystem was a no-op STUB, so
     subsystemArray[0] stayed NULL.  FIX (REAL, mirrors VTV::SetMappingSubsystem): SetMappingSubsystem
     now installs the mapper into subsystemArray[0] (+ mirrors controlsMapper).  -> control binding runs.
 16. btplayer.cpp:225 VehicleDeadMessageHandler AV: scenarioRole->GetReturnFromDeath() on a NULL role
     (scoring role not looked up for the minimal TEST.EGG; btplayer.cpp:815 deferred).  FIX (guard,
     consistent w/ the existing :644 null-role handling): only debit a life when scenarioRole != 0.

### END STATE
The Mech is **fully constructed from streamed resources** and spawned; controls bind; the mission loads
entities and enters the RENDER path.  Boot now reaches:
  "Entity 1:NN classNN couldn't figure out how to MakeEntityRenderables" (the stubbed BT renderable
  module) then AV at **btl4vid.cpp:808** BTL4VideoRenderer::SetupMaterialSubstitutionList ->
  NotationFile::GetEntry -> NotePage::FindNote.  CAUSE: the renderer looks up the mech's egg
  color/badge/patch via entity->GetAttributePointer("VehicleColor"/"VehicleBadge"/"VehiclePatch") -- a
  FLAGGED cross-family gap (those egg strings aren't in the attribute index; the call returns garbage
  that FindNote then derefs).  This is the BT video-renderer / material-substitution module (btl4vid.cpp,
  NOT a mech-construction file) -- the "ideally renders" frontier, a separate reconstruction task.

### REMAINING STUBS / GUARDS introduced or relied on this pass (bring-up worklist):
  - mech.cpp RECON_SUBSYS subsystems: now real MechSubsystem-derived objects but with MINIMAL class
    behaviour (Cockpit/Sensor/Generator/Gyro/Myomers/weapons/... all share the base body).  Per-class
    reconstruction (use the existing sensor.cpp/gyro.cpp/gnrator.cpp/powersub.cpp/emitter.cpp/... real
    classes in the switch) is the next refinement.  6 classes have NO real recon at all (Cockpit,
    Actuator, JumpJet, LegSubsystem, HeatSinkSource, MechDisplay).
  - mech.cpp Pass 3 (damage-zone segment 0x14) + crit-subsystem (0x1e) + standing-anim (0x1d): still use
    the mechrecon shim proxies (damageZoneCount scratch==0 -> loops inert).  Not yet real-streamed.
  - mech.cpp model field reads (Pass 2): write mostly to the Wword scratch bank; the Mech__ModelResource
    struct offsets vs the on-disk GameModel record are unverified (reads are buffer-safe, values unused
    on the critical path).  The capability sub-rosters (heatable/powered/damageable) stay EMPTY because
    the SubProxy::IsDerivedFrom shim returns 0 (no per-frame consumer reached yet).
  - mechmppr.cpp:327 torso-recenter: GUARDED/skipped (layout-dependent raw offset).
  - btl4app.cpp default controls case: MechRIOMapper fallback (no-joystick dev box).
  - btplayer.cpp:225 scenarioRole debit: NULL-guarded (no scoring role in TEST.EGG).
  - btstubs.cpp SetMappingSubsystem: now REAL (slot 0 install).  Remaining btstubs stubs unchanged.

### NEXT (for whoever continues): the render path.  btl4vid.cpp SetupMaterialSubstitutionList needs the
  mech's egg color/badge/patch (resourceNameA/B/C, set in the Mech ctor from the MakeMessage) exposed to
  the renderer -- either via the attribute index ("VehicleColor"/...) or a named Mech accessor -- and the
  VEHICLE table entries to match.  Then the BT renderable module (BTWorldContainer/DCSObject/... ctors,
  currently btstubs) must be reconstructed for MakeEntityRenderables to actually build geometry.

## ============ STAGE 6: RENDER PATH RECONSTRUCTED — mech tree builds + presents (black: asset gap) ============
GOAL: clear the render-path faults until a frame draws (mech in cavern) or reach the deepest render fault.
RESULT: the BT world-render path is reconstructed and runs end-to-end to a STABLE PRESENTING FRAME with no
crash; the mech's 51-segment renderable tree + cockpit camera build correctly.  The frame is currently
BLACK — honest status: nothing visibly draws — but the cause is now precisely localised to a CONTENT
(asset-pipeline) gap, NOT a render-code fault.  Files touched: decomp/reconstructed/btl4vid.{cpp,hpp}.

FAULT LADDER CLEARED (each a real fix):
  R1. btl4vid.cpp:808 SetupMaterialSubstitutionList AV (strcmp NULL) — GetEntry("color",egg_color,..)
      with egg_color from GetAttributePointer("VehicleColor") returns garbage; NotePage::FindNote
      deref-crashed.  FIX (mirrors RP RPL4VID.cpp:1562 which tolerates a missing colour/badge): the egg
      color/badge/patch reads are NULL-guarded and a table miss is no longer fatal (was Fail("Exiting"))
      — veh_color/badge/patch stay NULL and the %placeholder% substitution drops to default materials.
      TODO(bring-up): re-wire the real egg names (Mech::resourceNameA/B/C @0x844/0x848/0x84c) via a named
      accessor once the Mech layout is mapped; the attribute-index path is not wired.
  R2. ARCHITECTURE PIVOT — the recovered MakeMechRenderables built a 1996 pre-DPL renderable hierarchy
      (BTRootRenderable/BTHingeRenderable/... parenting on raw dpl_DCS*) on top of VideoComponent, which
      WinTesla never implemented (it was superseded by VideoRenderable; btstubs.cpp had to stub
      VideoComponent + every BT*Renderable just to link → all inert → "couldn't MakeEntityRenderables").
      FIX (the real work): REWROTE BTL4VideoRenderer::MakeMechRenderables to build the tree with the
      engine's WORKING D3D renderables — RootRenderable / HingeRenderable / BallJointRenderable /
      BallTranslateJointRenderable / DPLStaticChildRenderable / DPLEyeRenderable (MUNGA_L4/L4VIDRND) —
      exactly as RP's port does (RPL4VideoRenderer::MakeJointedMoverRenderables / RecurseSKLFile).  These
      self-register (RootRenderable→AddRenderable; VideoRenderable→AddDynamicRenderable), build their own
      DCS, parent on the PARENT RENDERABLE (HierarchicalDrawComponent*, not a dpl_DCS*), and hook the root
      to entity->localToWorld.  Walks the EntitySegment table; per segment loads geometry via
      d3d_OBJECT::LoadObject(GetDevice(), "<name>.bgf"), picks Hinge/Ball/BallTranslate/Static by joint
      type, and builds the cockpit camera (DPLEyeRenderable→mCamera) at the "siteeyepoint" site.
      MakeMechRenderables return type VideoComponent* → HierarchicalDrawComponent* (.hpp updated); the
      caller no longer double-registers via the AddDynamicRenderable stub.  The BT*Renderable stubs in
      btstubs.cpp are now DEAD CODE for the body (kept for link; the 2D reticle path still references the
      BTReticleRenderable stub but that block is deferred — see below).
  R3. _RTC_UninitUse at L4VIDEO.cpp:5211 (DPLRenderer::MakeEntityRenderables) — exposed when the default
      (non-mech) case was routed to DPLRenderer::MakeEntityRenderables.  ROOT (pre-existing ENGINE port
      bug): `this_instance` is used uninitialised (the DPL-stubbed engine left its assignment commented
      out) and /RTC1 traps it.  FIX (faithful + safe): the default case calls the generic base
      VideoRenderer::MakeEntityRenderables (FUN_0045e744) — which is exactly what the shipped BT renderer
      did (it deferred to the grandparent "couldn't figure out how to MakeEntityRenderables" handler, NOT
      the DPL prop builder).  Non-mech props/terrain pieces therefore log + draw nothing for now.
      TODO(bring-up): route world props through DPLRenderer::MakeEntityRenderables once that engine
      uninitialised-`this_instance` gap is fixed (out of scope here — shared engine source).

END STATE / VERIFIED BY DIAGNOSTICS (btl4.log, flagged [BTrender] lines):
  "[BTrender] MakeMechRenderables: 51 segments, view=1"        <- render path runs, inside (cockpit) view
  "[BTrender]   no mesh for 'blx_cop.bgf' (expects VIDEO\*.x)" <- geometry load FAILS
  "[BTrender] mech tree built: meshes 0/1 loaded, eye=1"       <- tree + camera built OK; 0 meshes loaded
  Window: 804x600 "BattleTech", stable, ALIVE@20s+, no crash, captured frame = solid black.

DEEPEST RENDER FAULT REACHED = ASSET PIPELINE GAP (not code):
  d3d_OBJECT::LoadObject (MUNGA_L4/L4D3D.cpp:47) loads `VIDEO\<name>.x` via D3DXLoadMeshFromXA — i.e. the
  WinTesla D3D renderer consumes Direct3D .x meshes produced by the port's MeshExp exporter.  The BT pod
  content tree ships 879 `.bgf` (DIV-BIZ2) files and ZERO `.x` files (VIDEO\ + VIDEO\GEO\).  So EVERY
  segment mesh resolves to NULL → renderables are built with a NULL graphicalObject → nothing is drawn →
  black clear.  Inside (cockpit) view requests only the cockpit shell (blx_cop); the 50 body segments have
  no inside-view object name (correct — you're inside the mech).  To actually SEE geometry the .bgf models
  must be exported to .x into VIDEO\ (the MeshExp/ASSET_PIPELINE task), and/or use the OUTSIDE view to load
  the full body.  Terrain/cavern likewise needs either the prop path (R3 TODO) or environment build.

REMAINING STUBS/GUARDS in the render path (bring-up worklist):
  - SetupMaterialSubstitutionList: egg color/badge/patch forced NULL (default materials).  TODO: wire real
    Mech::resourceNameA/B/C.
  - Inside-view targeting reticle (BTReticleRenderable + AddWeapon pips) and per-subsystem weapon/effect
    renderables (PPC/emitter beams, projectile tracers, coolant, searchlight) NOT built — they depend on
    the unported dpl2d_ 2D layer (btstubs.cpp, all inert) + the BT effect renderables (btstubs.cpp).  These
    are the HUD/weapons render bring-up; not needed for the mech body.
  - dpl2d_* (9 fns) + dpl_SetMaterialNameCallback: still inert stubs (btstubs.cpp).
  - Non-mech entity default → VideoRenderer base (no-op + log); props/terrain not rendered (R3 TODO).
  - [BTrender] DEBUG_STREAM diagnostics left in MakeMechRenderables (low volume; remove at cleanup).

================================================================================
PASS: .BGF MESH LOADER (close the asset-pipeline gap so meshes actually load)
================================================================================
PROBLEM (from prior pass): d3d_OBJECT::LoadObject loaded VIDEO\<name>.x via
D3DXLoadMeshFromXA, but the pod ships 879 original .bgf (DIV-BIZ2) models and ZERO
.x -> every segment mesh resolved NULL -> "meshes 0/1 loaded" -> black frame.

FIX (engine mesh loader now reads .bgf natively):
  - NEW MUNGA_L4/bgfload.{h,cpp}: C++14 port of the proven port/src/bgf.cpp loader.
    Parses DIV-BIZ2 (OBJECT->LOD->PATCH->PMESH; quads triangulated; per-PATCH
    SV_SPECIAL material name), resolves .bmf material libs + texture image basenames,
    produces L4VERTEX-compatible verts (XYZ|NORMAL|DIFFUSE|TEX1) + 32-bit index list
    + per-material draw batches. Directory scanning uses Win32 FindFirstFile (NOT
    <filesystem>) so it builds under the engine's C++14 target. Asset resolution:
    recursively indexes VIDEO\ (covers VIDEO\GEO, VIDEO\GEO\<theme>, VIDEO\MAT...),
    basename(lower)->path; LoadObject("blx_cop.bgf") -> VIDEO\GEO\BLX_COP.BGF.
    Geometry is emitted DOUBLE-SIDED (both windings) so it is visible regardless of
    the engine's global D3DCULL_CW (no .x exporter survives to confirm winding);
    smooth normals computed from the forward winding only.
  - L4D3D.cpp: new static d3d_OBJECT::LoadObjectBGF — builds an ID3DXMesh
    (D3DXCreateMeshFVF, MANAGED|32BIT, L4VERTEX_FVF), fills VB/IB, writes one
    attribute id per face = batch index, GenerateAdjacency + OptimizeInplace(ATTRSORT)
    to build the attribute table, then constructs the mesh-backed d3d_OBJECT and fills
    mDrawOps per batch: material Diffuse(+Ambient) from the resolved .bmf color, and a
    decoded texture (port/src/image.cpp decodeImage -> D3DFMT_A8R8G8B8 managed tex).
    LoadObject now falls through to LoadObjectBGF when D3DXLoadMeshFromXA fails (the
    .x path is kept as a fallback), before LoadSpheres.
  - port/src/image.cpp (tga/vtx/bsl decoder, C++14-clean) added to the engine build;
    enginebuild/CMakeLists.txt: + bgfload.cpp, + image.cpp, + port/src include dir
    (no header-name collisions with the engine; verified).

VERIFIED (btl4.log, flagged [BTrender]/[BTdraw] lines):
  "[BTrender] mech tree built: meshes 1/1 loaded, eye=1"   <- inside view: cockpit
        shell blx_cop.bgf now LOADS (was 0/1). N>0 achieved.
  Forced-outside experiment (skeletonType_N, reverted): "meshes 12/12 loaded"
        -> loader handles the full mech body too (12 segments w/ geometry, 0 failures).
  [BTdraw] diagnostic (added then removed): opaqueList=1, batches=9, every frame
        -> the cockpit mesh REACHES the opaque pass list and issues 9 DrawSubset calls
        per frame. The load->D3D-buffer->rasterize pipeline works end to end.

FRAME STATE: still BLACK in the default inside view (captured the BattleTech client
        region via screen grab; solid black even with materials forced fully Emissive
        and with the full body loaded). So this is NOT a loader/lighting problem -- the
        geometry IS rasterized but projects outside the eyepoint camera's frustum.
        ROOT (out of scope here, R2/R3 render-tree + camera): the inside view places the
        camera at the cockpit "siteeyepoint"; the player's own cockpit shell / body sit
        at/behind that eyepoint, and there is NO world to see ahead (terrain not built;
        other entities still hit the default VideoRenderer base = "couldn't figure out
        how to MakeEntityRenderables", R3 TODO). Original BT drew the world through the
        canopy + a 2D gauge HUD (dpl2d, unported). So black is expected for the current
        port state -- a VISIBLE mech needs either an external/chase camera looking at the
        body, or routing enemy JointedMovers through MakeMechRenderables so a mech renders
        ahead. Neither is the asset pipeline; both are render-tree/camera work.

HONEST MILESTONE READ: the asset-pipeline gap is CLOSED (meshes load: 1/1 cockpit,
        12/12 body; rasterized 9 batches/frame). The window is still black because the
        only loaded geometry is the player's own shell behind the eyepoint with no world
        ahead -- a camera/world-render gap, not a mesh gap. Per the strict milestone
        ("window shows geometry, not black"), the on-screen mech is NOT yet achieved.

REMAINING GAPS (next pass, in priority order):
  - Camera/visibility: add an external view (or capture an enemy mech) so loaded body
    geometry lands in the frustum; verify winding (currently double-sided as insurance).
  - Textures: most BT materials resolve to .bmf diffuse COLORS; only ~47 .vtx/.bsl exist
    in the tree, so most batches are flat-colored (no texture). Texture coverage + the
    egg color/badge/patch substitution (SetupMaterialSubstitutionList, still NULL-forced)
    remain for a faithful skin.
  - World/props/terrain rendering (R3) + 2D cockpit HUD (dpl2d_, btstubs inert).

---

## MECH VISIBLE ON SCREEN — first rendered BattleMech (external chase camera)

**WIN:** `btbuild/run/frame.png` shows a flat-shaded Avatar BattleMech (torso, both arms +
gun pods, both legs + feet/toes, hip) centered in the BattleTech window. 12/12 body meshes
assembled and rasterized.

### What was wrong (diagnosis chain)
1. The default player view is `insideEntity` -> `MakeMechRenderables` built the INSIDE
   skeleton (SkeletonType_A) and put the camera AT the cockpit eyepoint; no body geometry,
   nothing ahead -> black.
2. Forcing the OUTSIDE body + adding an external camera still gave black. Instrumented
   `DPLEyeRenderable::Execute` (L4VIDRND.cpp): camera WAS correct — ~29 units in front of the
   mech (mech localToWorld vs camera pos), look-dir within ~5deg of the mech centre.
3. Instrumented the opaque pass: the 12 mech body meshes WERE submitted (DrawSubset) with
   correct world matrices clustered at the mech's world position. Still black. CULLMODE=NONE
   did not help -> not backface culling.
4. **Root cause:** logged the device transforms at draw time — the PROJECTION matrix was
   uninitialised garbage (every entry ~ -4.3e8). `BTL4VideoRenderer::LoadMissionImplementation`
   was an **empty stub** (btstubs.cpp), so `DPLReadEnvironment` never ran and
   `DPLRenderer::mProjectionMatrix` (a private member) was never built -> all geometry clipped.
   Compounded by `D3DXMatrixPerspectiveFovLH` mismatching the `D3DXMatrixLookAtRH` view.

### Changes made
- `decomp/reconstructed/btl4vid.cpp` `MakeMechRenderables`:
  - For the player's own mech (originally `insideEntity`) force the OUTSIDE body build
    (loads all 12 body meshes) and, after the tree is built, install a fixed external chase
    camera: `DPLEyeRenderable` parented to `this_root` with a hand-built `LinearMatrix`
    offset (camera at mech-local (0,9,-28), looking at (0,6,0); +Z=look, +Y=up, W=pos).
- `MUNGA_L4/L4VIDEO.cpp`:
  - `DPLReadINIPage` projection: `PerspectiveFovLH` -> `PerspectiveFovRH` (match the RH view),
    dropped the `mProjectionMatrix(0,0)*=-1` X-flip.
  - Added `DPLRenderer::EnsureValidProjection()` (decl in L4VIDEO.h) — builds a valid RH
    projection from the private members + bright ambient + fog off.
  - Opaque pass: `CULLMODE=NONE` and `LIGHTING=FALSE` (flat-shaded so the mech shows without
    scene lights).
- `decomp/reconstructed/btstubs.cpp`: `BTL4VideoRenderer::LoadMissionImplementation` now calls
  `EnsureValidProjection()` instead of being empty.
- Temporary diagnostics still present (gated to first few calls): `[EYE]`, `[DRAW]`, `[VP]`
  logging in L4VIDRND.cpp / L4D3D.cpp / L4VIDEO.cpp.

### Remaining work for a proper external view
- The current camera is a hard-coded DEBUG chase cam forced on the player mech. A real
  spectator/chase view-mode should be a toggle wired through `BTL4Application` (view mode),
  not a forced override inside `MakeMechRenderables`.
- Mech sits slightly low/small; tune offset (raise target, pull closer) or frame from the
  mech bounding box.
- `EnsureValidProjection` + opaque-pass `LIGHTING=FALSE`/`CULLMODE=NONE` are debug shortcuts.
  Proper fix: implement the real `LoadMissionImplementation` (call `DPLReadEnvironment`) so
  the per-mission viewangle/clip/fog/ambient/lights/paths from BTDPL.INI are honoured, then
  restore lighting + correct cull winding (and verify the RH projection against RP).
- Strip the `[EYE]`/`[DRAW]`/`[VP]` diagnostics once stable.
- Intermittent: ~1 run in 2 crashes during the segment loop before "mech tree built"
  (pre-existing reconstructed-code instability, unrelated to the camera/projection fix).

## ============ STARTUP-CRASH FIX (the intermittent ~1-in-6 heap corruption) ============
Symptom: exit 0xC0000374 (STATUS_HEAP_CORRUPTION), intermittent (2/12 runs), in the Mech ctor
subsystem loop. Diagnosis: debugger masked it (corruption, not AV); nailed via **gflags PageHeap**
(/p /enable btl4.exe /full) which faults at the exact bad access.
ROOT (two object-layout overflows in mech.cpp's subsystem construction):
  1. mech.cpp:654 HeatableSubsystem allocated only **0x104** bytes, but the shared MechSubsystem base
     ctor WRITES this[0x44] (byte 0x110, vitalSubsystemIndex) -> 16-byte write past the allocation =
     heap corruption. FIX: bumped to 0x140 (base extent is 0x114; all other subsystems were already
     >=0x130). THIS was the corruption. (PageHeap caught it at mechsub.cpp:161.)
  2. mech.cpp:497 the subsystem-resource MemoryStream wrapped the .res segment at exact size; the base
     ctor reads each record to res+0xe0, overrunning the buffer for short/last records (controls mapper).
     FIX: stream over a zero-padded (+0x100) copy. (Read-overflow; PageHeap caught at mechsub.cpp:165.)
VERIFIED: PageHeap off, **30/30 runs clean, 0 crashes** (was ~17%). Crash fixed.
RESIDUAL (NOT the crash; latent over-reads PageHeap flags but that read valid adjacent heap in normal
runs, e.g. mech.cpp:741 reading +0x108): object-layout debt -> fold into the Mech layout reconstruction.
Tooling note: gflags needs an ELEVATED prompt; user enabled/disabled. btl4main.cpp has a dormant
BT_HEAPCHECK #ifdef (CRT heap validation) for future hunts.

## ============ WORLD/TERRAIN VISIBLE — mech now stands in the cavern(des) world ============
**WIN:** `btbuild/run/world.png` shows the player mech standing on TEXTURED DESERT TERRAIN
(the `cavern`->`des_day` environment) with a horizon + midground structures, instead of the
black void. 3/3 stability runs clean, no crash. Engine + game both build green.

### Diagnosis chain
1. Set `L4DPLCFG=BTDPL.INI` + wired the real env load (see changes) -> the DPL per-entity
   builder began processing world props (`bld08_lp`, `dish_lp`, `mslr_LP`, `ctar/dtar/calp_lp`)
   but the run then crashed (0xC0000005) in `DPLRenderer::ConsolidateSingleObject`
   (L4VIDEO.cpp:2138), `mov eax,[edx]` edx=0.
2. ROOT: the pod ships `.bgf`, loaded by `d3d_OBJECT::LoadObjectBGF` with **D3DXMESH_32BIT**
   (L4D3D.cpp:212). `ConsolidateStaticObjects` (the post-load static-mesh merge) called
   `D3DXConcatenateMeshes` with only `D3DXMESH_MANAGED` (16-bit output) -> concatenating
   32-bit-index source meshes into a 16-bit output FAILS, leaving `outMesh==NULL`, then
   `outMesh->GetNumFaces()` dereferenced NULL. RP never hit this (its world loads from `.x`
   as 16-bit). This static-consolidation path had NEVER run for BT before, because the world
   default-case was previously a no-op (no static objects existed to consolidate).

### Changes made (all in owned files)
- `btbuild/btl4main.cpp`: added `putenv("L4DPLCFG=BTDPL.INI")` (alongside the other env
  defaults) so `DPLReadEnvironment` reads BT's real renderer config (paths/clip/fog/lights/
  ambient/background/cached shapes), not `dpldflt.ini`. (RP set `RPDPL.INI`.)
- `decomp/reconstructed/btstubs.cpp` `BTL4VideoRenderer::LoadMissionImplementation`: now calls
  `DPLRenderer::LoadMissionImplementation(mission)` (-> `DPLReadEnvironment` + `LoadNameBitmaps`,
  exactly like `RPL4VideoRenderer::LoadMissionImplementation`), then `EnsureValidProjection()`
  as a safety net (mProjectionMatrix is private here; this guarantees a valid RH projection +
  fog off so the mech/terrain are not clipped/fogged). Was previously an empty stub that only
  called EnsureValidProjection -> env never loaded.
- `decomp/reconstructed/btl4vid.cpp` `MakeEntityRenderables` default case: route non-mech
  entities (terrain/props/landmarks) to `DPLRenderer::MakeEntityRenderables` (the DPL prop
  builder) instead of the no-op `VideoRenderer::MakeEntityRenderables` grandparent -- this is
  what RP's default does (RPL4VID.cpp:1436) and is what actually loads world `.bgf` into the
  scene.
- `MUNGA_L4/L4VIDEO.cpp`:
  - `ConsolidateSingleObject`: pass `D3DXMESH_MANAGED | D3DXMESH_32BIT` to
    `D3DXConcatenateMeshes` (match the 32-bit source meshes); init `outMesh=NULL` and return
    NULL on failure with a log line instead of dereferencing NULL. Both callers in
    `ConsolidateStaticObjects` now skip a NULL result. **This was the crash fix.**
  - `MakeEntityRenderables` CulturalIcon/Landmark arm: initialise `dpl_INSTANCE *this_instance
    = NULL` (the per-object instance assignment is DPL-stubbed/commented out) so the /RTC1
    uninitialised-variable check can't fault if a CulturalIcon/Landmark entity is built.

### What renders / what doesn't
- RENDERS: desert ground/terrain (textured), horizon, midground structures, the player mech
  positioned on the terrain at world ~(275,-0.35,48). Static terrain meshes consolidate cleanly
  (no D3DXConcat-skip log).
- NOTE: `BT/VIDEO/GEO/CAVERN/` is EMPTY in this content tree; `cavern` branches to `des_day`
  in BTDPL.INI, so the "world" is the desert/arena prop set in `VIDEO/GEO/` (buildings, dishes,
  missile launchers, targets) -- which the recursive `.bgf` index finds and loads.
- STILL FAILS (harmless): 28 `*_LP.bgf` (low-poly distant-LOD variants: bld08_lp/dish_lp/
  mslr_lp/ctar_lp/dtar_lp/calp_lp). Their high-poly counterparts (BLD08/DISH/MSLR/CALP) ARE
  present and load; the `_LP` files are tiny (216-750B) valid DIV-BIZ2 that the bgf parser
  (bgfload.cpp) rejects -- this is the pre-existing BGF-loader gap (CLAUDE: 621/663 load), NOT
  a terrain-path regression. Fixing the LOD parse would add the distant-LOD billboards.

### Remaining / next
- Capture gotcha (for future sessions): the D3D9 window is windowed; `PrintWindow` returns
  BLACK (can't read the D3D backbuffer) and plain `CopyFromScreen` grabs whatever occludes it.
  WORKS: `SetWindowPos(h, HWND_TOPMOST, 0,0,820,640, SWP_SHOWWINDOW)` then `CopyFromScreen` at
  the client rect -> real frame.
- The chase camera + `EnsureValidProjection`/opaque-pass `LIGHTING=FALSE`/`CULLMODE=NONE` are
  still the debug shortcuts from last pass; now that the env loads, the INI lights/fog/ambient
  could be honoured (restore lighting + correct cull winding) once verified against RP.
- Fix the `_LP` BGF parse (bgfload.cpp) to add distant-LOD props; wire the dpl2d_ HUD.

---

## Tier 2 — DRIVABLE mech (locomotion + camera follow)  [this session]

**WIN: the player mech walks under control and the chase camera follows.**
Verified with forced throttle (headless): position log Z 493.156 -> 160.363
(monotonic, ~30 u/s at full throttle), and the per-render `[EYE] Execute
entityL2W.t` tracks the moving mech each frame (camera follows by
construction). Two warm screenshots (`run/walk_t1.png`, `run/walk_t2.png`) show
the mech centered while the background structures shift. Default (no-throttle)
run is stable: mech spawns idle, no drift, no crash.

### Root cause: mech rendered but never SIMULATED
The mech rendered every frame (EYE/DRAW) but its `localToWorld` was static. The
reconstructed per-frame tick (`Mech::Simulate` via `activePerformance`, set from
a `Recon`->null member-fn-ptr, and full of `this+0xNN` byte-offset-as-index
bugs) is unsafe and was never reached. Two engine gates also block a fresh
master entity from being executed:
1. `Entity::Execute` only calls `PerformAndWatch` when the app is in
   `RunningMission`/`EndingMission` **or** the entity `IsPreRunnable()`
   (ENTITY.cpp ~549). The bring-up never reaches RunningMission.
2. `UpdateManager::Execute` skips a master unless `IsInteresting()`
   (`interestCount!=0`) `&& IsNonReplicantExecutable()` (UPDATE.cpp:148).

### What was changed (4 files; engine untouched)
- `decomp/reconstructed/mech.hpp` / `mech4.cpp`: added
  `Mech::PerformAndWatch(const Time&, MemoryStream*)` — an **override of the
  engine virtual** `Simulation::PerformAndWatch` (the director calls it every
  frame on every entity; stasis/subsystem/activePerformance machinery lives in
  the *base* `Mover::PerformAndWatch`, which we deliberately bypass). It reads
  the drive input, integrates the engine-base `localOrigin` (turn -> yaw about
  world +Y; forward = mech-local -Z from the rebuilt matrix; advance in the
  ground plane preserving Y) and rebuilds `localToWorld` — the matrix the render
  tree AND the chase camera (btl4vid.cpp) are bound to. Bypasses the unsafe
  Simulate/subsystem chain (that's a later step). Logs world pos at 1 Hz while
  moving. Tuning: 30 u/s full throttle, 1.2 rad/s full turn (hand-picked; the
  animation `.ani` `[RootTranslation]` clip-speed path is future work).
- `decomp/reconstructed/btstubs.cpp`: `Mech::Reset` (spawn hook) now sets
  `SetPreRunFlag()` + forces `interestCount = 1` so the update manager ticks the
  mech regardless of mission-run state. Added `Mech::IsDisabled()` stub
  (return False) — was declared but undefined; the new vtable pulls mech2/mech4
  into the link which referenced it.
- `btbuild/btl4main.cpp`: keyboard drive input wired in `WndProc`
  (WASD / arrow keys -> `gBTDrive.throttle`/`turn`). `gBTDrive.forced` is a
  DEBUG toggle (env `BT_FORCE_THROTTLE`, default OFF) used only for headless
  verification (full-ahead, no keypress).

### Notes / caveats (flagged)
- Single local-player assumption: heading is a file-static in mech4.cpp. AI/
  multiplayer mechs would need per-entity state (out of scope; Phase 7/8).
- Idle (no input) the mech re-asserts yaw=0 each frame, overriding any egg
  spawn facing (minor; documented). Position is preserved.
- The bypass skips collision + the real animation-driven gait/`SequenceController`
  clips. Next: drive `commandedSpeed` through the controls-mapper subsystem and
  integrate the `.ani` `[RootTranslation].z` per-clip speed (the established
  animation-driven locomotion model) instead of a flat tuning constant.
- Render is slow in the Debug build (~0.6 fps on the big desert scene); the
  simulation runs ~real-time (dt~0.017). Capture gotcha unchanged: grab a WARM
  frame (>=8 s) — early frames are black (backbuffer not presented yet).

---

## Wave: per-frame SUBSYSTEM SIMULATION TICK wired into Mech::PerformAndWatch

Goal: turn the drivable mech into a live combat harness by ticking the mech's
subsystem roster every frame, WITHOUT calling the unsafe reconstructed
`Mech::Simulate` (raw `this+0xNN`-as-index bugs, null `activePerformance`).

### What was wired (how the tick reaches the subsystems)
Mirrored the shipped engine's `Entity::PerformAndWatch` roster loop
(`MUNGA/ENTITY.cpp` ~698-790; RP's `VTV` ticks its roster the identical way).
In `Mech::PerformAndWatch` (mech4.cpp), AFTER the existing drive/movement
integration and BEFORE `WriteSimulationUpdate`, we now walk the inherited Entity
roster `subsystemArray[0..subsystemCount-1]` and, for each non-null subsystem,
call the **engine** virtual `subsystem->PerformAndWatch(till, update_stream)`.
That base (`Simulation::PerformAndWatch`, SIMULATE.cpp:448) computes the
subsystem's OWN time slice from its own `lastPerformance` and dispatches
`activePerformance` — the reconstructed `<Class>::<Class>Simulation` method each
subsystem's ctor installed via `SetPerformance` (heat/gyro/sensor/power/weapons/
…). We deliberately do NOT call `Mech::Simulate`. Guards: null check +
`IsNonReplicantExecutable()` (mirrors Entity).

### Per-frame confirmation (verified live, headless, BT_FORCE_THROTTLE=1)
btl4.log over a 30 s run (cwd = pod REL410\BT, `-egg TEST.EGG`):
- `[tick] first frame: dispatched to 30 executable subsystem(s) of 30 present / roster 33`
  → the dispatch genuinely reaches **all 30 real subsystems** on frame 1.
- `[tick] subsystems simulated: 1 (executable) of 30 present / roster 33` (1 Hz, steady).
  After frame 1 the subsystems still on the engine default `DoNothingOnce`
  latch `NeverExecute` (DontExecuteFlag) on their first call and drop out of
  `IsNonReplicantExecutable()` — **faithful engine behavior**. The persistent
  N=1 is the single subsystem with an always-executable real Performance. As the
  upcoming per-subsystem wave deepens each subsystem (its ctor calls
  `SetPerformance(realMethod)`), it automatically stays executable and the live
  count climbs — the tick path is already wired to carry it.
- Driving NOT regressed: `[drive] pos=...` advances on Z at ~30 u/s·dt each frame.
- Stability NOT regressed: full 30 s run, no fault (re-verified under cdb).

### Roster shape (from the run)
roster 33 = slot 0 (controls mapper, skipped — see below) + slot 1 (resolved
voltage bus) + 30 streamed subsystems + (slots that streamed NULL). 30 present,
all ticked frame 1.

### One subsystem we could NOT safely reach (flagged, skipped by design)
The **controls-mapping subsystem** (`MechRIOMapper`/`MechControlsMapper`,
installed at roster slot 0 by `Mech::SetMappingSubsystem`, mirrored to the
`controlsMapper` member). Initial wiring crashed here on the FIRST tick:
`MechControlsMapper::FillPilotArray` (mechmppr.cpp:779) does
`pilotIDs[0] = *(int*)(local_pilot+0x1e0)` where `local_pilot` is read through
UNDOCUMENTED WinTesla `Application` byte offsets (`application+0x6c → +0x190`)
that don't exist in the port → wild pointer → 0xC0000005 (its own null guards
can't catch garbage-non-null). This is an **engine gap**, not a stub.
Resolution: skip `subsystem == controlsMapper` in the tick loop. Justified —
in bring-up the player drives the mech DIRECTLY via `gBTDrive` in this same
override, so the input mapper is bypassed by design (the "bring-up RIO fallback"
path). Reaching it safely = pod-bring-up / input-remap work (CLAUDE.md Phase 8).
All OTHER subsystems tick normally.

### Gait bonus (animation-driven speed): SKIPPED (flagged)
Not landed — not quick. The flat 30 u/s `kDriveMaxSpeed` slide remains. Wiring
`.ani [RootTranslation].z` per-clip speed (as `port/` viewer does:
`g_walkPos += dt*forwardSpeedAt(anim,t)`) needs either (a) independently loading
the mech's walk `.ani` and exposing its root-translation track, or (b) calling
the reconstructed `Mech::AdvanceBodyAnimation` (which lives inside the bypassed,
still-unsafe `Simulate`/`IntegrateMotion` chain). Both are a dedicated step, not
a quick add. Deferred to the locomotion/gait wave.

### Files changed (4; engine untouched)
- `decomp/reconstructed/mech4.cpp`: added the subsystem-roster tick loop +
  `#include <subsystm.hpp>`; controls-mapper skip; 1 Hz + one-shot first-frame
  tick logs; new file-statics `gTickLogAccum`, `gTickFirstLogged`.
- `decomp/reconstructed/mech.hpp`, `mechsub.*`, `btstubs.cpp`: not modified
  (the roster + `controlsMapper` member + `IsNonReplicantExecutable` were all
  already present/sufficient).

Build: `bt410_l4` + `btl4.exe` green (only the pre-existing /FORCE:MULTIPLE
LNK4006/4088 warnings). Engine lib untouched.

## COMBAT WAVE — agent 4/7 (sensor, mechtech) — DONE, both compile-clean (exit 0)

Per-frame TICK behavior verified against binary oracle + surviving headers. Both subsystems
install a real `activePerformance` in their ctor, so neither falls back to `DoNothingOnce`
(they tick every frame, not just frame 1).

### Sensor (classID 0xBC3, ctor @004b1d18, vtable @0050fb0c)
- **Behavior reconstructed:** `SensorSimulation(Scalar)` @004b1c4c — faithful to oracle
  (part_013.c:1823). Runs `PoweredSubsystem::PoweredSubsystemSimulation` first, then derives
  the radar-effectiveness readout: `radarPercent = 1.0 - heatMaster.heatEnergy`; zeroed +
  selfTest cleared when thermal model off; `badVoltage`/blind when electrical state != Ready;
  heat-state alarm trims radar (Normal→ok, Degradation→×0.5, Failure→0). This IS the whole of
  the Sensor subsystem's per-frame work in the binary.
- **NOTE on "target sweep/acquisition/lock-on":** confirmed NOT in this class. Oracle
  FUN_004b1c4c does only the radar-effectiveness model above; target acquisition/lock/range
  lives in the HUD/radar brick (other family), not the Sensor subsystem. Did not invent it.
- **SetPerformance wired:** ctor calls `SetPerformance(&Sensor::SensorSimulation)` gated on
  `(GetSegmentFlags() & 0xC) != 4` (damaged-copy segments don't tick) — matches oracle
  `param_1[7]=PTR_FUN_0050fa94`. Also sets has-performance instance flag bit 0x8.

### MechTech (classID 0xBDC, ctor @004ad228, vtable @0050e3a0)
- **Behavior reconstructed:** `TechnicalAssistance(Scalar)` @004ad33c — faithful to oracle
  (part_012.c:16435). Iterates `subsystemMonitors`; per monitor reads watched
  `MechSubsystem::GetStatusFlags()` (vt+0x30), loops the 7 TechStatusTypes, clears expired
  wooHoo latches, edge-detects each status bit, and posts cleared/set cockpit messages on
  change (set carries `alarmModel`). Monitor roster is built in the ctor over damageable
  segments (segment bit 0x8). Faithful to oracle ctor flag gate `(entity+0x28 & 0xC) == 0`.
- **SetPerformance wired:** ctor calls `SetPerformance(&MechTech::TechnicalAssistance)` for
  live primaries; copies/templates flag dormant (this[10] |= 2) and do NOT install a
  Performance — matches oracle (MechTech sets no has-performance bit, just the perf pointer).

### CROSS-FAMILY NEEDS (locally shimmed; real homes are shared bases — unchanged from Stage 1)
- **HeatSink (heat family):** `HeatStateLevel()`, `HeatModelOff()`, `heatEnergy` accessor —
  Sensor backs these locally (heatStateLevel/heatModelOff/heatEnergy members) pending real
  inherited accessors. SensorSimulation reads them; base sim must write them once exposed.
- **PoweredSubsystem (power family):** `ElectricalStateLevel()` — backed locally (electricalState).
- **Mech/Entity/Subsystem (mech family):** `GetSegmentFlags()`, `GetSubsystemCount()`,
  `GetSubsystem(i)`, `MechSubsystem::damageZone`/`GetStatusFlags()`, `Entity::simulationFlags`.
  Currently satisfied via the shared mechrecon.hpp compat shim + entity accessors.

### Stubs (cross-family, revisit at integration — unchanged from Stage 1)
- MechTech cockpit message dispatch: `StatusMessageSink()` returns 0,
  `ReportStatusCleared`/`ReportStatusSet` are no-ops. Real impl routes through
  `*(theApplication+0x38)` + HUD message builders (FUN_004366b8/00436688/004364e4) in the
  btl4gaug/app brick (not this family). Edge-detection + latch-clear in TechnicalAssistance
  are live; only the message emission is stubbed.
- `MechTech::GetTime()` returns `Now()`; oracle compared the subsystem's cached current-time
  field (this+0x10). Behaviorally equivalent for latch expiry; revisit if a per-frame cached
  clock is wired.

## From combat/energy-weapons (mechweap, emitter; +surviving PPC/GAUSS) — DONE, 0 errors

OWNS the energy/beam weapon family: MechWeapon (abstract base), Emitter (charge/discharge beam base),
PPC + GaussRifle (surviving real source, `: public Emitter`). compile1.cmd mechweap.cpp + emitter.cpp
both exit 0.

### Per-weapon fire/heat behavior + SetPerformance wiring

- **MechWeapon (base)** — abstract; `FireWeapon()` is the "should not be fired" assert stub (matches
  oracle @004b95ec / RP GenericGun). No own performance: ctor @004b99a8 only chains to PoweredSubsystem
  + installs vtable PTR_FUN_00511d2c (verified in oracle — does NOT write this[7..9]). Per-frame
  helpers live (UpdateTargeting heat-degrades effectiveRange = (1-heatLoad)*weaponRange; CheckFireEdge
  rising-edge on fireImpulse; recharge/heat-cost fields parsed from resource). Relies on a derived
  class to install the tick → correct, since only Emitter/ProjectileWeapon are instantiable.

- **Emitter (energy base) — FIXED the missing tick wiring.** The ctor @004bb120 was mis-reconstructed
  as choosing a "fire message template" (SetFireMessage). The binary oracle proves `this[7..9]` is the
  `Simulation::activePerformance` member-pointer (same slot every sibling fills via SetPerformance) and
  the ctor installs ONE of two performances, resolved from section_dump:
    - default            : member-ptr @00511e84 = `88 aa 4b 00` -> **0x004baa88 = EmitterSimulation**
    - external model (flags&0xC==4): @00511e90 = `d0 a8 4b 00` -> **0x004ba8d0 = ServiceDischarge**
  Replaced the stub with `SetPerformance(&Emitter::EmitterSimulation)` / `&Emitter::ServiceDischarge`.
  Without this the chained PoweredSubsystem ctor's PoweredSubsystemSimulation would tick instead and the
  Loading->Loaded->Firing charge/fire machine would never run (would drop out via DoNothing-style after
  frame 1). EmitterSimulation (the full state machine), FireWeapon (slot 18, vtables.tsv 005120b8 col3 =
  4bace8 — confirmed: E=½·currentLevel²·energyCoefficient split by damageFraction into damage + self-heat,
  beam build muzzle->target, pip), TrackSeekVoltage (charge integrate + I²R heat back into source),
  ServiceDischarge / ContinueDischarge / ResetFiringState / ComputeOutputVoltage / ReadyToDischarge all
  reconstructed and live. Removed the dead SetFireMessage stand-in + the two fire-template statics.

- **PPC (surviving source, unchanged)** — ctor chains to Emitter ctor → inherits EmitterSimulation tick.
  `FireWeapon()` tail-calls `Emitter::FireWeapon()` (the post-`return` block is `#if 0` dead code in the
  original). Fires + charges per frame via the inherited Emitter machine. No edit needed.

- **GaussRifle (surviving source, unchanged)** — ctor chains to Emitter ctor → inherits EmitterSimulation
  tick. `FireWeapon()` override sets `outputVoltage = 0.0f` (drain). Declares GaussRifleSimulation +
  SetPerformance in GAUSS.HPP but the ctor never calls them → intentionally uses the inherited Emitter
  performance (faithful to shipped GAUSS.CPP). No edit needed.

### CROSS-FAMILY NEEDS
- **messaging (messmgr/SubsystemMessageManager)**: Emitter beam emit + keepalive use
  `Subsystem::SendMessage(template,a,b)` (FUN_0041c350) with message templates PTR_LAB_00511e6c/e78
  (beam-keepalive) and the fire message. ServiceDischarge/ContinueDischarge/FireWeapon currently stub the
  actual SendMessage call (templates retained as statics). Bind to the real message manager at integration.
- **heat/power (heat.hpp/powersub.hpp — NOT edited)**: Emitter charge + self-heat depend on the linked
  VoltageSource (Generator). `FUN_00417ab4` (follow SharedData link to the voltage source) is stubbed →
  TrackSeekVoltage / ReadyToDischarge / ctor seekVoltage-scaling (×source->ratedVoltage) and energyCoefficient
  derivation need the real Generator link. `FUN_004ad7d4` (HeatableSubsystem online?) stubbed to 1 and the
  self-heat dump (`heatAccumulator += heatPortion`) needs to feed the inherited HeatableSubsystem load owned
  by the heat family. EMITTER.TCP confirms intended coupling (Condenser/Generator/PowerBar feed the Emitter).
- **hud**: `DrawWeaponPip` AddElement into the cockpit HUD manager is stubbed in mechweap.cpp (gated on
  pipSegment != -1) — wire to the HUD module's AddElement (FUN_0049b6d8).

### Stubs remaining (engine-internal stand-ins, local to emitter.cpp; bind at link)
- FUN_004ad7d4, FUN_0049fb54, FUN_004b0bd0 (PoweredSubsystem step), FUN_004b0d50 (dt scale),
  FUN_004ac9c8, FUN_00417ab4, FUN_00421070, ResolveSource, VoltageCurve, CopyColor — local stand-ins.
- Firing-physics tuning constants `_DAT_004bafbc` (kDamageScale=1.0f) and `_DAT_004bb3b8` (folded into
  VoltageCurve()→1.0f) are double-precision operands the optimised image left non-finite in the dump →
  left symbolic; a human should re-derive from the FPU stream for exact damage/recharge tuning.

---

## Agent 6/7 — damage / messaging (mechdmg, dmgtable, messmgr)

All three modules were already substantially reconstructed (prior pass); this pass DEEPENED the
damage math against the binary oracle + the WinTesla engine DAMAGE.cpp/.h and re-verified each
compiles clean single-file via `compile1.cmd`. **mechdmg.cpp / dmgtable.cpp / messmgr.cpp → 0 errors.**

### Damage model reconstructed (armor -> structure -> crit)
- **Base armour model confirmed & documented** (`DamageZone::TakeDamage` @0041e4e0, oracle part_002.c;
  identical to the WinTesla engine `MUNGA/DAMAGE.cpp` body we link against). There is **no separate
  armour-then-structure pool**: a single `damageLevel` [0,1] accumulates
  `damageLevel += damage.damageAmount * damageScale[damage.damageType]`, is clamped to [0,1], sets the
  DamageLevelChanged flag (|=4), and at `>= 1.0` marks the zone destroyed (BurningState, DestroyedGraphicState,
  flag |=8). Documented verbatim in `Mech__DamageZone::TakeDamage`.
- **Key correctness fix in the ctor:** the 5 scalars at words 0x51..0x55 were mislabelled "per-facing
  armour". The oracle base TakeDamage indexes them `this[0x51 + damage.damageType]`, so they are
  `damageScale[Damage::DamageTypeCount==5]` indexed by damage TYPE
  (Collision/Ballistic/Explosive/Laser/Energy), NOT by facing. Relabelled the field, loop var
  (`facing`->`type`, bound `< Damage::DamageTypeCount`) and comments. Normalisation math unchanged
  (1/(scale*count); leg zones ×0.5) — verified against oracle FUN_0049ce50.
- **Leg-failure threshold fix:** the non-standing / still-grounded branch of `Mech__DamageZone::TakeDamage`
  compares structure against `_DAT_0049c9a0 == 0.5` (partial leg-failure graphic: right->level 4,
  left->level 3), not `StructureMax (1.0)`. Was using 1.0; now uses new `LegHalfStructure = 0.5f`.
  The standing/walking branch correctly keeps 1.0 -> level 9 (fall). Verified vs oracle FUN_0049c690.
- **Critical-hit roll verified** (`CriticalHit` @0049ccc4): half the damage amount (×0.5, clamped to 1.0)
  flows through the normal `TakeDamage`, then a single uniform draw walks the cumulative `criticalWeight`
  list (`roll <= cum/criticalWeightSum`) to pick one MechCriticalSubsystem, applying `ApplyDamage` and
  accumulating `damagePercentageUsed` (capped at `damagePercentage`). Reconstruction matches oracle
  field offsets (+0x10 pct, +0x14 pctUsed, +0x18 weight) exactly.
- **DMGTABLE roll logic verified** (dmgtable.cpp): three-level resolver
  DamageLookupTable(layers/penetration depth) -> PieSlice(angular sector, optionally torso-relative) ->
  DamageZonePercentTable(weighted zone list summing to 1.0). `SelectZone()` = single uniform draw against
  ascending cumulative %, returns first zone whose cumulative exceeds the draw. Constants confirmed
  (1.0 sum target, 2*PI wrap, 1e-4 sort epsilon). No change needed.

### Message dispatch (SubsystemMessageManager) verified
- `AddDamageMessage` (@0049b6d8) re-verified against oracle: first-of-frame wins for entityHit (+0xE4),
  impactPoint (+0xEC, gated on AlmostEqual-to-origin), damageZoneIndex (+0xE8); each message also queues a
  0x14-byte DamageInformation Plug (damageType=msg+0x2C, subsystemID=msg+0x5C) into the damageInformation
  chain keyed by damage amount (msg+0x30). Field offsets match exactly.
- `ConsolidateAndSendDamage` (Performance @0049b784): walks queued damage, resolves each damaged subsystem
  from the owner roster, queues a per-zone weapon-explosion ResourceID (dedup via chain Find), then flushes
  via `SendQueuedExplosions` (staggered 0.1s/explosion) and clears the common record. Logic intact.

### CROSS-FAMILY NEEDS
- **renderer (btl4vid/L4D3D — NOT edited):** `messmgr::SubmitExplosion` is stubbed. Original built an
  explosion render command (ClassID 0x5C sub-type 3, FUN_004336f0) and submitted it to the global IG
  graphics pipe (`theGraphicsPipe->Submit`, FUN_0041acbc). WinTesla replaced the IG pipe with L4D3D and
  the submission entry point is not in these headers — wire to the L4D3D explosion/effect submit at
  integration, using commonDamageInformation.impactPoint + rendererCompensateTime.
- **subsystem base (subsystm.hpp — NOT edited):** `messmgr::ResolveExplosionID` should read the
  per-subsystem explosion id off the engine `Subsystem` (subsystem+0x3E4, `Subsystem::GetExplosionID()`).
  The WinTesla Subsystem doesn't expose it yet; currently returns the manager's own terrainHitExplosionID
  as a stand-in. Add the accessor to the base, then bind.
- **mech roster (mech.cpp / mech3.cpp — NOT edited):** ConsolidateAndSendDamage relies on
  `owner->GetSubsystem(id)` (mech+0x128 roster). Confirm the reconstructed Mech exposes that accessor with
  the same id->slot indexing the message manager assumes.
- **damage notify message (net/entity — NOT edited):** the consolidated TakeDamage/notify message build
  (ClassID 0x13, vtable @0050b984, target field +0x184) in ConsolidateAndSendDamage is left as a recovered
  note — the message ctor (FUN_00419e18) and target wiring are net/renderer-side and absent from headers.

### Random / stubs remaining
- **`RandomUnit()` (mechrecon.hpp) returns 0** — the unit-random ([0,1)) used by the CriticalHit weighted
  roll, DamageZonePercentTable::SelectZone, LODDamageRouter hysteresis and DamageLookupTable degenerate-angle
  fallback. With it pinned at 0 every weighted roll selects the FIRST entry and LOD always re-uses the same
  child. **Must be backed by the real engine RNG (FUN_00408050) before damage distribution is correct.**
  Flagged here as the single highest-impact bring-up item for this family.
- mechdmg local stand-ins (TheTime/TicksPerSecond clock, SegTable/SegmentIterator segment-tree walk,
  SubProxy2 subsystem facets, NoteX2/RFileX2 offline notation readers) and the dmgtable ReconTable/
  ReconTableIter/notation proxies are behaviour-neutral compile shims — bind to the real engine
  clock / EntitySegment tree / Subsystem / NotationFile + TableOf at integration.
- `LODReuseHysteresis = 0.82f` (_DAT_0049c514) is a TODO: the exact reuse-probability operand wasn't
  cleanly recoverable from the pseudo-C; behaves as a high "stay on the same spot" bias. Re-derive from the
  FPU constant stream for exact LOD damage clustering.

---

## COMBAT WAVE — agent 1/7 (heat/power)  [heat.cpp/.hpp, powersub.cpp/.hpp, gnrator.cpp/.hpp]

Status: all three files compile clean (compile1.cmd → 0 `error C`). The per-frame
TICK is wired for every master subsystem in this family (SetPerformance installed in
ctor; engine `Simulation::PerformAndWatch`→`Perform`→`(this->*activePerformance)` persists
it, no auto-reset — verified against RP MUNGA/SIMULATE.HPP:117-182).

### Per-class per-frame behavior + SetPerformance wiring
- **HeatSink** — `HeatSinkSimulation` (@004ad924): heatEnergy += pendingHeat; currentTemp =
  heatEnergy/thermalMass; UpdateHeatLoad (radiatedHeat = currentTemp*coolant, scaled+clamped+
  15-sample filtered); ConductHeat→ComputeHeatFlow (conductive exchange w/ linked sink via
  expf decay) + BalanceCoolant; UpdateCoolant (draw=master.heatEnergy*heatLoad, top-up via
  DrawCoolant, draw state machine); degradation/failure alarm. WIRED: ctor installs
  `SetPerformance(&HeatSink::HeatSinkSimulation)` for master segments (flags 0x100, copy-bits 0).
  Faithful to FUN_004ad924/7f0/8ac/9ec/da94/dbf8 in heat_cluster.c.
- **PoweredSubsystem** — `PoweredSubsystemSimulation` (@004b0bd0): runs HeatSink sim, resolves
  voltage bus from powering Generator, advances electrical state machine
  (Starting/NoVoltage/Shorted/GeneratorOff/Ready) off generator state + startTimer, AutoConnect
  scan of GeneratorClassID segments. WIRED: ctor installs it for masters. Voltage state per frame
  is live.
- **Generator** — `GeneratorSimulation` (@004b1f7c): spin-up (startTimer→startTime), short
  recovery (shortTimer→shortRecoveryTime), idle/recovered transitions, outputVoltage =
  (1 - sourceLevel)*ratedVoltage, percentVoltageAvailable clamped [0,1]. WIRED: ctor installs it
  for masters. ALSO folded in the one recovered method the powersub cluster omitted:
  `Generator::ResetToInitialState()` (verbatim from GNRATOR.TCP — chains
  HeatableSubsystem::ResetToInitialState, outputVoltage=0), declared in powersub.hpp, defined in
  powersub.cpp.
- **Myomers / PowerWatcher** (in powersub) — already wired (`MyomersSimulation`,
  `PowerWatcher::Simulation`) in their ctors; left as-is.
- **HeatableSubsystem** (base) — owns the damageable-subsystem virtual surface; base
  edits kept additive (Generator::ResetToInitialState chains it). No regressions to derived families.
- **gnrator.cpp/.hpp** — alias TUs (Generator lives in powersub); the recovered method they
  documented is now folded into powersub. Left as alias-only, no code emitted.

### Constants RECOVERED from the oracle (section_dump.txt raw bytes; corrected placeholders)
- `_DAT_004ad870` HeatLoadScale: **0.002f** (was 1.0f placeholder) — 80-bit extended
  `3b df 4f 8d 97 6e 12 83 f6 3f` = 1.023992 × 2^-9. Real: normalises radiatedHeat (~300) into
  the [0,1] heatLoad band; the 1.0f placeholder would have pinned heatLoad at the 1.0 clamp.
- `_DAT_004ad87c`=0.0f, `_DAT_004ad880`=1.0f, `_DAT_004ada90`=1.0f — confirmed correct.
- `_DAT_004adbf4` HeatEqualizeEpsilon & `_DAT_004adcfc` CoolantDrawEpsilon: **1.0e-4f**
  (0x38d1b717) — was 0.0005f JM_CLOSE_ENOUGH placeholder. Now exact.
- Power constants verified already-correct from bytes: VoltageEpsilon 1.0e-4f (@4b0bcc),
  RatedVoltageRef 1.0f (@4b1d10), DegradedDriveScale 0.5f (@4b1d14), MinOutputVoltage 0.0f
  (@4b2158), MaxOutputVoltage 1.0f (@4b2154/4b2258).

### CROSS-FAMILY NEEDS
- `BT_GetMessageManager(Mech*)`, `BT_IsBusLive(Mech*)`, `BT_ClearMyomers(Mech*)` (declared in
  powersub.hpp, definitions belong in the mech family) — used by PoweredSubsystem/Generator/Myomers
  message handlers. Mech family must provide these (owner+0x190 message manager, +0x274 bus-live
  flag, +0x374 myomer back-ptr).
- `Mech::GetSegment(int)` / `EntitySegment` segment roster — relied on for voltage/heat-sink linkage
  resolution and the AutoConnect generator scan. Owned by mech family.

### Remaining stubs / not deepened (out of my 3 DEEPEN targets)
- **Condenser** (RefrigerationSimulation @4ae4d8) — body lives in heatfamily_reslice.cpp (not my
  file). Condenser currently inherits HeatSink ctor → ticks via HeatSinkSimulation (live, not
  DoNothingOnce), but does NOT install RefrigerationSimulation. Deferred to whoever owns
  heatfamily_reslice.cpp; flagged so refrigeration output isn't yet per-frame.
- PowerWatcher MinVoltageScale (`_DAT_004b1924`) left at 1.0f — appears to be a double in the dump
  and is non-load-bearing (PowerWatcher only delegates per frame); not re-derived.
- `MyomersSimulation` SourceLevel/voltage-curve details depend on cross-family Mech back-ptrs above.

---

## COMBAT WAVE — agent 5/7: movement subsystems (gyro / torso / myomers)

Goal: real per-frame behavior + `SetPerformance(&<Class>::<Class>Simulation)` so each subsystem
ticks through `Mech::PerformAndWatch → subsystem->PerformAndWatch → Simulation::PerformAndWatch →
activePerformance` (instead of the default `DoNothingOnce` that drops out after frame 1).

### ROOT-CAUSE FOUND (all three were silently NOT ticking as the master)
The binary registers the per-tick Performance in each ctor by storing the pointer-to-member into
`activePerformance` (`this[7..9]`) under the live-MASTER guard `(segFlags & 0xC)==0 && (segFlags &
0x100)`. Proven identical shape in all three ctors:
- Gyro  @004b3778: `this[7..9] = PTR_FUN_0050fe08` (GyroscopeSimulation), guard bit **0x100**.
- Torso @004b6b0c: master → `PTR_FUN_00510c10` (TorsoSimulation), else → `PTR_FUN_00510c1c`
  (TorsoCopySimulation); `this[0x93]`=isDamagedCopy.
- Myomers @004b8fec: `this[7..9] = PTR_LAB_00511620` (MyomersSimulation), guard bit **0x100**.
The earlier reconstructions (a) tested the wrong bit (`SegmentLiveFlag` 0x01 instead of
`MasterHeatSinkFlag` 0x100) AND (b) primed the local `segmentFlags` shim to 0 → guard always false.
Net effect before this pass: **Gyro never registered its sim; Torso registered the slaved COPY sim
(no command processing); Myomers mislabeled the store a "graphic-state hook" and omitted
registration entirely.** All three would have fallen back to DoNothingOnce.

### Gyroscope (gyro.cpp/.hpp) — balance / tip-over
- Behavior: per-frame `GyroscopeSimulation` verified faithful to @004b275c — PowerWatcher watch
  update, idle-sway ramp toward (impaired? percentageOnDestruction : percentageOnNormal)+swayBias at
  rotationPerSecond·dt with overshoot clamp + [min,max] noise band, then IntegrateEyeJoint
  (@004b2ec0) + IntegrateBody (@004b30ec) spring-dampers. (Sim integrates only; the binary does NOT
  write the joints in-sim — WriteEyeJoint/WriteMechJoint are driven from the render/animate pass.)
- SetPerformance wired: guard fixed to `MasterHeatSinkFlag` (0x100); `segmentFlags` primed to live-
  master so `GyroscopeSimulation` registers. Compile-clean (exit 0).

### Torso (torso.cpp/.hpp) — twist (yaw) + elevation (pitch) aim
- Behavior: `TorsoSimulation` verified faithful to @004b5cf0 — watch update; effective rates gated by
  power/heat (Degradation halves, Failure/not-Ready/HeatModelOff zero); button-accel ramp; per-axis
  command integration (rotate L/R, elevate U/D) clamped to software limits; center/recenter; velocity
  + settle/dirty-bit; statusFlags limit latches. `TorsoCopySimulation` (@004b65f8) retained for the
  copy path.
- SetPerformance wired: guard fixed to `MasterHeatSinkFlag` (0x100); `segmentFlags` primed to master
  so the **command-processing** TorsoSimulation registers (was registering TorsoCopySimulation).
  Compile-clean (exit 0).

### Myomers (myomers.cpp/.hpp, classID 0xBC6) — artificial-muscle drive/actuation
- Behavior: `MyomersSimulation` verified faithful to @004b8d18 — advanced-damage gate (FUN_004ad7d4),
  then `pendingHeat(@0x1C8) += ratio² · (1+damage) · [(1-accelEff)·|vy|·k·m·dt + (1-velEff)·(k·|v|²·½)
  + (1-accelEff)·|v|·|a|·k·dt]` (k=motionGain@0x20c, m=*mass@0x250). Drive helpers AvailableOutput/
  RegisterMaxOutput/GetSpeedReading/HasAdequateVoltage already faithful.
- SetPerformance wired: ADDED the missing registration in the ctor (added a local `segmentFlags`
  Word shim + `SegmentCopyMask`/`MasterHeatSinkFlag` enum to myomers.hpp), primed to live-master,
  guard `(flags&0xC)==0 && (flags&0x100)` per @004b8fec, → `SetPerformance(&Myomers::MyomersSimulation)`.
  Compile-clean (exit 0).

### CROSS-FAMILY NEEDS (movement subsystems)
- **Real segment flags** (`owner+0x28`, read by all three ctors): the live-master vs damaged-copy
  decision and thus which Performance is installed must come from the owning Mech segment, not the
  locally-primed `segmentFlags` shim. Mech family must set these on the subsystem/segment before
  construction (master = 0x100 set, copy-mask 0xC clear). Until then all three are primed to the
  master value so the master sims tick.
- Gyro skeleton-joint I/O: `eyeJointNode`/`mechJointNode` resolution + the node get/set-transform API
  (FUN_0041cfa0/0041d020/0041d0a8/0041d11c) and `Mech::ResolveJoint(name)` are stubbed (NodeType/
  NodeScalar/SetNode*). WriteEyeJoint/WriteMechJoint integrate values are inert until the
  Skeleton/JointedMover node API is reachable from the subsystem.
- Torso: `Mech::ResolveJoint`, skeleton-node scalar writer (`PushTwist`), Simulation dirty/replicate
  bit (`SetMovedFlag`), and PowerWatcher base virtuals (`WatcherResetToInitialState`/
  `WatcherHandleDeathMessage`/`WatcherUpdateWatch`, FUN_004b1804/179c/181c) are stubbed — owned by
  Mech / Simulation / PowerWatcher families.
- Myomers: owner-Mech accessors (base/top speed @0x34C/0x7A0, velocity/drive vectors @0x1C4/0x82C,
  motionGain @0x20C, mass @0x250, advanced-damage gate FUN_004ad7d4), JointedMover roster
  Attach/Detach/Release (mover vtable +0x38/+0x3C/+0x44, fed `&speedEffect`@0x31C), and this segment's
  DamageZone structureLevel @0x158 are all backed by neutral local shims. The drive/heat formulas are
  intact but read placeholder zeros until the Mech/JointedMover/DamageZone accessors land.

### Stubs / not deepened
- Gyro `UpdateAnimationNoise` (@004b357c) procedural-noise generator: structure recovered, node
  injection bodies left as branch stubs (best-effort; not on the per-frame tick path).
- Gyro `WriteEyeJoint`/`WriteMechJoint` quantise-write logic faithful but inert pending the
  skeleton-node API (above).
- Myomers `ToggleSeekVoltage` (@004b8a48) command handler: not in the captured shards (untagged gap);
  cycles currentSeekVoltageIndex within [min,max] — left as a documented stub.

---

## COMBAT WAVE — agent 3/7: projectile / missile weapons

Edited only the 7 assigned module pairs. All 7 compile clean (`compile1.cmd`,
EXIT=0). The per-frame TICK is now wired end-to-end for the launcher and the
flight entity.

### Per class

- **ProjectileWeapon** (`projweap.cpp/.hpp`) — behavior DEEPENED + tick wiring
  FIXED.
  - **Bug fix (matters for the live tick):** the ctor's Performance-install gate
    read `subsystem_resource->subsystemFlags`; the oracle (FUN_004bc3fc @8375)
    reads the **owner's** flags `*(param_2+0x28)` = `owner->simulationFlags`
    (`&0xC==0 && &0x100`) — the *same* authoritative-mech gate the working AmmoBin
    uses. Corrected so launchers actually arm their Performance on the bring-up
    mech instead of dropping out as `DoNothingOnce`.
  - `ProjectileWeaponSimulation` (was an empty stub; body genuinely
    unrecovered @004bbd04) reconstructed from the recovered helpers
    (DrawFiringCharge @004bbc78, UpdateEject @004bbb50, CheckForJam @004bbfcc,
    ComputeTimeOfFlight @004bc06c) + the RP analog `RivetGun::RivetGunSimulation`
    (WEAPSYS.cpp): recharge recoil, advance eject, edge-trigger via
    `CheckFireEdge()`, a Jammed/NoAmmo/ready state machine, jam roll, then
    `FireWeapon()` through the vtable.
  - `FireWeapon` (slot 18, stub @004bc104) reconstructed: `ConsumeRound()` (→
    AmmoBin::FeedAmmo @004bd4f4), start recoil cooldown, `GetMuzzlePoint` +
    `Projectile::New`. New shared helpers `ConsumeRound()` / `ReadyToFire()`.
  - `SetPerformance(&ProjectileWeapon::ProjectileWeaponSimulation)` — wired (ctor).

- **MissileLauncher** (`mislanch.cpp/.hpp`) — `FireWeapon` (override @004bcc60)
  reconstructed: `ConsumeRound()`, recoil cooldown, then spawn `missileCount`
  guided `Missile::New` entities per salvo (damage already pre-split per-missile
  in the ctor). Ticks via the inherited `ProjectileWeaponSimulation`; its vtable
  `FireWeapon` override is dispatched from there.

- **Missile** (`missile.cpp/.hpp`) — flight-entity tick wiring ADDED.
  - **`SetPerformance(&Missile::MoveAndCollide)` installed in the ctor** (was
    MISSING — the Projectile base ctor only installed the unguided base pass, so
    a spawned missile would not have homed). This is the "flight entity
    simulates" wiring.
  - `MoveAndCollide` now explicitly drives its hosted subsystems each frame
    (`seeker->FindTarget(dt)`, `thruster->MissileThrusterSimulation(dt)`) — the
    behavior the shipped binary folds inline — before the steering/integrate/
    collide pass.

- **Seeker** (`seeker.cpp/.hpp`) — `LeadTarget`/`FindTarget` homing already
  reconstructed; now actually RUN each frame from `Missile::MoveAndCollide`.
  Faithful to the binary, the Seeker installs **no** custom Performance (its
  vtable is all engine slots; its work is folded into the host missile), so it
  is driven by the missile rather than a standalone `SetPerformance`. No change
  needed.

- **Projectile** (`projtile.cpp/.hpp`) — base integrate/collide pass already
  present; `SetPerformance(&Projectile::MoveAndCollide)` already installed by the
  ctor. No change.

- **MissileThruster** (`misthrst.cpp/.hpp`) — burn/steer sim already present;
  `SetPerformance(&MissileThruster::MissileThrusterSimulation)` already installed
  by the ctor, and now also invoked per frame by the host missile. No change.

- **AmmoBin** (`ammobin.cpp/.hpp`) — feed (FeedAmmo @004bd4f4), DumpAmmo
  @004bd588 and CookOff @004bd300 already reconstructed; `AmmoBinSimulation`
  Performance already installed by the ctor under the correct
  `owner->simulationFlags` gate. Verified the feed/dump identities against the
  oracle (FeedAmmo dispenses one round Loaded→Feeding; DumpAmmo empties the bin).
  No change.

### CROSS-FAMILY NEEDS
- **MechWeapon base (agent 2):** the fire/sim path relies on `recoil`,
  `rechargeRate`, `weaponAlarm` (`SetLevel`/`GetState`), `CheckFireEdge()`,
  `UpdateTargeting()`, `GetMuzzlePoint()`, `GetTargetPosition()`, `damageData`,
  `effectiveRange`, `rangeToTarget`. All present in `mechweap.hpp` today; if any
  are renamed/retyped, my two FireWeapon paths + `ProjectileWeaponSimulation`
  need a matching touch-up.
- **Mech (mech family):** the AmmoBin roster lookup (`OwnerSubsystemCount`/
  `OwnerSubsystem`) and the cockpit "live-fire" flag (`LiveFireEnabled`) are still
  isolated stubs in `projweap.cpp` — the real Mech subsystem-roster + controls
  query must wire them so the launcher resolves its bin and the jam roll honors
  the live-fire control.
- **Entity / world (engine):** `Projectile`/`Missile` world-segment registration,
  motion integration (`IntegrateMotion`/`AdvanceModel`), `CollisionQuery`
  (FUN_0042291c) and detonation spawn (FUN_004be078, ClassID 0x5C) remain
  structural stubs in `projtile.cpp`/`missile.cpp` — engine-side, not weapon
  logic. Spawned entities also need the entity-manager registration that ticks
  their installed Performance (engine-side).

### Stubs still standing (flagged, not blocking the tick)
- `projweap.cpp`: `GetStatusFlags` (slot 12 @004bbf88) and `UpdateWeaponState`
  (slot 16 @004bbc20) — bodies genuinely unrecovered; left deferring to base /
  benign. `OwnerSubsystem*` / `LiveFireEnabled` cross-family stubs (above).
- `missile.cpp`: `GetForward`, `ResolveTargetConnection`, `LaunchAimOffset`,
  `ResolveModel`, `SpawnDetonation` — engine/model plumbing stubs.
- `projtile.cpp`: `InitSegmentLink`/`ResolveWorld`/`IntegrateMotion`/
  `CollisionQuery`/`Retire` etc. — Entity-engine stubs.

---

## WAVE agent 7/7 — HUD / 2D cockpit layer (dpl2d_ over D3D9 + heat gauge feed)

### What was done
1. **dpl2d_ 2D vector display-list layer reimplemented over Direct3D 9.**
   Moved the 9 inert `dpl2d_*` stubs OUT of `btstubs.cpp` into a NEW file
   `decomp/reconstructed/dpl2d.cpp` (+ `dpl2d.hpp`), added to the `bt410_l4`
   CMake source list. The recorder calls (`dpl2d_NewDisplayList/Begin/SetColor/
   Circle/PushMatrix/PopMatrix/MoveTo/End/Compile` — prototypes in btl4vid.hpp)
   now build a real in-memory command list (colour, filled disc, outline ring,
   translation-matrix stack + pen). A real **`dpl2d_ExecuteList(list, device)`**
   executor rasterises a compiled list as pre-transformed 2D primitives
   (`D3DFVF_XYZRHW|D3DFVF_DIFFUSE`, mirroring engine `L4VERTEX_2D`/`_2D_FVF`):
   filled circle = `D3DPT_TRIANGLEFAN`, outline = `D3DPT_LINESTRIP`, 32-seg
   tessellation, alpha-blend on, z/lighting/fog off, full render-state
   save/restore, normalised-[0,1]→viewport-pixel mapping. This matches exactly
   what the reconstructed reticle/PIP builder in `btl4vid.cpp` (lines ~563-616)
   issues (`dpl2d_Circle(list,x,y,0.012f,1)` filled blip + `0.014f,0` dark ring).

2. **Heat gauge wired to real subsystem state.**
   Implemented `HeatConnection::Update()` (the per-frame data feed, orig
   "Transfer" @004c3720) in `btl4gaug.cpp`. It reads the live
   `HeatableSubsystem::currentTemperature` (@0x114) of the gauge's bound heat
   subsystem and writes the colour index that `ColorMapper::Execute` pushes into
   the hardware palette slot (no subsystem / destroyed → 100/full tint, else
   `Round(currentTemperature)`). `Update()` is the real base virtual
   (`GaugeConnection::Update`, gauge.h) the gauge framework calls each frame —
   so the cockpit heat tint art is now driven by actual heat state.

### 2D primitives implemented
Coloured filled circle, coloured outline circle, translation matrix stack
(Push/Pop), pen move — over D3D9 via `DrawPrimitiveUP` with pre-transformed
verts. (The port's dpl2d_ API surface is the small reticle/PIP subset; the full
libDPL board API — polylines/polygons/clip regions/AddSetMatrix etc. — is NOT
used by the reconstructed code and was not reimplemented.)

### Gauges wired to real state
- **ColorMapperHeat** ← `HeatableSubsystem::currentTemperature` (DONE, live).
  The ColorMapper draw path itself uses the engine's real L4 gauge raster layer
  (`Video16BitBuffered`/`SVGA16`/`L4GraphicsPort` in MUNGA_L4/L4VB16.cpp), which
  is **already fully implemented over D3D9** in WinTesla (rasters to a PixelMap16
  then uploads changed lines to a D3D texture) — so this path genuinely draws.

### Compile-clean status
All 7 owned files compile clean (exit 0) via `compile1.cmd`:
`hud.cpp btl4gaug.cpp btl4gau2.cpp btl4gau3.cpp btl4galm.cpp btstubs.cpp dpl2d.cpp`.

### Honest "draws vs compiles" assessment
- **Gauge raster path: REAL** (engine L4VB16 D3D path is implemented). The heat
  gauge's data feed is now live and correct.
- **dpl2d_ reticle: records + has a real D3D9 executor, but NOT yet on-screen.**
  No caller invokes `dpl2d_ExecuteList` yet — `BTReticleRenderable::Execute()`
  (btstubs.cpp) is still empty and `btl4vid.cpp` builds the PIP lists but never
  executes them. Hooking execution into the per-frame world render is the last
  mile and lives in btl4vid.cpp / the reticle renderable (NOT my files).
- **ColorMapperHeat::Make() uses placeholder .data resource constants** (empty
  palette names, port 0, colour slot) — the gauge-config resource pool
  (`l4gauge.cfg` / DAT_005150xx) was not recovered from the optimised image, so
  the heat gauge constructs degenerately at runtime until those constants are
  supplied. Data FEED is correct; the gauge's art binding is the gap.
- **Other gauge widgets** in btl4gaug/gau2/gau3 (bars, OneOfSeveral,
  HeadingPointer, arcs) remain comment-summaries (no code bodies); they only
  fail at link if the config references them (currently not constructed).
- **btl4galm.cpp** (alarm/lamp stream virtuals) is serialization glue — no live
  gauge to wire; left as the existing best-effort reconstruction.
- **hud.cpp** is the HUD *subsystem* (torso-horizon gimbal logic), not a 2D
  drawing surface — left as-is (already reconstructed).

### CROSS-FAMILY NEEDS
1. **Reticle execution hookup (btl4vid.cpp / BTReticleRenderable — NOT my files):**
   wire `dpl2d_ExecuteList(pipDisplayListA[i]/B[i], renderer->GetDevice())` into
   the world-view per-frame render (after the 3D scene) so the recorded reticle/
   PIP display lists actually draw. `DPLRenderer::GetDevice()` (L4VIDEO.h) returns
   the main-view device; `dpl2d_ExecuteList` is declared in `decomp/reconstructed/
   dpl2d.hpp`.
2. **Gauge-config resource pool** (`l4gauge.cfg` / the DAT_005150xx constants for
   ColorMapperHeat::Make): needed so the heat gauge binds real palette names /
   port / colour slot. Likely recoverable from the pod content tree or a deeper
   .data slice (binary oracle). Owner: whoever owns gauge-config / content.
3. **Heat temperature→percent scaling** (flagged in btl4gaug.cpp): the recovered
   feed rounds `currentTemperature` (seeded 300.0) straight into a 0..255 index;
   the exact ramp scaling should be reconciled against the original palette ramp.
   Touches heat subsystem semantics (heat.cpp owned by another agent) — read-only
   here; no edit made to heat.* .

---

## INTEGRATION PASS (post-7-agent wave) — subsystem tick reconcile

### TL;DR
- Tasks 1/2/3 landed; build GREEN, stable (3+ clean runs), driving intact.
- Tick count stayed 1 -> 1. Root cause is NOT the gate-source variance the brief
  described. The player mech's subsystem roster is built from local RECON_SUBSYS
  stub classes (mech.cpp:145-181), not the reconstructed real classes. The real
  classes (heat.cpp::HeatSink, gyro.cpp::Gyroscope, powersub.cpp::Generator/
  PoweredSubsystem, sensor.cpp::Sensor, ...) are compiled but never instantiated,
  so their (now-reconciled) gates never run.

### What actually gates the tick (empirically verified, not theory)
The base Simulation ctor installs activePerformance = &DoNothingOnce
(MUNGA/SIMULATE.cpp:352). DoNothingOnce runs once then calls NeverExecute() (sets
DontExecuteFlag 0x2), so a subsystem that never SetPerformance-s a real sim drops
out after frame 1. Frame-1 log = 30 executable, steady-state = 1: i.e. 29
subsystems entered with DoNothingOnce and self-disabled.

A one-time per-slot roster dump (temp diag, since removed) showed the lone
survivor is slot 18 'HUD' = the real MechTech (mech.cpp:643), whose gate
(entity->simulationFlags and 0xC)==0 reads the OWNER's flags and passes. Every
other slot (HeatSink, Reservoir, Condenser1-6, GeneratorA-D, Avionics, Myomers,
Gyroscope, Torso, Searchlight, ThermalSight, PPC_1/2, ERMLaser_1-3, AmmoBinSRM6,
SRM6, MessageManager) is a RECON_SUBSYS/local-struct stub -> DoNothingOnce ->
exec=0. (The brief's claim that AmmoBin is the survivor is incorrect; AmmoBin
isn't instantiated as the real class -- the 'AmmoBinSRM6_*' slots are stubs.)

### Binary-oracle finding on the gate (Task 1, done correctly)
decomp/recovered/all/part_*.c shows the canonical subsystem master-gate ~17x:
(*(uint*)(param_2+0x28) and 0xc)==0 && (*(uint*)(param_2+0x28) and 0x100)!=0
where param_2 is the owner (Mech*), so owner->simulationFlags (owner+0x28) is the
authoritative source -- matching the working AmmoBin/projweap path. The
reconstruction had drifted to per-file sources (subsystem_resource->subsystemFlags
[streams 0], GetSegmentFlags() shim, primed-local segmentFlags,
entity->simulationFlags without 0x100). Aligned all real-class SetPerformance
master gates to owner->simulationFlags: heat.cpp (HeatSink), powersub.cpp
(PoweredSubsystem, Generator, PowerWatcher), gyro.cpp, torso.cpp, myomers.cpp,
sensor.cpp. (mechtech.cpp already reads entity->simulationFlags = owner -> left
as-is; it's the one that works.) Heat/power linked-sink/voltage-source logic left
on per-segment flags (that linkage is genuinely per-segment, and leaving it keeps
the master-missing Verify() paths dormant). These edits are correct and
oracle-matched but LATENT -- they only take effect once the real classes are
instantiated (see blocker below).

### Task 2 -- mech-core accessors (btstubs.cpp)
The reconstructed Mech is NOT byte-exact (named members + a Wword scratch bank),
so the shipped raw offsets (+0x190 msg-mgr, *(+0x190)+0x274 bus, +0x374 myomers)
do NOT address the right members; a raw read would deref garbage. Done against
intent, deref-safe:
- BT_IsBusLive -> True (running player mech is a powered master; un-gates the
  power-dependent paths in powersub when wired). REAL change (was False).
- BT_GetSegmentFlags(Mech*) -> defined = owner->simulationFlags. This symbol was
  declared in hud.cpp but had NO definition -- it only linked via /FORCE (undefined
  return if ever called). Now resolves the dangling extern and feeds the HUD/
  segment gate the same authoritative source. REAL fix.
- BT_GetMessageManager -> still 0 (the real MessageManager is a roster slot but
  can't be located without the byte-exact layout; a bogus non-null would be worse
  -- callers deref). BT_ClearMyomers -> no-op (no known-offset member). Documented.
- Mech::GetSegmentFlags() / EntitySegment roster (owner+0x28) / GetExplosionID
  (+0x3E4): NOT implemented -- no safe byte-exact source in the reconstructed Mech;
  latent like the rest. Flagged.

### Task 3 -- RandomUnit backed by real RNG (DONE, verified)
mechrecon.hpp: RandomUnit() was return 0 (pinned every damage/crit/zone roll to
entry 0). Now #include <RANDOM.hpp> (fwd -> engine RANDOM.h) and returns
(Scalar)Random -- RandomGenerator::operator Scalar() in [0,1), matching
FUN_00408050. Variadic tail + Scalar return keep dmgtable call sites unchanged.
Verified with a temp 1 Hz log (since removed): printed varying triples e.g.
0.00662 0.1477 0.2346 / 0.2919 0.1782 0.3686 / 0.0590 0.0847 0.4086 across runs.
This genuinely de-pins damage/crit/zone selection -- but its consumers (dmgtable
via weapon impacts) are exercised only when the stub weapons fire, so the combat
effect is latent until the weapon roster is real.

### THE REAL BLOCKER to N->~30 (honest)
Replacing the RECON_SUBSYS stubs (mech.cpp:145-181 + the switch @550-672) with the
real reconstructed classes is the genuine remaining work. It was NOT done in this
pass because it cannot be landed stably piecemeal:
1. Two parallel ClassID schemes. The streamed segments use the switch's 0xBBD-0xBDE
   IDs; the real classes stamp a different family (heat.cpp HeatSinkClassID,
   heatfamily Condenser/Reservoir/HeatWatcherClassID, powersub, ...). The class<->
   resource mapping must be reconciled first or a class gets constructed over a
   resource blob meant for another (garbage fields).
2. Unverified per-class alloc sizes. The switch hand-codes Memory::Allocate sizes
   per class; the real objects are larger (e.g. HeatSink/AmmoBin reach >=0x224).
   Under-allocation -> heap corruption (this family already caused the
   "~1-in-6 startup crash", mechsub.cpp:165 note).
3. Real ctors Verify()-assert on segment links. HeatSink @004adda0 asserts
   "Bad subsystem resource ->heatSink" if owner->GetSegment(heatSinkIndex) is null;
   PoweredSubsystem @004b0f74 asserts on GetSegment(voltageSourceIndex). These
   depend on the streamed indices landing at the right resource offsets in our
   (approximate, +0x100-padded) stream.
4. Interdependence. Even a single real class wired alone won't show useful
   computation: HeatSink's HeatSinkSimulation does
   currentTemperature = heatEnergy/thermalMass but pendingHeat stays 0 unless the
   heat sources (Generator/weapons -- all stubs) feed it. The roster must be made
   real together to compute real combat state.

Ordered safe path (next pass): (a) reconcile the streamed ClassID -> real-class
table; (b) recover each real class's exact object size from the binary and size the
allocations; (c) confirm owner->GetSegment(index) returns valid skeleton segments
for the streamed indices (it's the real engine JointedMover::GetSegment(int), so
likely yes) and that resource fields sit at the expected offsets; (d) wire ONE
family at a time (heat first -- it's the pilot), build+run, watch for the asserts,
keep only if green+stable; (e) repeat. The gate alignment (Task 1) and accessors
(Task 2) above are the prerequisites already in place, so each newly-real class
will tick the moment it's instantiated.

### What genuinely runs today (no overclaim)
- Driving: real ([drive] pos advances every second; stable).
- 1 real subsystem ticks: MechTech::TechnicalAssistance every frame (the
  [tick] ... 1 (executable) of 30). The other 29 are stubs decaying to
  DoNothingOnce -- they tick frame 1 only, then opt out (by design of the stub).
- RNG: real and verified (Task 3). Bus-live / segment-flags accessors: real values
  now, but their consumers are stubs -> latent.
- Stability: 3+ headless runs to timeout, no asserts, no faults, gflags PageHeap OFF.
- Build: GREEN (bt410_l4.lib + btl4.exe), links under the pre-existing /FORCE (now
  with one fewer unresolved extern -- BT_GetSegmentFlags resolved).

## ============ HEAT-FAMILY PILOT (instantiate real heat classes) — 2026-06-30 ============
GOAL: make the mech construct the REAL heat-family subsystem classes (heat.cpp/heat.hpp/
heatfamily_reslice: HeatSink/HeatableSubsystem/Condenser/Reservoir/HeatWatcher) instead of the
inert RECON_SUBSYS stubs, proving the instantiation+tick pattern for the other families.
RESULT: **REVERTED to known-good (all stubs).** A real Condenser DOES instantiate and its
per-frame Performance DOES tick (the gate/mechanism works) — but it then crashes in the heat
SIMULATION on a missing inter-sink linkage that cannot be fixed from the allowed files. Build is
back GREEN, 3/3 runs stable, tick back to 1/30, driving intact. This is the conservative outcome
the brief sanctions ("if a class can't be made stable, keep the stub, document, report").

### #1 finding — the factory ClassID enum NAMES (mech.hpp:253-273) are MISLABELED.
The streamed ClassID VALUES are right, but the human-readable enum names + the class each switch
case constructs are guesses that DISAGREE with the authoritative CLASSMAP.md. Cross-referencing the
ctor address each case cites against CLASSMAP gives the TRUE class. Authoritative map (streamed ID
-> ctor -> REAL class // current switch label):
  0xBBD @4ae568 -> Condenser            // labelled CockpitClassID  (builds stub Cockpit)
  0xBBE @4ae8d0 -> HeatSink bank (agg)  // labelled SensorClassID   (builds stub Sensor; ALSO
                                        //   wrongly sets sensorSubsystem — pre-existing mislabel)
  0xBC0 @4af408 -> Reservoir            // labelled CondenserClassID (builds stub Condenser)
  0xBC1 @4b225c -> Generator            // GeneratorClassID  (correct)
  0xBC2 @4b0f74 -> PoweredSubsystem     // correct
  0xBC3 @4b1d18 -> Sensor               // labelled MyomersClassID
  0xBC4 @4b3778 -> Gyroscope            // correct
  0xBC5 @4b6b0c -> Torso                // labelled SinkSourceClassID
  0xBC6 @4b8fec -> Myomers              // labelled ActuatorClassID
  0xBC8 @4bb120 -> Emitter              // WeaponEmitterClassID (correct)
  0xBCB @4bd5c4 -> AmmoBin              // labelled JumpJetClassID
  0xBCD @4bc3fc -> ProjectileWeapon     // MechWeaponClassID (correct family)
  0xBD0 @4bcff0 -> MissileLauncher      // labelled BallisticWeaponClassID
  0xBD3 @49bca4 -> SubsystemMessageManager // labelled MechControlsMapperID
  0xBD4 @4bb888 -> PPC                  // labelled GaussWeaponClassID
  0xBD6 @4b7f94 -> HUD                  // labelled MechTechClassID — and the case builds the REAL
                                        //   MechTech class over it (size 0x2a4 == HUD size, so safe);
                                        //   THIS is the lone steady-state tick survivor.
  0xBD8 @4b84dc -> Searchlight          // labelled LegSubsystemClassID
  0xBDC @4ad228 -> MechTech             // labelled HeatableClassID (builds stub HeatableSubsystem,
                                        //   and that case does NOT even assign subsystemArray[id])
  0xBDE @4b8718 -> ThermalSight         // labelled DisplayClassID
ACTION for the next pass: re-label this enum + re-target every switch case to the CLASSMAP class
BEFORE wiring any real class — a class built over the wrong streamed blob = garbage fields. (I did
NOT renumber the enum this pass to avoid churn/regression; documented here instead.)

### Heat-family streamed in TEST.EGG (from the roster dump): Condenser x6 (0xBBD), Reservoir x1
(0xBC0), "HeatSink" x1 (0xBBE aggregate). The 0xBBE aggregate has NO reconstructed class (only
prose in heatfamily_reslice.hpp), so it is not instantiable. That leaves Condenser and Reservoir.

### Assert/crash analysis (heat.cpp, read-only):
- Condenser is the only ctor-safe heat class. HeatSink ctor @004adda0 (heat.cpp:415-428) resolves
  a linked sink via owner->GetSegment(heatSinkIndex) and Verify-aborts ("Bad subsystem resource
  ->heatSink") if null — BUT it SKIPS that whole block when IsDerivedFrom(Condenser) (true during a
  Condenser ctor iff shared_data == Condenser::DefaultData). So Condenser never hits the segment assert.
- Reservoir runs the segment block (it is HeatSink-derived, not Condenser) -> Verify-abort risk if
  heatSinkIndex doesn't resolve; PLUS its own master branch (heatfamily_reslice.cpp:446-448) does
  link->Attach(this) with no null guard; PLUS btl4vid MakeMechRenderables walks the roster touching
  ClassID 0xBC0 (Reservoir) at BINARY offsets (reconstructed layout != binary) — three independent
  risks. Not attempted past the Condenser result.

### What I actually did + the debugger-confirmed blocker:
Wired the REAL Condenser into case 0xBBD: new (Memory::Allocate(sizeof(Condenser))) Condenser(this,
id,(Condenser::SubsystemResource*)seg, Condenser::DefaultData) (used C++ sizeof(Condenser) for the
alloc — the reconstructed object size, guaranteed to cover every member the ctor writes; NO binary
hand-size, NO under-alloc). Added #include <heat.hpp>; renamed the two colliding local stubs
(Condenser->ReservoirStub, HeatableSubsystem->HeatableStub) so heat.hpp's real names win.
  - Build: GREEN. Construction: SUCCEEDED — all 6 Condensers built, mech spawned (no ctor assert; the
    Condenser skip-path held).
  - The master gate DID arm (owner->simulationFlags has &0xC==0 AND &0x100 — the Task-1 gate
    reconcile is correct): the Condenser installed HeatSink::HeatSinkSimulation and it TICKED frame 1.
  - CRASH (0xC0000005) on frame 1, cdb stack (PageHeap off):
      btl4!HeatSink::UpdateCoolant+0x35   heat.cpp:693
      btl4!HeatSink::HeatSinkSimulation+0xa4  heat.cpp:537<-531
      btl4!Simulation::Perform / PerformAndWatch
      btl4!Mech::PerformAndWatch  mech4.cpp:554
    ROOT: heat.cpp:692-693 `HeatSink *master = linkedSinks.Resolve(); coolantDraw = master->heatEnergy
    * heatLoad;` — linkedSinks is EMPTY for a Condenser (its HeatSink ctor skipped the linkage block),
    so master==NULL and master->heatEnergy derefs null. NB the sibling methods ConductHeat (heat.cpp:595)
    and BalanceCoolant (heat.cpp:646) DO null-guard linkedSinks.Resolve(); UpdateCoolant does NOT — a
    reconstruction omission (the shipped binary @4adbf8 must guard, since real condensers ran). Even the
    "correct" Condenser sim (RefrigerationSimulation @4ae4d8, which the reconstructed Condenser ctor fails
    to install) derefs master the same way (heatfamily_reslice.cpp:125-127) -> same crash.

### Why it can't be made stable from the allowed files (mech.cpp/mech.hpp + heat.hpp/powersub.hpp):
The fix is EITHER (a) a one-line null-master guard in heat.cpp::UpdateCoolant (mirroring its own
ConductHeat/BalanceCoolant guards) — but heat.cpp is outside the allowed edit set and UpdateCoolant's
body can't be patched from heat.hpp; OR (b) give the Condenser a VALID linked master heat sink — which
requires the 0xBBE master heat-sink bank (no reconstructed class) to be real AND the inter-sink linkage
to be wired, i.e. the whole heat family at once. Fabricating a self/peer link to dodge the null deref
would produce meaningless heat numbers (the exact "garbage" the brief warns against). This is precisely
the interdependence blocker already called out in "THE REAL BLOCKER" point 4 above — now proven with a
debugger trace rather than predicted.

### Before/after: tick stayed 1 (executable) of 30 — the Condenser tick CRASHED rather than surviving;
reverted -> 1/30 baseline restored. Stability after revert: 3/3 runs alive to 14s, bad-pattern count 0,
[drive] pos advances every frame. Build GREEN (mech.cpp only recompiled). NO files left modified.

### Reverted-to-stub: Condenser (0xBBD) — blocker = heat.cpp::UpdateCoolant null-master deref +
absent inter-sink linkage (interdependence). Reservoir (0xBC0) and HeatSink bank (0xBBE) — not attempted
(0xBBE has no class; Reservoir carries 3 independent crash risks).

### EXACT path forward for a (necessarily family-wide) heat pass:
1. Re-label the SubsystemClassID enum + re-target every switch case to the CLASSMAP class (table above).
2. Reconstruct the 0xBBE master HeatSink-bank class (heatfamily_reslice.hpp documents it: parses
   HeatSinkCount/AmbientTemperature, ctor @4ae8d0) so a real master exists.
3. Wire the heat inter-sink linkage in the Mech ctor (after the subsystem loop, like the existing
   gyro<->sinkSource cross-link @ mech.cpp ~683): link each Condenser/Reservoir's linkedSinks to the
   master bank. (linkedSinks is public on HeatSink — reachable from mech.cpp.)
4. Add the missing null-master guard to heat.cpp::UpdateCoolant (and install Condenser's real
   RefrigerationSimulation in its ctor) — REQUIRES heat.cpp edits (out of scope for this pilot's file set).
5. THEN instantiate the heat family together (Condenser+Reservoir+bank) and verify the tick rises by
   their count without the UpdateCoolant fault.
