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

re: [phase+10152]/[phase+10156] are an answer and a request state

Browse Source 
Built-ins 102/103/130 are one trio over two phase fields, read off
four consecutive vtable stubs (slots 70/71/72/97).  102's body:

  state==1 -> return 2                     (pending)
  state==2 -> special[0] = (answer==1); state=0; return 0
  else     -> state=1; answer=0; return 2  (issue)

2 and 0 are the dispatcher's thread codes, so 102 blocks the coroutine
until an answer arrives; 103 is the non-blocking form and 130 clears
the answer.  The answer is published by sub_821A9DC8 under the same
(16,32] gate that request_next's writer uses.

Flags an inherited name I could not verify: prompt_yes_no (102) has no
derivation recorded anywhere in the corpus, so 103 and 130 are left
unnamed rather than named off it.

Docs only; artefacts byte-identical.
This commit is contained in:
Sylpheed RE agent
2026-08-27 09:39:52 +00:00
parent af61c162f3
commit 237dbce155
2 changed files with 78 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

32
docs/re/BACKLOG.md
View File

@@ -418,6 +418,38 @@ unknown, what evidence exists, and what the first step would be. Move an item in
`[phase+10156]`, which are neighbours of REQUEST_NEXT but have 14 and 11
touching sites rather than one — a different, busier mechanism.
* ✅⚠️ **(2026-08-27) `[phase+10152]` / `[phase+10156]` ARE READ — an ANSWER and a
request STATE, and built-ins 102/103/130 are one trio.
[structures/isl-condition-builtins](structures/isl-condition-builtins.md).**
The backlog carried these as "9 and 7 writers, unread", and warned they are not
`request_next`'s siblings just because they are adjacent. Correct — they belong
to **four consecutive vtable stubs**: 102 → slot 70 `sub_8226BF48`, 103 → slot
71 `sub_8226BFA8`, 104 → slot 72 (`request_next`), **130 → slot 97**
`sub_8226BFD0`. Built-in 102's body:
`state==1 → return 2` (pending); `state==2 → special[0] = (answer==1); state=0;
return 0`; `else → state=1; answer=0; return 2`. **`2` and `0` are the
dispatcher's thread codes**, so 102 is a *blocking* built-in that yields until
an answer arrives; **103 is the non-blocking form** (`state != 0 && answer ==
1`) and **130 clears the answer**. ⇒ **`[phase+10156]` = request state (0 idle /
1 pending / 2 answered), `[phase+10152]` = the answer**, tested against 1.
✅ The answer is published by `sub_821A9DC8` (`[10152] = [r6+4]`, `[10156] = 2`)
**under the same `(16,32]` gate on `[r30+104]+12`** that `request_next`'s writer
uses — one engine→script publish path serves both.
⚠️ **An inherited name I could not verify: `prompt_yes_no` (102).** Grepping the
corpus, it appears only in a list of built-ins Stage 02 does not call, with **no
derivation recorded anywhere**. The mechanism is consistent with a modal yes/no
prompt but does not establish it, so **103 and 130 are left unnamed** rather
than named off an unverified premise.
🟡 Not settled: what question is asked. `sub_821A9DC8` has **no strings** and
exactly one reference in the image (a tail `b` from `0x821AC064`), so the
string recipe finds nothing there; and the `(16,32]` gate is still unread.
📎 Reference picked up on the way: the image carries the **full GamePart id
table** as `silph::GamePartTask::RegisterToFactory<N,class silph::GamePart_X>`
strings — Title 0, SaveLoad 3/4, Extras 5, MovieTheater 6, MissionSelect 7,
Options 8, Movie 9, Bunk 10, ReadyRoom 11, Hangar 12, Arsenal 13, PilotLog 14,
System 15, MainGame 17, PauseMenu 19, StageClear 20, MissionLog 21, GameOver 22,
Debriefing 23, Dialog 24, Tutorial 25, ChallengeMission 26, Leaderboard 27.
## ✅✅ SOLVED — the mission freeze was a modal sign-in dialog (2026-08-26)
`XamShowSigninUI` opens a modal dialog and `xeXamDispatchDialog` blocks the