415dd75a8b
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.