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

#45 scoreboard: reclaim the binary's DEATHS field, add a heartbeat, sweep the false KB claims

Browse Source 
Follow-up to 4fa7eee, driven by an adversarial review pass and three rig cycles.
Each item below is a real defect that pass found, not polish.

DEATHS now uses the binary's own column.  PilotList::Execute @0x4cabd0 draws
`fild [edi+0x27c]` (KILLS) and `fild [edi+0x280]` (DEATHS); +0x280 has exactly
two runtime writers image-wide plus the ctor zero.  Our port had declared it
`pad_0x280`, never written, and displayed the ENGINE's Player::deathCount
(+0x200) instead -- which is the respawn-handshake identity, seeded -2, and is
why it needed a clamp to pass as a count.  It is now BTPlayer::deathTally (our
offset 0x274, offsetof-locked), incremented beside ++deathCount, read by the
gauge, and replicated.  deathCount is left to the engine's handshake.  So this
half moves TOWARD the binary; it also closes the plan's Headline-1.
(`deathTally`, NOT `deaths`/`deathCount` -- those would shadow the base.)

The mirror was not self-healing: update records are UNRELIABLE by construction
(Entity::UpdateMessage clears ReliableFlag, ENTITY3.h:112; the relay's UDP path
also drops stale/reordered datagrams), and the pair was dirtied only on an
event.  One lost datagram left every peer stale until that pilot's next kill or
death -- forever for the last kill of a round.  Added a 2s heartbeat that
re-dirties the record, which also bounds how long the binary's phantom
partner-increment stays visible.  The timer is a function static deliberately: a
data member would change sizeof(BTPlayer) and break the offset locks.

Also fixed: the SBMIRROR row AND its change-detect both still read deathCount (a
constant -2 here), so the "log only the edge" guard could never be false and
every row printed deaths=-2.  That is what made the first rig runs look like
DEATHS was broken when a WRITE/READ trace proved the transport correct.  Row
count per node fell from ~20 to 3, one per real change.

Guarded the record against per-bit layouts: update_model is a BIT INDEX and
Entity::WriteUpdateRecord switches on it (ENTITY.cpp:329-352) -- the DamageZone
bit emits a variable-length packed stream whose length it computes itself, so
appending two ints and re-stamping recordLength over that would corrupt it.

Deleted BTPlayerCountObservedDeath -- definition, call site, extern and friend
together, since /FORCE hides stragglers.  It never executed (its call site sat
inside the once-per-death transition, which a replicant never enters) and could
not have worked (0 of 8800 corpus DMG rows target a replicant, which is why every
DEATH inst=R row reads killer=0:0).  Under replication it would have been a
second writer of a replicated counter.

New forensics: NOCREDIT names the failing link when a kill credit is skipped (it
used to be completely silent -- the counter simply never moved), and PLAYER_LINK
records whether the one-shot link resolved.  Both retire the NULL-playerLink
theory: every rig shows `PLAYER_LINK inst=R resolved=1` and no NOCREDIT rows.
PLAYER_DEAD now logs both counters (deaths=handshake, tally=scoreboard).

