The user spotted this from the game itself: the [config] line always said
gun=HeadOn while the in-game turret and bullet COLOURS varied. The colours are
set at the selection site, so they were truthful and the log was not.
MEASURED, one 2-round battle, same process:
[config] output : 6 lines, ALL gun=HeadOn
tracker selection : Displace 25.1%, HeadOn 20.8%, Pattern 15.5%,
KNN 14.1%, Tsetlin 6.3%, WallBounce 6.1%, ...
Root cause: printConfig did GunNames[bot.currentGun] but EVERY call site ran
before the tick's gun selection - onRoundStarted right after currentGun = 0
(so HeadOn by construction), and the target/radar-change prints. The selection
that sets currentGun is ~490 lines later in the same tick. radarMode and
currentTargetId ARE updated before those sites, which is exactly why the radar
and target columns looked plausible while the gun column did not.
WHERE IT CAME FROM: git history shows commit 2cc2a3b ('cleaner logging')
removed the original printConfig call at the selection site while leaving the
prevGun highlight logic in place. That removal is when the regression appeared -
before it, the bot logged on round start AND on gun switch.
FIX: one emission at the end of the tick, after selectShot has run, gated by a
cfgDirty flag set on gun switch / target change / radar change. The index is
guarded (currentGun may be -1), the round-start line omits the gun field rather
than inventing one, and the existing output contract is preserved (all white,
only changed fields green, enemies= and target= kept).
VERIFIED: before 6 lines all HeadOn; after 782 lines over 2118 ticks with 13
distinct guns and ZERO violations - no printed gun was one that had not been
selected. Counts differ from the selection totals because the log prints only
on change, which is the behaviour the user asked for.
Also removes the 'currentGun = 0' initialisation in onRoundStarted, keeping the
existing -1 sentinel so 'no gun chosen yet' is representable.
SirStone
ab35540035