re: the ScriptPhase vtable is 113 slots, and there is a SilphScriptPhaseDemo

RTTI at vtable[-1] names the class .?AVSilphScriptPhase@silph@@ and the
next class's COL at 0x820A8680 terminates the table at 113 entries.
The earlier ">=200 slots" reading used a bad terminator -- scanning for
a non-code word runs straight into the next vtable.  Cross-check: the
147 built-in stubs use 109 distinct slots, min 0 max 110.

The next vtable is .?AVSilphScriptPhaseDemo@silph@@, also 113 slots,
overriding 109 of them with mostly one shared stub -- a cut-down phase.
That explains why sub_822710D0 has two callers: sub_82263408 and
sub_82275800 are the two classes' Update, both slot 111.

Both "unread spawner callers" are placed: sub_82264058 is slot 0 of
SilphScriptPhase and sub_82273910 is slot 0 of the Demo class -- the two
destructors.

Also records a negative: the Stage%02d construction site I proposed last
iteration does not exist (no stage format string among the 43 short %d
strings; no precomputed name hash anywhere), so the stage-index lead
cannot be settled that way.

Docs only; artefacts byte-identical.
This commit is contained in:
Sylpheed RE agent
2026-08-27 10:05:01 +00:00
parent 6213825a2f
commit 044b98dcc4
3 changed files with 95 additions and 5 deletions

View File

@@ -215,9 +215,25 @@ Compare the controls honestly:
| stage index (this) | **1** — Stage17 | 1 value | 1-of-1 |
That is a much tighter fit, and it is *still* coincidence-shaped. **Not adopted.**
What would settle it: the `Stage%02d` construction site — the image has a generic
`'%s%02d'` formatter at `0x820A9C8C`, and whether it is fed `index` or
`index + 1` decides the question outright. Not found this pass.
### 🔴 (2026-08-27) The test I proposed for it DOES NOT EXIST
The plan was to find the `Stage%02d` construction site and see whether it is fed
`index` or `index + 1`. Two searches say there is no such site:
* **No stage-shaped format string.** The `'%s%02d'` at `0x820A9C8C` has exactly
**one** xref, into `sub_822929E0`, a generic string helper. Listing *every*
short `%d`-bearing string in the image — 43 of them — turns up no
`Stage`/`_S%02d` pattern at all.
* **No precomputed name hash.** Using the corpus's own `name_hash`, the values for
`Stage_S00…30`, `Stage00…30`, `StageNN.ssb` and `UnitGroup_S00…30` appear
**nowhere in the image as a 4-byte word**.
So the executable never builds a stage script's name; the mapping lives on the
data side. **The stage-index lead cannot be settled this way**, and the next pass
should not retry it. The one remaining static handle is another hop up: `X+12`
arrives as `[r21+8]` in `GamePart_MainGame` vtable slot 4, so it comes from
whatever the GamePartTask manager passes when it switches parts.
🟡 Its neighbours belong to the same cluster: `builtin103` reads
`[phase+10156]` and `[phase+10152]` (9 and 7 writers), and a sibling vtable stub