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

re: correct a mislabelled blocker -- the world unit needs a run, not a waiver

Browse Source 
I wrote "blocked on the oracle" for the unit-to-metre conversion.  That was a
mislabel: red is for what the container cannot do, and run-canary works here.
What the km-name sweep actually established is narrower -- no STATIC test can
settle it, because the disc has exactly one size-bearing asset name.

The run is well-supported by tooling that already exists: findplayer.py
recovers the player position triple from motion, the HUD prints the distance to
the selected target in the game own units, and the same separation read both
ways is the conversion.  Recorded as amber with the experiment written out.
This commit is contained in:
Sylpheed RE agent
2026-08-26 10:07:01 +00:00
parent 0a64728fae
commit 76a998eed4
2 changed files with 28 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

23
docs/re/structures/collisionset.md
View File

@@ -128,9 +128,26 @@ My objection's own premise did survive its check: `rou_e010` is a real
trailing `_S` means "small" is a further guess — there are `_EX4`, `_HF` and
`_HF_Wayne` variants of the same unit — so it is suggestive, not evidence.)
🔴 **Blocked on the oracle.** An independent scale reference — the flight model's
speed values against a measured traversal time in the running game — is the only
route left, and it needs an emulator run rather than the disc.
🟡 **Not blocked — just not run yet.** An earlier version of this line said
"🔴 blocked on the oracle", and that was a mislabel. 🔴 is for what the container
*cannot* do; `run-canary` works here, and measuring the game is what it is for.
What the sweep above actually established is narrower and worth keeping: **no
*static* test can settle this**, because the disc contains exactly one
size-bearing asset name.
The experiment is well-supported by tooling that already exists:
1. `findplayer.py` recovers the player craft's live position triple from guest
RAM by its motion, so a mission run yields positions in world units.
2. The HUD prints a **distance to the selected target** in the game's own units
of measure.
3. The same separation read both ways — Euclidean distance between the two
position triples, against the number the HUD displays — is the conversion,
measured rather than inferred from a filename.
`pad.py` scripts the target-select input (Ⓐ pressed **twice**, per `AGENT.md`),
and `screenshot` crops to the game surface. Nothing here needs anything the box
lacks. It is the next run.
Reproduce with `tools/re-capture/collisionset.py verify` / `list`
([`../data/collisionset.txt`](../data/collisionset.txt)); `collisionset.py obj`