Commit Graph
3 Commits
Author SHA1 Message Date
CydandClaude Fable 5 e9b51cd6ee Mech milestone phase 2: map the complete subsystem family tree
Records the full mech-subsystem hierarchy discovered while reconstructing the
roster, with per-class build status. 6 classes done + verified (MechSubsystem,
HeatableSubsystem, HeatSink, PoweredSubsystem, Sensor, Generator); the tree shows
the remaining intermediates (HeatWatcher : MechSubsystem, PowerWatcher :
HeatWatcher) that unblock the Torso/HUD/Gyroscope branch (the Mech's directly-
referenced subsystems), plus Myomers/Condenser leaves and the separate weapon
subtree. The reconstruction pattern is now a proven template (documented). Enables
efficient continuation.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-19 23:51:55 -05:00
CydandClaude Fable 5 82de438dfb Mech milestone phase 2: reconstruct HeatableSubsystem + map the roster hierarchy
HeatableSubsystem (HEAT.CPP) reconstructed + compile-verified (BT: 25 ok):
statics, ctor (chains MechSubsystem resource form + ResetToInitialState ->
currentTemperature=300, heatLoad=0), dtor, TestClass/TestInstance,
CreateStreamedSubsystem staged. Verified slice now: Subsystem -> MechSubsystem
-> HeatableSubsystem.

Also mapped the roster hierarchy from BT411, which is DEEPER than the staged
headers (recorded in MECHSUB.NOTES.md):
  MechSubsystem -> HeatableSubsystem -> HeatSink -> PoweredSubsystem -> {Sensor,
  Generator, ...}
Findings for the next steps: (1) HeatSink is MISSING entirely from the staged
tree and must be added between HeatableSubsystem and PoweredSubsystem;
(2) staged POWERSUB.HPP wrongly derives PoweredSubsystem from HeatableSubsystem
(real base = HeatSink) -- fix it; (3) PoweredSubsystem has inter-subsystem wiring
(resolves its voltage-source generator from the owner mech's subsystem roster),
imposing a segment-walk ordering constraint for the phase-4 ctor.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-19 23:14:49 -05:00
CydandClaude Fable 5 02a6355f0e Mech milestone phase 2 kickoff: MechSubsystem base analysis (damage-model de-risk)
Begins phase 2 (MechSubsystem base + subsystem roster) with the base-class
analysis that keeps the reconstruction on the 4.10 damage model. Key findings:

- All base deps survive: Subsystem (SUBSYSTM.HPP + staged SUBSYSTM.CPP),
  DamageZone (DAMAGE), Mech__DamageZone + BT damage model (MECHDMG.HPP),
  AlarmIndicator (just built).
- Finding 1: the staged base Subsystem ctor sets damageZone=NULL, so the derived
  MechSubsystem creates the Mech__DamageZone (BT411's zone-creation is right).
- Finding 2 (CRITICAL): the damage model DIVERGED. 4.10 is per-damage-TYPE --
  DamageZone has defaultArmorPoints + damageScale[5] {collision/ballistic/
  explosive/laser/energy} and STREAMS its own armour (DAMAGE.CPP:335,413).
  BT411 reconstructed a per-FACING armorByFacing[5]/structureReference model that
  MechSubsystem hand-seeds -- those fields exist only in BT411's ReconDamageZone
  proxy, NOT in the 4.10 zone. So BT411's MechSubsystem ctor CANNOT be backdated
  verbatim; doing so would install a damage model the 4.10 engine doesn't
  implement, corrupting every subsystem.

Corrected approach (now fully scoped, ready to write): chain base Subsystem,
create Mech__DamageZone, add mech-specific members + TakeDamage override, let the
zone stream per-type armour. Full detail in MECHSUB.NOTES.md; the staged
MechSubsystem__SubsystemResource (per-facing, BT411-copied) is flagged for
re-derivation.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-19 22:17:43 -05:00