vwemirror/BT411
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

#81 ghost: light the SILENT DISCARD -- the only path a respawn can vanish on

Browse Source 
Walked the respawn handshake end to end and measured the assumptions.  Two
eliminations and one find:

ELIMINATED: the engine hunt re-posts to itself every 2s forever while the mech
is dead (PLAYER.cpp:325-327; its only state-based exit never fires, see below),
and the DropZone re-grants the SAME slot to a repeat request from the same
requester+deathCount even while busy (DROPZONE.cpp:182-194).  So neither a
transient "no slot" nor a single lost reply can strand a respawn -- the request
keeps being re-sent and re-granted.  A permanent strand needs a permanent cause.

THE FIND: BTPlayer::DropZoneReplyMessageHandler ends
  if (!playerVehicle) ... else if (deathCount == message->deathCount) ... else { return; }
and that last branch was a BARE RETURN WITH NO LOG.  The drop zone grants a
spot, replies, the numbers disagree, the reply is dropped, deathPending stays
latched, the mech is never Reset -> permanent ghost, zero evidence.  That is
why 6 of 8 field cycles stranded silently.  Now always-on, printing the
DIRECTION of the mismatch: msgDeath < ours = genuinely stale (dropping is
right); msgDeath > ours = our counter is behind and we just threw away a LIVE
respawn -> points straight at #45 (the death tally does not replicate).
Deliberately NOT auto-recovered: guessing would be a stand-in, and the wrong
guess resets a mech that is still alive.

LANDMINE DOCUMENTED IN CODE: Set_Alarm_Level is an empty stub (btstubs.cpp:87),
so the death path's Set_Alarm_Level(this+0x2c,1) and the reply's (+0x2c,2) are
no-ops.  Their values decode against Player's enum as DropZoneAcquiredState(1)
and VehicleTranslocatedState(2), which makes "these should obviously be
SetSimulationState() calls" both attractive and CATASTROPHIC: the engine hunt is
gated on GetSimulationState() != DropZoneAcquiredState, so setting 1 on death
would stop AssignDropZone ever being dispatched and ghost EVERY pilot.  Measured
our simulationState at 0x24 (not 0x2c) and the write leaves it 0; in the binary
+0x2c is the Simulation-base alarm (the field the mech side calls graphicAlarm,
@0x4ac126 "owner alarm+0x2C -> level 9"), which our layout models only on Mech.

