Completes 2772175/e82f54c. The interceptor restored the credit; this puts it
on the right node, so a player's score accumulates again.
The operator corrected two of my claims, and both were load-bearing:
1. Scores DID accumulate before build 787. Checked: build 774 already had
`currentScore = 0` in the console flush, so the flush was never eating
score. My "score zeroed every interval" theory is dropped. The watermark
from e82f54c stays only because it is harmless and keeps a master's own
total intact across a flush -- it was not fixing a field bug.
2. The reroute works, and 774's own comment says so: the killer's player is a
REPLICANT, so Entity::Dispatch reroutes to the owning host
(ENTITY.cpp:244-251) and the credit lands on the killer's OWN machine.
That is how kill credit has always crossed nodes.
So the earlier master-only gate was the right idea and failed for a reason I
guessed wrong. A rerouted message arrives over the WIRE through Receive(),
which goes straight to the handler table -- the virtual Dispatch override is
never called on the receiving side. Type 0 therefore landed in
ScoreMessageHandler's arm, which Verify-rejected it: award 0.00.
Fix is both halves:
* Dispatch intercepts on a MASTER only -- local delivery stays exactly as
@004bffa0 does it;
* ScoreMessageHandler's type-0 arm DELEGATES to ScoreInflictedMessageHandler
instead of Verify-rejecting -- wire delivery gets the same handler.
One accumulator, on the machine that owns the score.
Works for Steam today (no console tally exists -- btconsole.py/btoperator.py
handle no score at all) AND for a real operator console later: the console
flush is untouched and still ships authentic deltas under the owner's ownerID.
Benched (cross-node zone-walk kill):
credit node shooter's master only (victim's node banks 0)
running total 253.60 and CLIMBING, no resets
(was: peaks ~35, snapping back every few seconds)
type-0 rejects 0
LOOSE END: each real award is followed by a duplicate row with award=0.00
(80 real + 80 zero). Harmless -- the total is unaffected -- but it means the
report is delivered twice on the owner; not yet explained.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NCJQkvq6G2JNrpVbA75tVZ
