SirStone/SirRoboGarage
1
0
Fork 0
Code Issues 28 Pull Requests Actions Projects Releases Wiki Activity
378 Commits 5 Branches 0 Tags
8dd9b3b3b5f81f5bbcd06ca9f1cfb118dbbc57dd
Commit Graph

3 Commits

Author SHA1 Message Date
SirStone 1ea84f5b6e STRAFE: draw the heat field, real bullet danger, corrected ring comment 
Three defects the owner hit as "no heat tiles anymore" under TR_MOVEMENT=strafe.

1. The strafe overlay drew ONLY the tiles on its strafe line, so the computed
   heat field was essentially invisible. It now draws the WHOLE field exactly as
   TFIL does (every non-zero tile, yellow->orange->red ramp by field max, integer
   value label) behind the same debugGraphics flag, with TR_STRAFE_HEAT_GRID=0 to
   hide it. The strafe overlays draw on top, unchanged.

2. STRAFE carried the SHIPPED bullet constants (core 10 / aura 5), so a bullet's
   own heat sat exactly ON PathDangerThreshold (10.0) and a bullet was never
   dangerous on its own in this mover; it only ever bit through its corridor.
   Defaults are now the retune's 20/10, exposed as TR_STRAFE_BULLET_CORE /
   TR_STRAFE_BULLET_AURA.

3. The ring mover's header documented CorridorHeat 5.0 / WallHotness 10.0 while
   the code has always been 10.0 / 15.0. A job read the comment and handed out
   sub-threshold heat values, which emptied the field. The comment now states the
   real values and their actual behaviour; no code values changed.

Also sets strafe's heat defaults to the retune shape (bullet 20/10, corridor 10,
wall 15/5, pillar 0), documented with the reason.

Gate A re-run (j110, offline DrussGT fixture, measure_strafe_gates.nim):
  corrected DEFAULT : 24.6% of picks with ZERO safe tile, mean 11.17 safe
  j108 shipped field: 63.4% / 3.70   (reproduced exactly)
  j108 ring retune  :  8.1% / 18.41  (reproduced exactly)
  bullet isolated   : 11.4% / 17.07
The corrected default beats the shipped field but is WORSE than j108's retune
row: the bullet retune alone costs 8.1 -> 11.4, the corridor/wall retune accounts
for the rest. That is the deliberate price of making a bullet dangerous.

Guards green: test_env_report 24 PASS, test_tfil_commit_env 30 PASS (shipped TFIL
default untouched, byte-for-byte), test_tfil_ring_weights 24 PASS. The three new
knobs are registered in the boot env report so the tree-scan guard stays clean.
 2026-09-25 23:25:34 +02:00
SirStone 7f6ccfb015 Ring mover heat retune (author: the user) - dodge bullets, ignore walls/centre, 
re-plan 3x more often

Uncommitted working-tree change in `the_floor_is_lava_ring.nim`, confirmed by the
user as theirs. Committing it so it stops appearing in every job's `git status`.

WHAT IT DOES - a coherent "be far more afraid of bullets" strategy:
- BULLETS 2x hotter: BulletCore 10 -> 20, BulletAura 5 -> 10.
- Walls weaker and thinner: WallRadiance 10 -> 5; the `WallHotness` default
  10 -> 15 (so the heat falls off over ~3 tiles instead of 1, with a higher peak).
- CENTRE PILLAR DISABLED: PillarHotness 30 -> 0, PillarRadiance 10 -> 0, so the
  bot may now use the middle of the arena instead of treating it as a no-go zone.
- MUCH more reactive: CommitTicks 15 -> 5 and MinCommitTicks 5 -> 0, i.e. the
  dodge target is re-chosen 3x more often and a replan is allowed immediately.
- `CorridorHeat` default 5 -> 10.

This applies ONLY to the ring mover, which is NOT the shipped movement (the default
is `tfil`), so the shipped bot is unaffected.

TWO FACTS RECORDED, not objections - it is the user's call:
1. `CorridorHeat = 10` now EQUALS `PathDangerThreshold = 10`. The earlier measured
   taming set it to 5 precisely so a single corridor could no longer poison a path
   on its own (a corridor at 10 puts every tile along it at/over the threshold).
   That is part of what lifted the "band-weightable" fraction from 10.8% to 26.5%.
   At 10 the range weighting gets less to work with.
