The two Performance bodies fell in a Ghidra gap (@004c11b3..@004c1408), so
BeABTDirector came straight off ndisasm of the shipped CODE section. The
verdict corrects the BT411 donor twice more: FUN_0049fb54 is not
'IsLiveMech' -- it is the mech DEATH-TRANSITION test (simulation state 2 or
9; its other callers strip update-record motion bits and halt motion
integration while it holds, and our own MovementMode ledger already said
so) -- and the donor's pick loop breaks on a DYING vehicle where the
binary's jz breaks on a LIVE one. The true 1995 behavior: the camera
lingers on its mech while the 30s timer runs, cuts away THE MOMENT the
followed mech starts dying, picks the first of four ranked players with a
live vehicle, and refreshes the lock during mission end. The 'BT-specific
0x15/0x34 track message' the port invented an engine substitute for IS the
engine's CameraShip::DirectionMessage -- ID 0x15 == Entity::NextMessageID,
0x34 bytes, byte-for-byte; the RP engine's own BeADirector source
(DIRECTOR.CPP survives) is the literal structural template BT overrode
(rank-0-only, 10s, no offset -> four ranks, 30s, (0,5,0) eye).
Mech::InDeathTransition lands in mech.cpp per the census (@0049fb54, 32
bytes). The ctor's replicant gate uses the binary's own flag test --
entity-side simulationFlags arrive live via the MakeMessage, unlike the
subsystem masters still waiting on the stream builders.
Stubs: 11 across 9 files (the 8 authoring CSS fns + the L4NET trio).
Pod-role soak clean; the director's live test rides the operator's
camera-egg / mission-review session.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
CydandClaude Fable 5
454102ef35