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:
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user