KB sweep of the claims that hid this bug for so long:
  * context/gauges-hud.md's "RESOLVED -- deaths tally per node from locally
    observed events" was FALSE; corrected with the measured evidence.
  * docs/GAUGE_COMPOSITE.md + btl4gau3.cpp "the dead pad_0x280" -- never dead,
    merely unwritten.
  * btplayer.hpp attributed VehicleDeadMessageHandler to @004c012c; it is
    @004c05c4 (absent from the decomp export -- the #60 gap).
  * docs/RESPAWN_REARM_PLAN.md's "#45 SUBSUMED" -- the PLAYER_DEAD symptom was
    subsumed, the scoreboard defect was not.
  * The corpus figure in the record banner now states its method so it is
    reproducible.

Rig-verified (2-node loopback, several cycles): owner 3:1 kills 2/tally 1 read
`kills=2 deaths=1` on the peer; owner 2:1 kills 1/tally 2 read `kills=1 deaths=2`
on the peer.  Respawn unaffected, no crash, no GLITCH rows.  Still awaiting live
multi-pod verification by a human; all pods must run the same build.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
arcattack
2026-07-25 22:09:00 -05:00
co-authored by Claude Opus 5
parent 4fa7eee54f
commit a52207d779
11 changed files with 316 additions and 86 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/RECONCILE.md
+25 -4
View File
@@ -1579,6 +1579,23 @@ therefore point at BTPlayer's versions. No new data member and no new virtual, s
`sizeof(BTPlayer) == 0x28c` is unchanged and the existing offset locks still hold. **[T3 on the
divergence being *necessary*; T0 on the mechanism that makes it necessary.]**
The record only appends to the DEFAULT update model. `Entity::WriteUpdateRecord` switches on the
bit (`ENTITY.cpp:329-352`) and the DamageZone bit emits a variable-length packed stream whose length
it computes itself, so re-stamping `recordLength` over that would corrupt it. A pilot only ever sets
the default bit (plain `ForceUpdate()`), which is why the engine's own `Player::WriteUpdateRecord`
gets away with being bit-agnostic; we guard anyway.
**Second, smaller divergence in the same change: `+0x280` put back into service.** The DEATHS column
is now `BTPlayer::deathTally` (our offset 0x274) -- the binary's own `+0x280`, which
`PilotList::Execute` @0x4cabd0 draws with `fild [edi+0x280]` and which has exactly two runtime
writers image-wide (@0x4c0674/@0x4c067a) plus the ctor zero. Our port had declared it `pad_0x280`,
never written, and displayed the ENGINE's `Player::deathCount` (+0x200) instead -- which is really
the respawn-handshake identity (seeded -2 at `PLAYER.cpp:777`, matched at `:230`) and needed a
display clamp to pass as a count. So this half is a move TOWARD the binary, not away from it: the
gauge reads the field the arcade read, and `deathCount` is left to the engine's handshake. Naming
note: it is `deathTally`, NOT `deaths`/`deathCount`, which would shadow the base
(reconstruction-gotchas #1).
**Why it is necessary.** A kill is credited by `BTPostKillScore` on the VICTIM's node, which
resolves the killer's `Player` — a REPLICANT there — and calls `Dispatch()`. `Entity::Dispatch`
reroutes a replicant's message to the owning host (`ENTITY.cpp:244-251`), so `++killCount` lands
@@ -1589,10 +1606,14 @@ no other node can even know the killer. The pods' closed LAN made the one-way en
sufficient in 1995 only because nothing ever needed the counters off-node — the arcade cabinet
scoreboard each pod drew was its own.
**Verified live** (2-node loopback, Release, `BT_MP_FORCE_DMG`, 2026-07-25): both nodes converged
exactly — owner 3:1 (kills 3 / deaths 2) read `kills=3 deaths=2` on the peer, owner 2:1
(kills 2 / deaths 3) read `kills=2 deaths=3` on the peer. 3 respawns per side, death sequences
intact, no crash.
**Verified live** (2-node loopback, Release, `BT_MP_FORCE_DMG`, 2026-07-25, several runs): both
nodes converge exactly. Final run -- owner 3:1 (kills 1, `tally=1`) read `kills=1 deaths=1` on the
peer, and owner 2:1 (kills 1, `tally=1`) read `kills=1 deaths=1` on the peer; an earlier longer run
converged at 3 kills/2 deaths and 2 kills/3 deaths. Respawn unaffected (3 cycles per side, `deaths=`
sequences intact -- the handshake `deathCount` is only ever overwritten on a replicant copy, and the
handshake itself runs on masters). `NOCREDIT` empty on both nodes (no silently skipped credit) and
`PLAYER_LINK ... inst=R ... resolved=1`, which retires the "NULL playerLink" hypothesis outright.
No crash, no `GLITCH` rows.
**What we did NOT change (kept byte-faithful).** The kill handler's partner increment
`++sender_owner->killCount` (btplayer.cpp, the binary's `inc [ebx+0x27c]` / `inc [edx+0x27c]`