TeslaRel410/restoration/source410/BT/HEAT.NOTES.md

HEAT.CPP / POWERSUB.CPP — the power/heat wave (Phase 5.3.10, 2026-07-21)

The mech's thermal + electrical economy is LIVE: weapons dump firing heat into their own sinks, the sinks conduct through the Condenser bank into the central HeatSink, temperatures drive the degradation/failure alarms, and every powered subsystem tracks its generator through the electrical state machine.

The heat topology (wire-verified on TEST.EGG)

linkedSinkIndex (the previously-missing HeatSink resource int — see below) wires the authored conduction graph at construction:

weapons / equipment  ->  Condenser1..6 (slots 4-9)  ->  central HeatSink (slot 2)
GeneratorA..D (10-13) ->  Condensers
Reservoir (3)         ->  central HeatSink

Authored values match the BT411 calibration audit EXACTLY: central bank mass 1.39e6, PPC's own sink 174000, thresholds 77 start / 1000 degradation / 2000 failure, PPC conductance 86800. (The central sink's own linkedSinkIdx=5 is a FORWARD reference — Condenser2 isn't constructed yet at slot 2's ctor — so its drain is unwired; a post-walk fixup is a small future item. Everything drains INTO it fine.)

Reconstructed

• HeatSink::HeatSinkSimulation (@004ad924): absorb pendingHeat → T = E/mass → UpdateHeatLoad (15-sample filter) → ConductHeat → alarm thresholds. Installed by the HeatSink ctor (derived classes override and chain it).
• ConductHeat / ComputeHeatFlow (@004ad8ac/@004ad9ec): the two-body equilibrium relaxation — (T·massScale − (E_other+pending+E_own)/denom)·tau· (1−exp(−dt·conductance·(coolant/capacity)·flowScale/denom)). Verified: flow == 0 exactly at uniform temperature; a fired PPC bleeds ~170K units/step into Condenser4.
• PoweredSubsystem ctor + PoweredSubsystemSimulation (@004b0f74/@004b0bd0): resolves voltageSourceIndex from the roster (GeneratorA-D — wire-verified), attaches the tap (Generator::TapVoltageSource, −1 when full), and runs the electrical FSM (Starting=0 / NoVoltage=1 / Shorted=2 / GeneratorOff=3 / Ready=4) watching the generator state. Deferred: the AutoConnect replacement-generator hunt (needs the status flags / damage wave).
• Generator::GeneratorSimulation (PARTIAL): heat step + start/short-recovery timers; the load model (voltage sag, I²R self-heat feeding the charge integration) joins the electrical-charge wave (TrackSeekVoltage).
• Sensor::SensorSimulation upgraded to the authentic gating (@004b1c4c): power step first, radar = 1 − damage, electrical-Ready gate (badVoltage), heat-state switch (Degradation ×0.5, Failure → 0). Verified: voltState=4, radar 100% on the healthy mech.
• Weapons: Emitter/Projectile sims run the power step at their head; the Loading recharge is gated on electrical Ready (authentic @4bbdf5); FireWeapon dumps the firing heat.

Heat units (1e7-native) — TWO authoring conventions

The heat chain is 1e7-unit-native (BT411 audit). The stream stores heatCostToFire in TWO conventions:

• Energy weapons: small units (PPC = 11) — the ×1e7 comes from the energy closed form ((1−dF)·E ≈ heatCost·1e7 at full charge). Our partial multiplies by 1e7 pending the charge model.
• Ballistics: native units (SRM6 = 5.06e7) — dumped RAW. (Double-scaling this to 5e14 was the runaway-temperature bug during bring-up.) Both land ~+640K on the weapon's own sink — the consistent design magnitude.

The resource-alignment resolution (wire-verified, closes the +3 mystery)

The raw-stream dumps pinned the FULL ancestry alignment:

