Decide geometric would-have-hit error signal #163

New Issue

2026-09-13T20:28:02+02:00

SirStone commented

2026-09-13 20:28:02 +02:00

Question

How should the "would-have-hit" geometric error signal work?

The idea: instead of firing and waiting for hit/miss (sparse binary reward), compute where a hypothetical bullet would arrive and compare to where the enemy actually was at that future tick.

Decisions needed:

Ring buffer size for enemy position history (how many ticks to record?)
At evaluation time: compute bullet travel time from current distance, look ahead that many ticks in the position buffer, measure angular error between aim angle and actual enemy position at impact time
How to handle the delay: the position buffer needs FUTURE positions that haven't happened yet — do we evaluate N ticks late (after recording the future), or predict forward from velocity?
Does this replace the current instantaneous error signal, or augment it?

## Question How should the "would-have-hit" geometric error signal work? The idea: instead of firing and waiting for hit/miss (sparse binary reward), compute where a hypothetical bullet would arrive and compare to where the enemy actually was at that future tick. Decisions needed: - Ring buffer size for enemy position history (how many ticks to record?) - At evaluation time: compute bullet travel time from current distance, look ahead that many ticks in the position buffer, measure angular error between aim angle and actual enemy position at impact time - How to handle the delay: the position buffer needs FUTURE positions that haven't happened yet — do we evaluate N ticks late (after recording the future), or predict forward from velocity? - Does this replace the current instantaneous error signal, or augment it?

SirStone added the wayfinder:grilling label 2026-09-13 20:28:02 +02:00

SirStone commented

2026-09-13 20:28:08 +02:00

Blocked by: #160 (Research bullet mechanics — need bullet speed for travel time computation)

**Blocked by:** #160 (Research bullet mechanics — need bullet speed for travel time computation)

SirStone referenced this issue

2026-09-13 20:28:09 +02:00

SNNBot: lead-predicted aiming against moving targets #159

SirStone commented

2026-09-13 21:21:28 +02:00

Resolution

Retroactive would-have-hit error signal using a ring buffer of actual enemy positions.

Design

Decision	Answer
Error method	Retroactive — record actual enemy positions, evaluate against where enemy really was at hypothetical bullet impact time
Replace/augment	Replace — lead-angle error is the only target signal, replaces instantaneous bearing error
Firepower	Fixed (matching actual fire command) — gives known bullet speed for travel time computation
Evaluation timing	Window end — compute at end of 10-tick inference window using freshest state
Ring buffer size	100 ticks — covers max engagement range (~71 tick worst case) with margin
Learning delay handling	Delayed target only — SuperSpike updates every window as before, but targetAngle comes from the most recently matured retroactive entry instead of current bearing. No queued traces or membrane snapshots needed.
Buffer bootstrap	Skip learning until first entry matures (~71 ticks max). No fallback to instantaneous or predictive error — let the buffer fill, then start clean.

How it works

Each tick, record enemy (x, y) in a 100-slot ring buffer
Each tick, also record the SNN's aim decision (output angle) and the distance to enemy
At each inference window end, check if any past aim snapshot has 'matured' (tick_now >= tick_recorded + distance/bulletSpeed)
If matured: compute actual bearing to enemy at the impact tick from the ring buffer, compare with the recorded aim angle → that's the SuperSpike error signal
If no matured entry yet (early game): skip weight update entirely

## Resolution **Retroactive would-have-hit error signal using a ring buffer of actual enemy positions.** ### Design | Decision | Answer | |----------|--------| | Error method | Retroactive — record actual enemy positions, evaluate against where enemy really was at hypothetical bullet impact time | | Replace/augment | Replace — lead-angle error is the only target signal, replaces instantaneous bearing error | | Firepower | Fixed (matching actual fire command) — gives known bullet speed for travel time computation | | Evaluation timing | Window end — compute at end of 10-tick inference window using freshest state | | Ring buffer size | 100 ticks — covers max engagement range (~71 tick worst case) with margin | | Learning delay handling | Delayed target only — SuperSpike updates every window as before, but targetAngle comes from the most recently matured retroactive entry instead of current bearing. No queued traces or membrane snapshots needed. | | Buffer bootstrap | Skip learning until first entry matures (~71 ticks max). No fallback to instantaneous or predictive error — let the buffer fill, then start clean. | ### How it works 1. Each tick, record enemy (x, y) in a 100-slot ring buffer 2. Each tick, also record the SNN's aim decision (output angle) and the distance to enemy 3. At each inference window end, check if any past aim snapshot has 'matured' (tick_now >= tick_recorded + distance/bulletSpeed) 4. If matured: compute actual bearing to enemy at the impact tick from the ring buffer, compare with the recorded aim angle → that's the SuperSpike error signal 5. If no matured entry yet (early game): skip weight update entirely

SirStone closed this issue

2026-09-13 21:21:28 +02:00

SirStone referenced this issue

2026-09-13 21:21:39 +02:00

SNNBot: lead-predicted aiming against moving targets #159

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: SirStone/SirRoboGarage#163