From d19634e061873adcfa70f48ba0798d75de9524b3 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Tue, 25 Aug 2026 18:24:21 +0000 Subject: [PATCH] re: what appends a trigger node -- not found, recorded as such Three approaches, none successful. sub_8226E160, earlier flagged as 'enqueue a pending trigger', has exactly one caller and is a specific operation rather than the general append. Writes to the count at +20 inside the container code number only four, and all four are part of a block initialisation (stw to 0/8/12/16/20/ 24 in consecutive instructions) in sub_8226E7D8 and sub_8226E930 -- constructors, called from 0x8226E560 and from ScriptMission's own constructor at 0x822608A0. So the increment that takes the count 0 -> 1 -> 2, which is measured live, does not appear as a plain stw to 20(rM) anywhere in the container's code. It is inlined, uses another addressing form, or lives somewhere I have not looked. Recorded as not found rather than guessed: inferring from the shape of nearby functions is exactly what produced the 'push' mislabel last iteration. Names the approach that would settle it: a gdb watchpoint on ScriptPhase+272+20 during a live mission. The address is known at runtime, the count demonstrably changes within ~2 minutes, and a watchpoint reports the writing instruction directly instead of inferring it from static shape. --- docs/re/structures/isl-builtins.md | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/docs/re/structures/isl-builtins.md b/docs/re/structures/isl-builtins.md index 19385bb7..e4dc030d 100644 --- a/docs/re/structures/isl-builtins.md +++ b/docs/re/structures/isl-builtins.md @@ -338,3 +338,33 @@ So built-in 100 *clears* the trigger queue and then rebuilds the thread list via mine, not the disassembly's. `xrefs` gives it two callers: `0x82265DD4` (vt2, the script side) and **`0x8226D420`, an engine site** — so the engine clears it too. What actually *appends* a node is still unidentified. + + +## 🔴 What appends a trigger node — NOT FOUND this iteration + +Three approaches, none of which produced the appender: + +* **`sub_8226E160`**, flagged earlier as "enqueue a pending trigger", takes a + `double` plus several pointers, rejects `arg == -1`, and has **exactly one + caller** (`0x8226A044`). It is a specific operation, not the general append. +* **Writes to the count at `+20`** inside the container code + (`0x8226DF00–0x8226F200`) are only **four**, and all four are part of a + *block initialisation* — `stw` to `0, 8, 12, 16, 20, 24` in consecutive + instructions, in `sub_8226E7D8` and `sub_8226E930`. Those are **constructors** + (callers `0x8226E560` and `0x822608A0`, the latter inside `ScriptMission`'s + own constructor), not increments. +* So the increment that takes the count 0 → 1 → 2 — which is **measured, live** + — does not appear as a plain `stw rN, 20(rM)` anywhere in the container's own + code. It is either inlined into a caller, uses a different addressing form + (`stwx`), or the node count is maintained somewhere I have not looked. + +**Honest state:** the queue's structure, its live count and its node chaining are +verified; what writes a node into it is not identified, and I do not have a +candidate I believe. Guessing from the shape of nearby functions is what produced +the "push" mislabel last iteration, so I am not repeating it. + +**The approach that would settle it** costs more but is unambiguous: a **gdb +watchpoint on the count word** during a live mission. The address is known at +runtime (`ScriptPhase + 272 + 20`), the count demonstrably changes within ~2 +minutes of flight, and the watchpoint reports the writing instruction directly +instead of inferring it from static shape.