2. UNMEASURED: this retune has not been A/B'd. The ring mover it modifies was
   itself measured as a glass cannon (best offline hit rate, but round wins
   16/49 -> 6/49, p=0.012). The two changes push in the same direction - hotter
   bullets and more frequent replanning mean MORE dodging and LESS time spent
   closing to the 100-200px band where our hit rate peaks (27% vs 5% at 450px).
   Worth an A/B before drawing conclusions, but it is an experiment, not a
   shipped change.
 2026-09-23 00:30:52 +02:00
SirStone 9caf1d3728 movement: range-weighted TFIL variant + tamed heat field (opt-in, default unchanged) 
New mover `the_floor_is_lava_ring.nim`, a COPY of `the_floor_is_lava.nim` (which
stays byte-identical - the user explicitly wants the current TFIL preserved).
Selected only via `TR_MOVEMENT=tfil_ring`; the default stays `tfil`.

WHY: our measured real hit rate vs DrussGT is strongly range-dependent - 21.6%
at 0-100px, 27.1% at 100-200px, 19.3% at 200-300, 10.9% at 300-400, 6.8% at
400-600, 5.4% at 600-800 - but we shoot from ~450px on average. Plain TFIL has
no range preference at all.

THE ONE CHANGE: the final tile draw is re-weighted toward a target band.
  rangeW(d) = 1.0 if lo<=d<=hi; exp(-((lo-d)/K)^2) if d<lo; exp(-((d-hi)/K)^2) if d>hi
  w_i = rangeW(d_i)^(1/T);  chosen ~ Categorical(w)
FLAT TOP on purpose: a Gaussian centred on the band midpoint would collapse the
band to a point and destroy the within-band hedge. `T` is the only knob;
`TR_TFIL_RANGE_TEMP=0` gives plain `rand(candidates.high)` - the exact control
arm. Safety stays a HARD constraint: the weighting only reorders the draw among
the pool the old code already accepted, so it can never pick a tile the old code
rejected (monotone refinement). Small pools (<4) stay uniform.
Randomness is deliberately KEPT: a measured A/B showed committing to the "best"
tile made real hit rate WORSE (7.02% -> 5.10%), so the distribution is tilted,
never removed.

HEAT TAMING (ring copy only; env-overridable):
  TR_TFIL_CORRIDOR_HEAT  20.0 -> 5.0
  TR_TFIL_WALL_HOTNESS   30.0 -> 10.0
Rationale, measured: `CorridorHeat=20` is TWICE `PathDangerThreshold=10`, so a
single corridor could poison a path by itself; `WallHotness=30` with
`WallRadiance=10` put the outer two tile rings over threshold on their own.
Per-source shares of total lava: wall 60.6%, corridor 25.4%, pillar 7.4%,
everything else <3%.

MEASURED EFFECT (primary fixture, 20,026 ticks / 15 rounds, field identity
verified max diff 0.000e+00):
  metric                        original(20/30)   ring(5/10)
  band-weightable ticks              10.79%         26.45%
  mean safeTiles/tick                 15.19          85.04
  ticks with 0 safe (pre-fallback)    58.5%           7.5%
  safePool >= 4                       39.05%         92.47%
  >=1 safe tile in 100-200px          11.84%         26.64%
  MEAN CLOSEST-SAFE-TILE DISTANCE    397.78px       284.84px
  tiles > 10 threshold                 0.61           0.15
The 397.78px figure is why the bot stayed far away: the safety filter left
nothing safe near the target, and 397px is our WORST range. Control: setting
corridor=20 wall=30 reproduces the original baseline exactly.
CEILING, honestly: even at corridor 0 / wall 0 only ~40% of ticks are
band-weightable, so no constant tweak fully unlocks the range weighting.

Ram unification: the ring mover takes a `band` field; ramming becomes just
`band=(0,50)`, so there is one movement engine. The `tfil` path is unchanged.

Observability: magenta annulus at the band edges, candidates tinted by weight,
chosen tile marked; one `[tfil_ring]` log line on change (now including
corridorHeat/wallHotness).

Guards: test_tfil_ring_weights 24/24 (new, pure, no battle), test_gun_harness 39,
test_vbullet_metric 11, test_power_selection 3, test_adaptive_radar 41.
UNVERIFIED: the mover's live effect. It has not been run in a battle yet.
 2026-09-21 23:46:47 +02:00