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

backlog: the world-unit blocker was the ROUTE, not entities2.py's VA window

Browse Source 
The entry blamed a stale committed VA window for "0 unit definitions".  Measured
2026-08-26: the scan works and returns 13 definitions + 42 named live instances
once the run reaches the mission via LOAD GAME -> slot 01 rather than via MISSION
SELECT.  What still blocks the measurement itself is narrower and now stated: the
flight HUD was not up (green 0.03% vs 1.3-1.5%), so there was no distance readout
to compare positions against.
This commit is contained in:
Sylpheed RE agent
2026-08-26 20:47:43 +00:00
parent 1f17726526
commit 06f4dec741
1 changed files with 17 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
docs/re/BACKLOG.md
View File

@@ -86,11 +86,23 @@ See [`mission-freeze-heap-exhaustion.md`](mission-freeze-heap-exhaustion.md).
between tool calls.** Sequential tool calls *within* one turn are fine; it is
ending the turn that kills it.
❔ **The world-unit measurement is still not made.** Flight was reached and the
screen classifier agrees, but `entities2.py self` reports **0 unit definitions** —
its committed VA window `0xBD00_0000`–`0xBE00_0000` does not match this run, the
same run-dependent-address problem this file documents for the OB counter. The
next attempt must hunt the range rather than trust the stored config.
❔ **The world-unit measurement is still not made** — but the blocker under it is
now GONE. The entity scan works: see
[`entities-live-roster.md`](entities-live-roster.md), **13 unit definitions and 42
named live instances** with 52 moving triples, on 2026-08-26.
The old note here blamed `entities2.py`'s committed VA window. That was the wrong
suspect: ✅ the real cause was the **navigation route**. Runs that reach a mission
through `MISSION SELECT` scan 0/0; the route that populates the world is
`launch_mission.sh`'s **title → LOAD GAME → slot 01 → YES → READY ROOM → TAKE
OFF**, which is what `structures/unit-struct-runtime.md` used when the constants
were first derived.
What remains for the measurement itself: this run reached the mission but the
flight **HUD was not yet up** (green 0.03 %, against 1.3–1.5 % in flight), so
there was no on-screen distance readout to compare world-unit positions against.
Next attempt: get to a live HUD, then read a target's position triple and the
HUD's own distance to it.
---