THE GAP: Mech::Reset sweeps every subsystem with the virtual DeathReset
(mech4.cpp:1789), but only 7 weapon/ammo classes overrode it -- the entire
heat/coolant/power family fell through to the empty Subsystem::DeathReset base
(SUBSYSTM.h:161), so the respawn reset was a SILENT NO-OP for them. All the
ResetToInitialState bodies already existed; nothing ever called them. Hence the
field report: 'respawned with drained coolant'.
Added DeathReset forwarders (ResetToInitialState is not virtual, so each class
with its own body needs one): HeatableSubsystem, HeatSink, Condenser,
PoweredSubsystem, Generator. HeatSink's also serves Reservoir -- the coolant
tank -- which has no body of its own; that is the one that refills coolant.
TWO MIS-TRANSCRIPTIONS FIXED, both verified against the binary with capstone:
1. HeatSink::ResetToInitialState chained HeatableSubsystem::ResetToInitialState
with the comment 'FUN_004ac22c'. But @004ac22c is Subsystem's terminus --
disassembled: it reads the damage zone at this+0xe0, clears zone+0x158, and
Set_Alarm_Levels zone+0x10 and this+0x2c to 0. And the binary's HeatSink
@004ad760 calls only @004ad884 (ClearHeatFilter), @004ad7f0 (UpdateHeatLoad)
and @004ac22c -- never HeatableSubsystem. Worse, HeatableSubsystem's body sets
currentTemperature = 300.0f, CLOBBERING the startingTemperature that HeatSink
assigned four lines earlier. Dropped the call; the terminus work is already
done for every subsystem by MechSubsystem::RespawnRepair (mech4.cpp:1790).
2. Generator::ResetToInitialState chained HeatableSubsystem and set
outputVoltage = 0 -- which matches GNRATOR.TCP, but BT's BINARY DIVERGES from
the TCP source, and the binary is what shipped. Disassembled @004b215c
instruction by instruction: it chains HeatSink (so the coolant refill DOES run
for a generator), then generatorOn=1, startTimer=0, stateAlarm 0 then 2,
**outputVoltage = ratedVoltage**, coolantAvailable=1, coolantFlowScale=1.0,
startTimer=startTime. Every offset matches our declared members exactly.
The old version brought generators back from a respawn at ZERO output voltage,
so energy weapons could never charge -- no recharge ring, no ready dot, nothing
damaged. That is a strong candidate for #54 (David's three dead lasers).
LIVE VERIFICATION (sim3.py, 3 mechs + force damage): 4 death/respawn cycles, and
every heat sink logged coolant == capacity on every respawn, with temp restored to
startingTemperature (77) rather than the clobbered 300. Left as a silent
regression guard that only speaks if a respawn leaves coolant short.
KNOWN REMAINING [T3, noted in code]: Condenser's body chains HeatableSubsystem
rather than HeatSink, so a coolant loop's VALVE DETENT may still persist across a
respawn -- the binary's Condenser reset is not yet decompiled. Do not claim
valves are fixed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0166KTsC7ADm7VXEi1HF1jNg
