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

docs/re: restate the ship item's blocker as the crash, not navigation

Browse Source 
Navigation is solved and scripted as far as the save-slot screen; what stops the
second capital-ship capture is the cache-flush crash firing at SELECT DATA. The
backlog entry now says that, so the next person does not re-solve navigation.
This commit is contained in:
Sylpheed RE agent
2026-08-19 04:01:09 +00:00
parent 72b0e23e3b
commit 10b89c77a3
1 changed files with 10 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
docs/re/BACKLOG.md
View File

@@ -598,9 +598,13 @@ in `command_processor.cc` on `auto/re-ui-draw-order`, and F10 wrote a 2.9 MB
`xenia_ship_capture_01.log` from this session's binary. No separate
`capture-ship-placement` build is needed.
What blocks it now is **navigation**: a mission is behind the main menu, and Ⓐ at
the title is accepted on roughly half of boots with nothing observable predicting
which ([`canary-scripted-input-traps.md`](canary-scripted-input-traps.md)).
`tools/re-capture/tutorial_launch.sh` therefore retries whole boots rather than
re-pressing — re-pressing the same title never works — and drives menu → TUTORIAL
from there.
What blocks it now is **the cache-flush crash**, not navigation — measured
2026-08-19. `tools/re-capture/tutorial_launch.sh` (which retries whole boots,
because re-pressing the same title never works) gets all the way from the title
through the main menu to **DIFFICULTY** and then **SELECT DATA**, and the guest
dies there at `0x82307128` — the same `std::map`/`set` erase as the boot-time
throw, 537 stacked dumps, with `--mem_watch=false`. See
[`title-crash-stl-tree.md`](title-crash-stl-tree.md).
So a second capital-ship capture needs that crash dealt with first. Everything up
to the save-slot screen is now scripted and works.