BT411

605 Commits 3 Branches 0 Tags

2 Commits

Include renames

Author SHA1 Message Date

Author	SHA1	Message	Date
arcattackandClaude Opus 5	a52207d779	#45 scoreboard: reclaim the binary's DEATHS field, add a heartbeat, sweep the false KB claims 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>	2026-07-25 22:09:00 -05:00
arcattackandClaude Opus 5	4fa7eee54f	K/D scoreboard ROOT-CAUSED for real (#45 ): the kill credit was rerouted, not lost Kills/deaths only ever appeared on ONE machine. The cause is not a missing tally -- it is Entity::Dispatch: if (GetInstance() == ReplicantInstance) // ENTITY.cpp:244-251 application->SendMessage(ownerID, EntityManagerClientID, message); BTPostKillScore runs on the VICTIM's node (the only node whose mech carries a populated lastInflictingID), resolves the killer's Player -- a REPLICANT there -- and Dispatch()es to it. The engine reroutes that to the owning host, so ++killCount lands on the killer's own PC and nowhere else, and nothing carried it back out: Player__UpdateRecord is currentScore + dropZoneLocation only. Every other pod's copy therefore read 0 all mission. playerLink was never NULL for these kills -- the dispatch proves it resolved. Field proof over the whole corpus (255 node-logs): 125 of 125 SCORE type=2 rows credit the LOGGING node's own player, not one credits a remote pilot; and 0 of 8800 DMG rows target a replicant, so no other node can even know the killer. This means the owner's counter is already the single authoritative copy, incremented exactly once per kill. So the "design decision" the plan was blocked on collapses: there is no second writer to reconcile, only a one-way owner->replicant mirror to add. * BTPlayer__UpdateRecord = Player::UpdateRecord + killTally + deathTally, with Read/WriteUpdateRecord overrides. No new data member, no new virtual -> sizeof(BTPlayer)==0x28c and every existing offset lock still holds. * Both counter writes already ForceUpdate() (:508 death, :829/:840 score), so no dirty-bit edit was needed (plan risk 6 avoided). * recordLength guard in ReadUpdateRecord: a pod on a build without the extension degrades to "remote counters don't move" instead of reading a neighbouring record as a kill count. * Size locks added per plan risk 2 (no false offsetof assert). Rig-verified, 2-node loopback (scratchpad/rig45_up.ps1, BT_MP_FORCE_DMG): owner 3:1 finished kills 3/deaths 2 and the peer read kills=3 deaths=2; owner 2:1 finished kills 2/deaths 3 and the peer read kills=2 deaths=3. Exact convergence where a remote column previously never left 0. 3 respawns per side with intact death sequences (deathCount is only overwritten on replicant copies; the handshake runs on masters), no crash, no GLITCH rows. Kept byte-faithful: the kill handler's partner increment (the binary's inc [ebx+0x27c] / inc [edx+0x27c] wrong-column slip) is still reproduced. It always lands on a replicant copy, so the owner's record now overwrites it -- the rig caught the correction repeatedly (wasKills=3 -> kills=2). The phantom kill stops being visible without silently deciding the fidelity question. Still open and deliberately untouched: which field the LOCAL pod's DEATHS column should read (+0x280 vs deathCount), last-hitter-takes-all/ram kills, and the slip's fidelity. Awaiting live multi-pod verification by a human. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 21:40:59 -05:00

arcattackandClaude Opus 5

a52207d779

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

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>

2026-07-25 22:09:00 -05:00

arcattackandClaude Opus 5

4fa7eee54f

K/D scoreboard ROOT-CAUSED for real (#45 ): the kill credit was rerouted, not lost

Kills/deaths only ever appeared on ONE machine.  The cause is not a missing
tally -- it is Entity::Dispatch:

    if (GetInstance() == ReplicantInstance)              // ENTITY.cpp:244-251
        application->SendMessage(ownerID, EntityManagerClientID, message);

BTPostKillScore runs on the VICTIM's node (the only node whose mech carries a
populated lastInflictingID), resolves the killer's Player -- a REPLICANT there --
and Dispatch()es to it.  The engine reroutes that to the owning host, so
++killCount lands on the killer's own PC and nowhere else, and nothing carried it
back out: Player__UpdateRecord is currentScore + dropZoneLocation only.  Every
other pod's copy therefore read 0 all mission.  playerLink was never NULL for
these kills -- the dispatch proves it resolved.

Field proof over the whole corpus (255 node-logs): 125 of 125 SCORE type=2 rows
credit the LOGGING node's own player, not one credits a remote pilot; and 0 of
8800 DMG rows target a replicant, so no other node can even know the killer.

This means the owner's counter is already the single authoritative copy,
incremented exactly once per kill.  So the "design decision" the plan was blocked
on collapses: there is no second writer to reconcile, only a one-way
owner->replicant mirror to add.

  * BTPlayer__UpdateRecord = Player::UpdateRecord + killTally + deathTally, with
    Read/WriteUpdateRecord overrides.  No new data member, no new virtual ->
    sizeof(BTPlayer)==0x28c and every existing offset lock still holds.
  * Both counter writes already ForceUpdate() (:508 death, :829/:840 score), so
    no dirty-bit edit was needed (plan risk 6 avoided).
  * recordLength guard in ReadUpdateRecord: a pod on a build without the
    extension degrades to "remote counters don't move" instead of reading a
    neighbouring record as a kill count.
  * Size locks added per plan risk 2 (no false offsetof assert).

Rig-verified, 2-node loopback (scratchpad/rig45_up.ps1, BT_MP_FORCE_DMG):
owner 3:1 finished kills 3/deaths 2 and the peer read kills=3 deaths=2; owner 2:1
finished kills 2/deaths 3 and the peer read kills=2 deaths=3.  Exact convergence
where a remote column previously never left 0.  3 respawns per side with intact
death sequences (deathCount is only overwritten on replicant copies; the
handshake runs on masters), no crash, no GLITCH rows.

Kept byte-faithful: the kill handler's partner increment (the binary's
inc [ebx+0x27c] / inc [edx+0x27c] wrong-column slip) is still reproduced.  It
always lands on a replicant copy, so the owner's record now overwrites it -- the
rig caught the correction repeatedly (wasKills=3 -> kills=2).  The phantom kill
stops being visible without silently deciding the fidelity question.

Still open and deliberately untouched: which field the LOCAL pod's DEATHS column
should read (+0x280 vs deathCount), last-hitter-takes-all/ram kills, and the
slip's fidelity.  Awaiting live multi-pod verification by a human.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-07-25 21:40:59 -05:00