SirStone
ab86c0481f
Audited all 14 guns offline over the committed DrussGT fixtures (~150k resolved bullets/gun) plus 123 rounds of live gun_stats. Prompted by a GUI observation that selected guns "fire dozens of pixels away" and a suspicion of reverse selection. MY HYPOTHESIS WAS WRONG. I expected guns to be ignoring `bulletSpeed`, which would make their 4 power bins identical and the per-bin fitness pure noise. MEASURED: only `HeadOn` is speed-blind (100% identical bins) and that is its correct definition. Every other gun emits 91-94% DISTINCT per-bin predictions (mean intra-tick bin spread 62-103px). The earlier "tick-only cache collapsed all bins onto bin 0" fix is complete across the whole rack. LEAD/SIGN/UNITS ARE CORRECT: replaying synthetic ground truth, all 14 guns score 100% on a stationary target (which also proves predictions are ABSOLUTE - a relative or angle return would score 0), ~100% on constant-velocity for every leaded gun, Circular 100% / Accel 99.8% on a 3deg/tick circle, WallBounce 98.2% on a bounce. No missing lead, no sign inversion. Resolution is right (BotRadius 18, hit credited to the owning gun). FEEDBACK IS INTACT: offline pushes=151260/starved=0, Tsetlin trained=149205/ traceMisses=0; live `vStarved=0` and `vDropped=0` across all 123 rounds. THE "43% FLAT / 4x OPTIMISTIC" EVIDENCE I CITED IS NOT REPRODUCIBLE on current code/data. Live virtual/real ratios against DrussGT are 0.8-2.0 for most guns (Linear 10.9 virt / 13.4 real; KNN 8.1/7.1; DecayGF 10.5/9.8). The 43%-flat session matches an older config or a weak opponent (SittingDuck), not DrussGT. `bmPath` IS 2.3-3.6x `bmPoint` - but by design and documented: it asks "does the ray eventually sweep the target's path", a deliberately generous relative signal. So the flat tie is a RANKING artefact: many guns share the same base forecast and, with a near-zero learned correction, collapse onto the same ray; RelTieMargin=0.20 then treats the top ~half of the rack as tied. DUTY AND OVERLAP (>=50% of ticks within 20px = redundant): Tsetlin ~ StopShot 87% -> duplicate pair DecayGF ~ GuessFactor 92% -> duplicate pair Accel ~ Circular 65% -> partial duplicate WallBounce~ Linear 58% AvgLead = the MEAN of Linear+Circular+WallBounce (constructed redundancy) Displace worst point% (6.6) AND worst real% (2.4); wins no bucket TMSelect DEAD - never spawned (EnableTmSelector=false), 0 shots in every log Pattern the ONLY gun competitive in every distance/speed bucket HeadOn/Linear/Tsetlin/StopShot are identical copies of each other on a real surfer (v<1 ~50.8%, everything else ~2%) RECOMMENDED LEAN RACK (8): HeadOn, Linear, Circular, Accel, Pattern, GuessFactor, KNN, WallBounce. DROP (6): TMSelect (dead), AvgLead (constructed mean), Displace (worst), DecayGF (92% GF), StopShot (87% Tsetlin), Tsetlin (the repo's own sweep already showed it learns nothing on DrussGT). HONEST HEADLINE: pruning is NOT expected to raise hit rate - an earlier 15-paired-run experiment found it neutral-to-negative (p=0.57/0.21). The mechanism by which it could help is a SELECTOR effect (shrinking the tied band), not a gun effect, and that is UNVERIFIED until A/B'd. The virtual system and the rack are basically sound; the lever that matters most is the selector's metric/tie-band, not deleting guns. DESIGN SMELL FOUND (INFERRED, not measured): GF/DecayGF/KNN `onResult` pops the OLDEST wave, but under bmPath bullets leave the arena in non-FIFO order, so a resolution can be paired with a neighbouring tick's wave. starved=0 does not rule this out. Candidate fix: key waves by fireTick, as Tsetlin/TMSelect do. Adds common_libs/tests/audit_virtual_guns.nim (offline, no shipped file touched).