• HeatSink__SubsystemResource.linkedSinkIndex — THE missing int that shifted every descendant block +1 (PoweredSubsystem's voltageSourceIndex previously read the linked-sink index — hence "power sources" appearing to be Condensers).
• The MechWeapon pip tail is pipPosition(int) + pipColor(3 floats) + pipExtendedRange(int) (+2) — matches BT411's verified overlay exactly.
• +1 +2 = the +3 the interim ProjectileWeapon pad compensated; the pad is gone.
• True bhk1 reads: PPC recharge 5.0 s (not the misaligned 1.0), discharge 0.99 s, range 900, damage 12, heatCost 11, pipColor (0,0,1); SRM6 recharge 5 s, range 800, salvo damage 35, missileCount 6.

VERIFIED (BT_FORCE_FIRE + BT_POWER_LOG)

PPC: 77° → fires → ~709° → relaxes to 441° across its 5 s reload → sustained fire climbs the residual 441 → 674 → 838 → 960 — brushing the 1000° degradation threshold: the authentic fire-discipline game. SRM salvos spike +641K and cross degradation after three. Condensers absorb and pass to the central bank. Neutral run: sensor Ready/100%, mech holds, zero Fail.

Heat consequences (Phase 5.3.11, 2026-07-22)

The weapon-side consequences are wired and VERIFIED under sustained fire:

• Ballistic gate 1 (@4bbd36): weapon destroyed-state or its own sink at FailureHeat pins full recoil + the unavailable alarm (the NoAmmo roach-motel re-asserts). (Mech-disabled half joins the damage wave.)
• CheckForJam (@4bbfcc): p = 0.41·T/failT clamped [minJamChance, 1.0], rolled per granted shot against the MUNGA uniform Random. Interim gate: heat-degraded only (stands in for the deferred LiveFireEnabled novice switch AND the trivially-true heatLoad>0 early-out — the exact spurious- cold-jam trap the BT411 port documented). Verified: SRM6s jam at T≈1200-1320 (24%+ rolls past the 1000° threshold), stay jammed.
• Emitter hard gate (@4baab9): FailureHeat drops the beam state + charge each frame; SELF-RECOVERING — conduction cools the sink below 2000° and the weapon resumes from Loading. Verified: the PPC settles into an emergent thermal duty cycle (fire at ~1930° → spike 2562° → shutdown → cool → refire); the lasers oscillate around ~2200°.

The experience gates + the coolant wave (Phase 5.3.12, 2026-07-22)

The player-experience gates are LIVE (the workflow dossier recovered every body from the BT411 RE):

• HeatSink::HeatModelActive() (binary FUN_004ad7d4): owner mech → Entity::GetPlayerLink() → BTPlayer::heatModelOn — ON only for veteran / expert. Gates BOTH phases of HeatSinkSimulation (absorb/conduct AND UpdateCoolant) and every weapon fire-heat dump. Standard mode has NO heat consequences — authentic. NULL player link reads ON (dev-permissive).
• ProjectileWeapon::LiveFireEnabled(): playerLink → simLive — 0 only for novice, whose ballistics never jam. CheckForJam is now the AUTHENTIC form: LiveFireEnabled early-out + the heatLoad <= 0 early-out (with the model off heatLoad stays 0, so standard mode never jams either) + the minJamChance floor (a veteran+ launcher carries its authored ~5% cold jam chance — the interim heat-degraded gate is retired).
• BTPlayer's flag block renamed to its TRUE semantics (simLive @0x25c, heatModelOn @0x260, advancedDamageOn/2, levelFlag26c/270, experienceLevel) — the ctor rows were already binary-accurate; only the names/types were the old "display toggles" misread.

THE LOAD-BEARING FIX found on the way: Mech ctor SetValidFlag(). Every 1995 entity ctor tail marks itself valid; ours didn't — and Entity::Dispatch routes messages to an INVALID entity into the deferred event queue, so the PlayerLink bind (and every directly-dispatched mech message) silently never landed. The experience gates read a NULL player forever (permissive ON) until this one authentic line was restored.

The coolant system (all bodies authentic from the dossier, constants byte-verified: HeatLoadScale 0.002 → heatLoad now lives in the [0,1] band, HeatEqualizeEpsilon 1e-4, draw floor 0.0025 / ON 0.003, draw gate 1e-4):

• UpdateCoolant (@004adbf8): coolantDraw = own structural damage × heatLoad (an UNDAMAGED mech leaks nothing — the bars stay full), drain, top-up via the virtual DrawCoolant, and the active-flag hysteresis.
• BalanceCoolant (@004ada94): full clamp chain, called from ConductHeat.
• DrawCoolant base = 0; Reservoir overrides it as THE SOURCE (@4af3b0).
• Reservoir reconstructed (@4af408): capacity overlays thermalCapacity (streamed 20), squirtMass 0.5, CoolantSimulation + InjectCoolant (@4aefa4, the full flush distribution: condensers → weapons → heatables → master with intentional duplicate weighting, squirts only leave the tank, the chill only cools). BT_FORCE_FLUSH=1 dev hook (the cockpit InjectCoolant button joins the message wave). Deferred: the AggregateHeatSink master-bank attach + the 0.05×count capacity rescale.
• Condenser refrigeration (@4ae4d8): valveState inits 1, massScale = (1 − own damage) × refrigerationFactor (streamed 3.0) clamped ≥ 1 each frame — the condenser pumps heat as if 3× hotter, chilling itself below ambient; that chill is what cools the weapons. INTERIM: coolantFlowScale stays 1.0 (authentic streams 0 + the MoveValve/BTRecomputeCondenserValves share assignment — the cockpit-button wave; zeroing it now would strand condenser heat).

VERIFIED headlessly, both directions of the experience lever (TESTNOV.EGG = TEST.EGG with experience=novice):

• NOVICE: 212 fire cycles ALL at T=77, zero jams, zero shutdowns, coolant static — the heat model authentically absent.
• EXPERT: playerLink resolves, the full economy runs (PPC duty cycle now sawing ~650-1200° — the refrigeration pump drains harder than before — 119 shutdowns + 2 authentic jams under forced sustained fire). Zero Fail in both.

Still deferred

The electrical charge model (TrackSeekVoltage / voltage sag / I²R), the mech-disabled halves of the weapon gates (damage wave), the AggregateHeatSink family (the central bank's count/radiator loop + reservoir attach + capacity rescale + its forward-linked drain), the MoveValve / ToggleCooling / InjectCoolant cockpit-button message handlers + BTRecomputeCondenserValves, Myomers movement heat, jam recovery via ResetToInitialState (mission reset).

The cockpit-button message layer (Phase 5.3.13, 2026-07-24)

The subsystem-family button messages are LIVE through the authentic Receiver dispatch -> per-class handler-table path (the id space decodes cleanly: Receiver::NextMessageID == 3, so ToggleCooling = 3 on the HeatSink chain and the per-class id 4 is MoveValve on a Condenser / InjectCoolant on the Reservoir -- the same number, different class, exactly the binary's per-receiver-class convention):

• HeatSink::ToggleCoolingMessageHandler (@004ad6f8, id 3): novice-locked, press-only; toggles coolantAvailable + coolantFlowScale together (OFF strands this sink's heat until switched back).
• Condenser::MoveValveMessageHandler (@4ae464, id 4): novice-locked, press-only; cycles the valve 1 -> 5 -> 50 -> 0 -> 1 and calls Condenser::RecomputeValves (@0049f788): every condenser's coolantFlowScale = valve / sum-of-valves. The Condenser ctor now streams the authentic flowScale = 0; the Mech ctor seeds the shares once at spawn (all valves 1 -> equal shares) -- retiring the flowScale=1 interim. (The condenser-alarm change pulse joins the gauge wave.)
• Reservoir::InjectCoolantMessageHandler (@4aee70, id 4): novice-locked; press raises the inject alarm when the tank holds charge (flush-cloud psfx deferred), release drops it.
• MechSubsystem::NoviceLockout() (@4ac9c8): owner -> playerLink -> experience == novice; unlinked mechs read unlocked.
• DEV harness: BT_PRESS_VALVE / BT_PRESS_FLUSH dispatch the REAL messages ~6 s in (Mech::Simulate).

VERIFIED: spawn shares 6 x 0.166667; one MoveValve press -> Condenser1 valve=5 flow=0.5, the others 0.1 (valve/sum exactly); the flush arms via the real button message; NOVICE: both presses swallowed by the lockout (valve lines stay spawn-only, zero flush). Zero Fail throughout.