Read BT's own respawn code and checked it against BTL4OPT.EXE itself.
FAITHFUL: BT's Player::VehicleDeadMessageHandler (FUN_0042db80, part_003.c:12029)
gates on message->deathCount == player->deathCount AND player+0x40 != 1
(simulationState != DropZoneAcquiredState) -- exactly WinTesla's two gates --
then runs the same closest-DropZone search skipping "win*" zones, dispatches
AssignDropZone and re-posts to itself on a timer. So the retry loop and the
cross-machine hunt are authentic 1995 behaviour, not a WinTesla artifact.
NOT FAITHFUL: BT's BTPlayer::VehicleDeadMessageHandler (FUN_004c012c,
part_013.c:10504) ENDS with *(param_1 + 0x290) = 0 -- it CLEARS the field our
reconstruction calls deathPending, at the end of every death. Verified in the
raw binary: +0x290 is written in exactly three places in the whole executable
(0x0b75fb, 0x0bffe3, 0x0c0a05) and ALL THREE store a zeroed register (xor
ecx,ecx / xor eax,eax / xor edx,edx immediately before). There is NO write of 1
or of any non-zero value to +0x290 anywhere in BTL4OPT.EXE. Two are ctor/reset
sweeps; the middle one is the death handler, sitting right after the call to
Post and add esp,0x14, matching the decompiled tail exactly.
So 1995 has NO death-pending gate. We invented it (btplayer.cpp:505) and then
needed six clear sites to patch the strandings it caused (:382 :469 :1431 :1442
:1461 :1532). #57 and #55 are artifacts of that invention. It is also what
makes a ghost PERMANENT: in BT a failed respawn is harmless (the 2s re-post
keeps hunting, the next death starts a clean cycle); in ours the first failure
latches the pilot and every later death is SWALLOWED forever -- exactly the
field signature of 8 cycles, 6 stranded, none recovering.
Fix proposed in the doc (match the binary: clear instead of latch, drop the
dedup gate) but NOT applied -- six sites depend on the latch and the dedup is
load-bearing, so it wants a deliberate two-node bench, not a 1am edit.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
