The ghost (a player who dies, never respawns, stays dead-but-driveable and is a
wreck on every peer) traces to a respawn stalling on drop-zone acquisition:
DropZone::AssignDropZoneMessageHandler grants a slot only if IsAvailable(), and
when none is free it reposts to ITSELF every 0.1s at MaxEventPriority and never
replies -- so deathPending is never cleared. This whole subsystem was DARK: not
one drop-zone line in a full night of field logs.
ALWAYS-ON (no env gate -- rare, catastrophic, field-only, same rationale as the
#57/#59 guards; volume bounded and rate-limited):
[dz] POOL -- slots + downTime + proximity radius, once per mission
[dz] GRANTED-- one per respawn, with the WAIT time; tags (GHOST RECOVERED)
when a long-stalled request finally lands (what testers see as
"it fixed itself")
[dz] STALL / GHOST LIKELY -- escalating, per-waiter rate-limited, and it names
WHY each slot is busy (age + last user), which discriminates
cooldown saturation from proximity blocking -- different fixes
[dzreq] -- the REQUESTER half: re-try count for this death, and msgDeath vs
our own deathCount. The engine gates the hunt on those being
equal AND the DropZone resend net is keyed on the same value, so
a mismatch breaks both silently (cf #45, tally replication).
BT_DROPZONE_LOG=1 adds the verbose per-request slot dump for bench work.
First run already overturned a theory: slots=8, so an 8-slot pool cannot be
cooldown-starved by 5 players (max 5 on cooldown at once) -- the shared
dropzone=one in eggmodel.py is NOT the bottleneck. Suspicion moves to the
handshake (lost reply / deathCount mismatch).
Verified with NO env vars set, exactly as a tester runs it: 4 probe lines for a
full death+respawn cycle, all in the normal day log.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
