SirStone
7f706e5b14
The entire GuessFactor family scored 0% on clean circular and wall-bounce trajectories. Two hypotheses were on the table and BOTH were wrong: - MEA range too narrow / edge clamping: REFUTED. Measured 0 clamped shots out of 837/849/957, required offsets peak at ~33 deg against MEA 28.1-46.7 deg, and the 8 in arcsin(8/bulletSpeed) is correct (it is the max robot SPEED, not the hit radius). Changing it to BotRadius=18 would have coarsened resolution for nothing. - Peak selection: REFUTED. A sweep of every constant GF value showed the ORACLE-BEST constant offset on the original gun was only 6% circular, 4% wall-bounce, 7.5% random-walk. No peak choice could have done better. The learning path was fine too: ~850-960 observations per fixture, 0 starved waves, well-populated histograms. REAL CAUSE: the GF family aimed at the FIRE-TIME distance. The virtual-bullet metric resolves a bullet at the AIM-POINT distance and scores that single point against the enemy's position on that tick, so with any radial target motion the bullet stops at the wrong radius and misses even with a perfect angle. Angle-only prediction is structurally unscoreable under this metric. FIX: give the GF family a self-consistent constant-velocity forecast as its base reference (new common_libs/guns/lead_forecast.nim, which iterates the flight time to the same fixed point circular.nim uses), so the histogram learns the RESIDUAL against that forecast and the aim point lands at the right radius. Applied to guess_factor, decay_gf and knn_gun. Same defect fixed in Linear: it did a one-shot dist/bulletSpeed extrapolation and never iterated its flight time. The oracle sweep proves the structural fix, independently of tuning: the best achievable constant GF moved 6% -> 20% (circular), 4% -> 57% (wall-bounce), 7.5% -> 49% (random-walk). MEASURED, all 15 fixtures: total 39.0% -> 44.4% (30399 -> 34654 hits). circular GF 6 -> 23, DecayGF 6 -> 21 wall-bounce GF 0 -> 60.2, DecayGF 0 -> 60.2 constant-vel GF 26 -> 100, DecayGF 26 -> 100, KNN 26 -> 100, Linear 87 -> 100 random-walk GF 0 -> 53, DecayGF 0 -> 52, Linear 24 -> 53 StraightLine GF 8 -> 77, DecayGF 8 -> 77 Non-regression: 33 guard checks pass, the range's 12/12 offline==online acceptance still PASSES, tsetlin tests green, live gauntlet 5/5. HONEST TRADE-OFF, recorded rather than hidden: on the 5 real DrussGT wave-surfing captures the GF family REGRESSES - GuessFactor 108 -> 55, DecayGF 108 -> 76, KNN 101 -> 74 hits per 2000. The linear base is a poor model for a surfer, so the residual histogram is noisier than the old total-lead histogram. Linear itself improved there (95 -> 105). The synthetic range and the live gauntlet both improved, and the structural bug is provably fixed, so this was judged worth the cost - but recovering the DrussGT regression is the next job, not something to wave away.
55 lines
2.7 KiB
Nim
55 lines
2.7 KiB
Nim
## Shared self-consistent constant-velocity forecast used by the Linear gun and
|
|
## the GuessFactor family (guess_factor, decay_gf, knn_gun).
|
|
##
|
|
## Why this exists: the virtual-bullet metric resolves a bullet when its travel
|
|
## distance reaches the distance to its aim point, then scores that single point
|
|
## against the enemy's position on that tick. A gun that places its aim point at
|
|
## the FIRE-time distance therefore stops at the wrong radius whenever the target
|
|
## has moved radially over the flight, and misses even when its angle is
|
|
## perfect. Measured symptoms:
|
|
## * the whole GF family scored ~0% on the circular/wall-bounce/random-walk
|
|
## fixtures while the model-fitting guns scored 40-100%;
|
|
## * the Linear gun scored 87% (p3.0 = 63/100) on the constant-velocity
|
|
## fixture where a self-consistent forecast scores 100%.
|
|
## The GF angle range was never clamped (0/837 shots), so the earlier
|
|
## "MEA too narrow" hypothesis was wrong.
|
|
##
|
|
## Fix: iterate the flight time until the predicted point sits at the distance
|
|
## the bullet actually travels (the same fixed point circular.nim uses). The GF
|
|
## family additionally measures its histogram as the residual of the actual
|
|
## bearing against this forecast's bearing, so it learns the deviation from a
|
|
## base model instead of having to encode the whole lead angle.
|
|
##
|
|
## Coordinate system: 0° = East, CCW positive (Tank Royale standard).
|
|
|
|
import std/math
|
|
import gun_harness/gun_interface
|
|
|
|
type
|
|
BaseForecast* = object
|
|
x*, y*: float ## absolute predicted enemy position
|
|
dist*: float ## distance from shooter to the predicted position
|
|
bearing*: float ## bearing from shooter to the predicted position (rad)
|
|
|
|
proc forecastLinear*(state: WorldState, bulletSpeed: float): BaseForecast =
|
|
## Constant-velocity forecast with self-consistent flight time. The enemy is
|
|
## assumed to keep its current heading/speed; the flight time is the fixed
|
|
## point t = |predictedPos(t) - self| / bulletSpeed (5 iterations, matching
|
|
## circular.nim). Enemy speed (< 8 px/tick) is always below bulletSpeed
|
|
## (>= 11), so the iteration contracts.
|
|
let d0 = hypot(state.enemyX - state.selfX, state.enemyY - state.selfY)
|
|
let hr = degToRad(state.enemyHeading)
|
|
let v = state.enemySpeed
|
|
var t = if bulletSpeed > 0.0: d0 / bulletSpeed else: 0.0
|
|
var ex = state.enemyX
|
|
var ey = state.enemyY
|
|
for _ in 0..4:
|
|
ex = state.enemyX + cos(hr) * v * t
|
|
ey = state.enemyY + sin(hr) * v * t
|
|
if bulletSpeed > 0.0:
|
|
t = hypot(ex - state.selfX, ey - state.selfY) / bulletSpeed
|
|
result.x = ex
|
|
result.y = ey
|
|
result.dist = hypot(ex - state.selfX, ey - state.selfY)
|
|
result.bearing = arctan2(ey - state.selfY, ex - state.selfX)
|