Verified solo: a healthy death+respawn logs the grant and the RESET and emits
ZERO discard/gate-off lines (no false positives).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Joe DiPrima
2026-07-30 01:08:01 -05:00
co-authored by Claude Fable 5
parent 372cbfa344
commit 0dbdad17f3
2 changed files with 120 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
game/reconstructed/btplayer.cpp
+75
View File
@@ -429,6 +429,15 @@ void
static int s_forDeath = -999;
if (s_forDeath != message->deathCount) { s_forDeath = message->deathCount; s_tries = 0; }
++s_tries;
// #81: the OTHER gate. The engine hunt (PLAYER.cpp:229) requires
// BOTH message->deathCount == deathCount AND simState !=
// DropZoneAcquiredState. Report both, so a stranded respawn names
// its own cause instead of being inferred.
if (GetSimulationState() == (unsigned)DropZoneAcquiredState)
DEBUG_STREAM << "[ghost] hunt GATED OFF: simState="
<< (int)GetSimulationState() << " == DropZoneAcquiredState"
<< " -- the engine will not dispatch AssignDropZone, so no"
<< " reply, no RESET, permanent ghost\n" << std::flush;
if (s_tries <= 3 || (s_tries % 5) == 0)
DEBUG_STREAM << "[dzreq] player " << BTMatchHostOf(GetEntityID())
<< ":" << (int)GetEntityID() << " asking for a drop zone"
@@ -578,6 +587,25 @@ void
DEBUG_STREAM << "[respawn] BUG (Gitea #59): the death path left this "
"player's watchers DELAYED -- ExecuteWatchers is dead for it now\n"
<< std::flush;
// ⚠ LANDMINE, MEASURED 2026-07-30 (#81 dig). `Set_Alarm_Level` is an empty
// STUB (btstubs.cpp:87), so this write and its partner in
// DropZoneReplyMessageHandler (+0x2c, 2) are NO-OPS today.
//
// DO NOT "fix" them by calling SetSimulationState(). The values 1 and 2
// decode against Player's enum as DropZoneAcquiredState and
// VehicleTranslocatedState (PLAYER.h:273-279), which makes that conversion
// look obviously right -- and it would BREAK RESPAWN ENTIRELY: the engine's
// respawn hunt is gated on `GetSimulationState() != DropZoneAcquiredState`
// (PLAYER.cpp:231), so setting state 1 on death means AssignDropZone is
// never dispatched for that death and EVERY pilot ghosts permanently.
//
// +0x2c is not simulationState (ours is at 0x24, measured). In the binary
// it is the Simulation-base ALARM indicator -- the same field the mech side
// calls `graphicAlarm` (@0x4ac126 sets "owner alarm+0x2C -> level 9"). Our
// layout models that only as a Mech member, so a BTPlayer has nowhere to
// put it; the stub is therefore harmless until we find what reads a
// PLAYER's alarm in the binary (unrecovered; likely a cockpit/HUD respawn
// indicator). [T1 offsets, T3 purpose]
Set_Alarm_Level((char *)this + 0x2c, 1); // FUN_0041bbd8(this+0x2c, 1)
//
@@ -1438,6 +1466,36 @@ void
}
else // stale / old message
{
//
// #81 GHOST: THIS IS THE LAST PLACE A RESPAWN CAN VANISH WITHOUT A
// TRACE. The drop zone granted us a spot and dispatched the reply, but
// its deathCount does not match ours -- so the reply is dropped, the
// mech is never Reset, `deathPending` stays latched, and the pilot is a
// permanent GHOST: dead, un-reset, still simulated and driveable, and a
// burning wreck on every peer (which then sinks after ~18s and can
// never be drawn again, btl4vid.cpp:1277). Until now this branch was a
// bare `return` with no log at all, which is exactly why 6 of 8 field
// death cycles stranded on 2026-07-29 leaving no evidence.
//
// ALWAYS ON, and it prints the DIRECTION of the mismatch, which decides
// the fix: msgDeath < ours means the reply is genuinely stale (a
// superseded death) and dropping it is correct; msgDeath > ours means
// OUR counter is behind (a missed increment / a replicated write -- cf.
// #45, the death tally does not replicate correctly) and the reply is
// for a live death we should have honoured. Do not "recover" here
// until the field logs say which way it goes -- guessing would be a
// stand-in, and the wrong guess re-spawns a mech that is still alive.
//
DEBUG_STREAM << "[ghost] DROP-ZONE REPLY DISCARDED for player "
<< BTMatchHostOf(GetEntityID()) << ":" << (int)GetEntityID()
<< " -- msgDeath=" << message->deathCount
<< " ourDeathCount=" << deathCount
<< (message->deathCount < deathCount
? " (reply is STALE -- superseded death)"
: " *** OUR COUNTER IS BEHIND -- this was a live respawn and we just threw it away ***")
<< " deathPending=" << deathPending
<< (deathPending != 0 ? " <== LATCHED: this pilot is now a GHOST" : "")
<< "\n" << std::flush;
return;
}
@@ -1543,6 +1601,23 @@ BTPlayer::BTPlayer(
<< " deathPending@0x" << (int)offsetof(BTPlayer, deathPending)
<< std::dec << " <-- the raw write targets byte 0x284\n"
<< std::flush;
// #81 GHOST DIG: the death path does Set_Alarm_Level(this+0x2c, 1)
// and the drop-zone reply does (this+0x2c, 2). Decoded against
// Player's enum those are DropZoneAcquiredState(1) and
// VehicleTranslocatedState(2) -- i.e. the BINARY's +0x2c is the
// Player's simulationState. The engine's respawn hunt is gated on
// `GetSimulationState() != DropZoneAcquiredState`
// (engine/MUNGA/PLAYER.cpp:229), so if that raw byte really is our
// simulationState, EVERY death marks "drop zone already acquired"
// and the hunt can never run -> permanent ghost. Print where our
// compiled layout actually puts it.
DEBUG_STREAM << "[layout] simulationState@0x" << std::hex
<< (int)((char *)&simulationState - (char *)this)
<< std::dec << " (raw death write targets 0x2c;"
<< " DropZoneAcquiredState=" << (int)DropZoneAcquiredState
<< " VehicleTranslocatedState=" << (int)VehicleTranslocatedState
<< ") liveState=" << (int)GetSimulationState() << "\n"
<< std::flush;
}
}