fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

docs: revise the OB-flag item - the blocker is the pilot's trigger, not the freeze

Browse Source 
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE
This commit is contained in:
Sylpheed RE agent
2026-08-23 21:05:27 +00:00
parent 7881d4a93b
commit 1877160990
1 changed files with 18 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
docs/re/BACKLOG.md
View File

@@ -266,9 +266,17 @@ is what the autopilot needs in order to CHOOSE a target. One run in:
* 🔴 **Not a live class head-count.** Counter 4 against 8 attackers / 7 friendly
Delta Sabers / 7 turrets / 1 player — no class matches, no pair sums to it.
* ❔ **20 candidate per-entity flag offsets** exist (offsets where exactly 4 of
23 entities share a value) and have **never been put to the second test**,
because the guest froze before the counter could move.
* ❔ **11 candidate per-entity flag offsets** on a proper 161-entity sample
(2026-08-23, later) — still **never put to the second test**, and two of the
groups look wrong on inspection (seven consecutive floats shared by 12 of 32
attackers read like a shared AI parameter block; `+0x0238 = 4` is shared by
twelve *turrets*).
* 🔴 **The counter is not "hostiles left" either.** It held at `012` for fifteen
minutes of **live** flight while the ADAN population fell 132 → 93. That is
also why there is still no verification: no transition to filter on.
* 🔴 **`pilot.py` never fires** — `fire=1` in 0 of 13 521 samples. Every
kill-based experiment in the corpus is leaning on the wingmen without saying
so. Fixing it would give the counter something to react to.
* 🔴 **An in-mission freeze — the item in front of everything else.** Reproduced
with the Kernel channel on. 🔴 The resume-spin lead is **refuted by its own
control**: a still-flying run has *more* refused resumes (2 738) than a frozen
@@ -283,11 +291,13 @@ is what the autopilot needs in order to CHOOSE a target. One run in:
`ob_flag.py` abort on it. **Roughly two runs in three.**
See [`mission-freeze-resume-spin.md`](mission-freeze-resume-spin.md).
**First step:** re-run `ob_flag.py` on a run that is advancing — it aborts early
now if it is not. ⚠️ Attempted again 2026-08-23 and **blocked twice**: one run
froze before the counter could move, and the next put the counter at a different
address (`0xbdb59668` held a float there — the tool refused to run, correctly)
and then froze too. The freeze item above is now the prerequisite. Second step, if that comes back empty: `entities2.typed` only
**First step, revised:** make `pilot.py` shoot, then re-run `ob_flag.py`. The
freeze is no longer the blocker it looked like — a 25-minute run stayed
animating — and the actual obstacle is that nothing the pilot does moves the
counter, so there is never a second sample. If the counter still will not move
when the player is killing things, the next question is what *does* move it, and
the objective card's own wording ("shoot down all invading enemy fighters") is
the place to start. Second step, if that comes back empty: `entities2.typed` only
sees entities whose position *changes*, so a stationary objective is invisible to
it, and the enumeration itself would need widening before a null result means
anything.