All state-mutating script opcodes (SetFlag/StoreVar/etc.) silently kill script execution — read-only opcodes work fine

[CharlieHuntley]

Working on a B2W2 (IRDO) hack, hit a very consistent, reproducible issue I can't explain and haven't found documented anywhere. Posting in case others have hit this or know the real mechanism.

Setup: Hand-assembled a new NPC dialogue sequence, appended to an existing map's script file (/a/0/5/6), correctly resolved via the map's Zonedata record (mapScriptsIndex). Verified byte-for-byte correct via a custom BeaterScript-based decompiler at every step, and confirmed via live DeSmuME testing that basic dispatch/read logic works reliably (an NPC branching on a PushStackDerefVar/CompareStackVarTo/ConditionalJump sequence displays the correct message every time, deterministically, across many rebuilds).

The bug: The moment a sequence contains any instruction that writes persistent state, interacting with that NPC produces complete silence — no message, no sound cue, nothing. Tried, all with identical total-silence failure:

• StoreInVar (0x28), 2× ushort params (var addr, value)
• PushStackVar(0x8) + PopStackVar(0xA)
• SetFlag (0x23), tested with both a known-in-vanilla-use flag ID (695) and an arbitrary one (4000)
• StoreDerefVar (0x2A), the pattern seen in real vanilla scripts around CallStd 2805 calls
• Same with a ReturnAfterDelay inserted before the write (timing theory)
• Same with extra padding bytes after the parameter (parameter-width theory)
• Confirmed target addresses are in-bounds against the real save layout (Works[]/"Event const" block is exactly 431×2 bytes at 0x1ff00–0x2025e per FlagBrew/PKSM-Scripts' save map; flags go well into the thousands)

Also tried using opcode 0xA purely as a read instead (per CheapScript's naming it as GetStackVar rather than B2W2.yml's PopStackVar) — still silent either way.

Ruled out: NPC entity/position (same NPC works fine with read-only content at the identical position), save file staleness (tried a fresh backup-memory import), sequence-count/file-size limits (tested well under any threshold we found), and the ROM having any of our own custom ARM9 hooks (tested against the plain vanilla ROM).

Has anyone seen this before, or know whether these opcodes actually need a different calling convention (register setup, specific context, etc.) that isn't captured in the BeaterScript/B2W2.yml command definitions? Happy to share the exact test ROMs/bytecode if useful.