63d3ce089f
Chasing what makes the phase-1 condition re-evaluate, since the polls do not run continuously. Two method corrections: searching the VM range for '272(rN)' mostly returns VTABLE slot offsets -- 0x82273174 lwz r11,272(r11) is followed by mtctr/bctrl, a virtual call through slot 68, not an access to the phase field. And [phase+272] is not a pointer to a queue but an EMBEDDED container: vt2 (sub_82265DD0) is 'addi r3,r3,272 ; b 0x8226E3B8', passing phase+272 as this. Layout from the push/pop pair (sub_8226E3B8 from built-in 100, sub_8226E220 called every frame from sub_8226D740): +12 list head, +16 current node, +20 element count (zero = empty, tested first by the pop), +24 scratch. The pop returns the record through out-parameters read from node+8: three u32s, a double at +16, another u32 at +24 -- matching the six pointers sub_8226D740 passes in. The actionable part is [phase+272+20], a live pending-trigger count readable from /dev/shm. Watching it alongside [ScriptMission+40] should show when the engine hands the script an event, which is when condition coroutines start -- the thing every phase experiment so far has been blind to. Layout is from disassembly only; not yet verified live.