fabi/Syplheed-Reborn
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

re: add a hunting pilot; withdraw the "10 of 116 records are dynamic" result

Browse Source 
The user asked for an actively hunting pilot, since a player who kills nothing
cannot trigger an event-gated wave and both previous runs used the survival
pilot.

pilot.py gains SYLPH_HUNT=1. The substantive change is which contacts ENGAGE may
shoot: it previously skipped every "hard" target -- "turrets and hulls are not
the objective" -- and stood off 2500 units from turrets, on the assumption that
an e007 Turret is an AA mount on a capital ship. It is a craft, one of the main
enemy types of the first six missions, and at 100 HP the cheapest kill on the
field. Under SYLPH_HUNT it is a target and the keep-out drops to 600. The run
confirms the pilot engages: steady ENGAGE, fire=1, committed to an
e010_ADAN_Attacker_S at ~2.2 km, hull and escorted asset untouched over 160 s.

Withdrawn: "only 10 of 116 records ever changed a byte in 170 s". This run
measured 41-56 records changing in every 10 s tick. The old figure does not
reproduce.

I cannot say why, because I changed two variables at once -- the record bound
(fixed 0x200 to bounded-by-next-record) and the pilot (survival to hunting).
Either explains it. That is a design error, and the honest outcome is a
retraction without a replacement explanation rather than a story that fits.
The conclusion it had supported is unaffected: the roster identity now rests on
the exact 10-of-10 unit-composition match measured independently.

Still open, and explicitly not concluded: the pilot's own entity scan shows ADAN
drifting 147 -> 129 -> 142, and the late rise has the shape of an arrival, but
the sample-to-sample swing is +/-10, the same size as the effect. AGENT.md warns
that polling faster than the guest updates manufactures a curve out of noise, so
no wave conclusion is drawn. The run probably did not kill anything either
(fc=0, asset at 100%), so it does not test the event-gated model. A stable
per-record liveness field and a working kill counter are both needed first;
REMAINING OB at 0xbdb59668 still does not read as a counter.
This commit is contained in:
Sylpheed RE agent
2026-08-24 12:45:43 +00:00
parent 2030324419
commit 08352d09ac
5 changed files with 167 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
docs/re/BACKLOG.md
View File

@@ -332,8 +332,11 @@ search cannot find a *schedule*.
moves in one and not the other.
* 🔴 **Diffing inside the 116 records did not find the arrival flag**
(2026-08-24, same doc). 10 of 116 records are dynamic, 106 never change a byte
in 170 s — more support for the pre-allocated roster — and STRONGER than
first written: the "turrets don't move" hedge was withdrawn after the user
in 170 s — 🔴 **the "10 of 116 dynamic" figure is WITHDRAWN** — a hunting
run measured 41–56 records changing per tick; I had changed two variables at
once (record bound and pilot) so the discrepancy is unattributed. The roster
identity is unaffected: it now rests on the 10/10 unit-composition match.
Earlier note, kept for history: the "turrets don't move" hedge was withdrawn after the user
pointed out that early-mission "Turret" is a craft type, which the data
confirms (`UN_e007_ADAN_Turret` flies under `AI_ADAN_CraftSquadron_*`, never
`AI_Structure`). Lesson: check a unit's `AIID`, not its English name. No field transitions in groups of 3 at the

73
docs/re/mission-wave-arrivals.md
View File

@@ -313,3 +313,76 @@ records it recurring in about 5 runs of 7), and this was one of the misses, so
the run cannot say whether the pilot killed anything. Re-hunting the counter
with `ob_hunt.py` is a precondition for the kill-versus-no-kill test, not an
optional extra.
---
# Hunting run (2026-08-24) — and a withdrawal
Status: ✅ a hunting pilot exists and engages; 🔴 the "10 of 116 records are
dynamic" result is **withdrawn**; ❔ the wave question is still open, and the
entity scan is too noisy to settle it.
The user asked for an actively hunting pilot, with attention to the objectives,
because the two previous runs used the *survival* pilot and a player who kills
nothing cannot trigger an event-gated wave.
## ✅ `SYLPH_HUNT=1`
`pilot.py` gained a hunt mode. The change that matters is which contacts ENGAGE
is allowed to shoot: it previously skipped every "hard" target with the comment
*"turrets and hulls are not the objective"*, and kept 2500 units away from
turrets. That was written on the assumption that an `e007` "Turret" is an
anti-aircraft mount on a capital ship. It is not — it is a craft, one of the main
enemy types of the first six missions
(`AI_ADAN_CraftSquadron_*`, `Type = Squad`), and at 100 HP the cheapest kill on
the field. Under `SYLPH_HUNT=1` turrets are targets and the keep-out drops to
600.
The run confirms it flies and shoots: steady `ENGAGE`, `fire=1`, committed to
`e010_ADAN_Attacker_S` at ~2.2 km, hull 1500/1500 and escorted asset at 100 %
throughout 160 s.
## 🔴 Withdrawn: "only 10 of 116 records are dynamic"
The previous section reported that 10 of 116 records ever changed a byte in
170 s, and used it as supporting evidence for the pre-allocated roster. **This
run measured 41–56 records changing in every single 10 s tick.** The earlier
figure does not reproduce and is withdrawn.
I cannot say why, because I changed two things at once — the record bound (fixed
`0x200` → bounded by the next record's address, capped at `0x400`) *and* the
pilot (survival → hunting). Either could explain it: the old window mis-framed
every record whose true size is not `0x200`, and a hunting pilot flies into
traffic that an evading one avoids. **That is a design error on my part**: a run
that changes two variables cannot attribute its own result, and the honest
outcome is that the old number is retracted without a replacement explanation.
The conclusion the retracted number was supporting is unaffected — the
roster identity now rests on the exact 10-of-10 unit-composition match, which is
far stronger evidence and was measured independently.
## ❔ The entity scan is too noisy to answer the wave question
`pilot.py`'s own scanner reports a live entity count each tick. Over the run:
```
t=0s 168 (147 ADAN) t=56s 147 (131) t=101s 145 (129)
t=20s 171 (147) t=76s 155 (131) t=137s 151 (129)
t=30s 148 (132) t=86s 147 (131) t=157s 166 (142)
```
ADAN drifts 147 → 129 and back to 142. The late rise is the shape an arrival
would have, but the sample-to-sample swing is ±10 or more, which is the same
size as the effect. This is exactly the trap `docker/agent/AGENT.md` warns about
— polling faster than the guest updates manufactures a curve out of noise — so
**no wave conclusion is drawn from it.**
Two things are needed before this run type can settle the question:
1. A *stable* liveness signal — a per-record field that means alive/dead, read
from the 116 labelled records, rather than a re-scan whose population changes
between samples.
2. A kill count. `fc=0` in the pilot's telemetry and the asset at 100 % suggest
the hunt did not actually destroy anything in 160 s, in which case this run
does not test the event-gated model either. `REMAINING OB` at `0xbdb59668`
still did not read as a counter, so that check remains unavailable.