Files
BT411/game/reconstructed
Joe DiPrimaandClaude Fable 5 b70654dd11 torso twist died after a respawn: Myomers ran the inner integrator, never the wrapper
Gitea #70. Torso twist intermittently stops working after a death/respawn and
stays stopped, with the generator at a full 10000V and the voltage link
resolving fine. A stale state, not a live one.

The Torso is a PowerWatcher that mirrors the electrical level of the subsystem
it watches -- for the MadCat that is roster slot 15, Myomers -- and
torso.cpp:570 holds effectiveTwistRate at 0 whenever that mirrored level is not
Ready. So the question was never about the torso. It was: why does Myomers sit
at NoVoltage forever?

Because it never ran the state machine that would walk it back. The Myomers ctor
@004b8fec stores [0x511620] into activePerformance, and that pointer resolves to
0x4b8b9c -- whose first instruction is `call 0x4b0bd0`, which is
PoweredSubsystem::PoweredSubsystemSimulation. @004b8d18, the function this port
had registered, is the INNER drive-heat integrator that wrapper goes on to run.
We registered the inside of the onion. PoweredSubsystemSimulation is the only
code that both enters NoVoltage (source == 0) and leaves it
(NoVoltage -> Starting -> Ready), so a Myomers that lost power during the
death/reset window had no way back out.

Order is load-bearing: the base call precedes the heat-model gate in the binary.
Gating first -- as this did -- also denied the electrical machine to every
non-expert pilot, since OwnerAdvancedDamage() reads the +0x260 heat-model flag
and that is off below veteran.

Measured with BT_SELF_DAMAGE + BT_TORSO_LOG, before and after:

  pristine, before  48/48 Ready    after  38/38 Ready
  post-respawn      95/97 Ready           89/89 Ready

Two dead windows per respawn, now none, and the clean case stays clean.

The wrapper has a tail this does not yet reconstruct: @004b8bb9-0x4b8c1e runs an
effect when electricalStateAlarm == 1 and the myomer's damage zone is below 1.0,
building a small vector (const 0xbc343958, about -0.011f) against the owner's
localOrigin@0x100. Almost certainly the un-powered movement penalty. Flagged in
the KB as T4 rather than guessed at.

Worth generalizing, and noted as such in context/subsystems.md: when a
subsystem's Performance address in a PTR_LAB_* slot does not match the function
we reconstructed, suspect a wrapper that chains the base sim. The whole family
does it -- Generator and PoweredSubsystem both lead with
HeatSink::HeatSinkSimulation, and the Torso's own perf @004b5cf0 leads with
UpdateWatch.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-28 14:30:48 -05:00
..