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

isl: built-in 104 is request_next -- named from the game's own log string

Browse Source 
Followed the writer, not the reader.  [phase+10160]'s only writer in
the image is one site in the mission frame loop sub_821AA1B0: it does
obj->get() on an object fetched from a registry by id 0x20FFFF02,
stores it to the phase, then clears the object -- read, publish, clear,
every frame.

The id namespace has exactly three members (0x20FFFF00/01/02), each
built at exactly 4 sites, and two of those are in sub_821D5178, which
gets 0x20FFFF01 and 0x20FFFF02 and logs both:

  GamePart_ReadyRoom::Impl::OnCommand - Wait() command is requested.
  Check flow control valiables. WAIT_MODE : %d, REQUEST_NEXT : %d

Argument order gives 0x20FFFF01 = WAIT_MODE, 0x20FFFF02 = REQUEST_NEXT.
PrepareScript corroborates: it sets WAIT_MODE=1, REQUEST_NEXT=0 before
an ISL script runs.  So the six tutorial stages' lone dominating
condition request_next() != 1 is the script waiting on the game part's
proceed flag.

6 artefact lines changed, all 6 pair exactly.
This commit is contained in:
Sylpheed RE agent
2026-08-27 09:31:01 +00:00
parent b86c8c82ba
commit af61c162f3
4 changed files with 83 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

29
docs/re/BACKLOG.md
View File

@@ -389,6 +389,35 @@ unknown, what evidence exists, and what the first step would be. Move an item in
the ring buffer at `bus+4` (capacity `+8`, head `+12`, count `+16`), not what
reads `bus+8216`. Whether running out of time ends the mission is unanswered.
* ✅ **(2026-08-27) BUILT-IN 104 IS NAMED — `request_next`, from the game's own
log string. [structures/isl-condition-builtins](structures/isl-condition-builtins.md).**
Built-in 104 returns `[phase+10160]`, whose **only writer in the image** is one
site in the mission frame loop `sub_821AA1B0`. Following that writer instead of
the reader: `r29` is `obj->slot2()` on an object fetched from the registry at
`[r30+2424]` by id **`0x20FFFF02`**, published to the phase, and then the same
object is `slot1(0)` — **read, publish, clear, every frame**.
🔑 **The id namespace has exactly three members** (`0x20FFFF00/01/02`), each
built at exactly 4 sites image-wide — a closed family, so this is not the
coincidence the last two iterations kept tripping on. Two of those sites are in
`sub_821D5178`, which gets **both** `0x20FFFF01` and `0x20FFFF02` and passes
their values to a log call whose format string (`0x820A4968`) is:
*"silph::GamePart_ReadyRoom::Impl::OnCommand - Wait() command is requested.
Check flow control valiables. **WAIT_MODE : %d, REQUEST_NEXT : %d**"*.
Argument order settles it — `r4` (first `%d`) is `0x20FFFF01` = **WAIT_MODE**,
`r5` is `0x20FFFF02` = **REQUEST_NEXT**. ⇒ **`[phase+10160]` is REQUEST_NEXT**
and built-in 104 is **`request_next`**. Corroborated by
`PrepareScript`, which sets `WAIT_MODE = 1` and `REQUEST_NEXT = 0` before an ISL
script runs. So the six tutorial stages' single dominating condition
`request_next() != 1` is the script waiting on the surrounding game part's
*proceed* flag. ⚠️ Three other hits on offset 10160 are `lfs` on unrelated
objects — the recurring-offset trap, excluded.
✅ Renamed in `isl.py`; **6 artefact lines changed and all 6 pair exactly.**
🟡 Not settled: what the `(16, 32]` gate on `[r30+104]`'s `+12` selects; the
third id `0x20FFFF00` (used by the `GRAPH_PATH`/`EX_FONT`/`SYSTEM` code in
`sub_821D6350`/`sub_821D6A40`); and `builtin103`'s `[phase+10152]` /
`[phase+10156]`, which are neighbours of REQUEST_NEXT but have 14 and 11
touching sites rather than one — a different, busier mechanism.
## ✅✅ SOLVED — the mission freeze was a modal sign-in dialog (2026-08-26)
`XamShowSigninUI` opens a modal dialog and `xeXamDispatchDialog` blocks the