ac4f53b8a1
sub_822FE040 is a fully unrolled registration: 1023 slots filled with a default, then 57 explicit writes, of which 48 are real handlers and nine are a shared accept-and-discard stub. Return convention is nonzero = consumed, 0 = retry, which is how the interpreter waits for a named unit to exist. Opcode 995 is the ONLY handler touching the phase mirror [*(0x828F35F8)+236] -- the sole read and sole write in the table -- independently confirming why polling that mirror saw nothing during phase 1. And no handler spawns or despawns a unit: 256 is the strongest deploy candidate but is unconfirmed because the message ids are write-only in this image. WITHDRAWN, verified wrong: I had recorded the writes to '+20' in sub_8226E7D8 / sub_8226E930 as block initialisations by container constructors. At 0x8226E86C-0x8226E8E0 they do li r3,28 / bl 0x8230C160 then lis r10,0xAB03 / ori r7,r10,0xE4BA / stw r7,4(r3): they build an INTERPRETER COMMAND RECORD for opcode 996 and push it, i.e. AddSelector and RemoveSelector, with a 32-entry cap. The stw to 20(r3) is the command record's +20, a different object. Wrong twice: not constructors, and not that container. Also flags that sub_8230C398 -- gated on *(0x82899CE0) == 16 at both call sites -- looks like Stage 16's script compiled in C++, which 'debug defaults' does not survive given the .ssb loader explicitly refuses mission 16.