The Koopo bug, redux

[premchai21]

I couldn't find this already described anywhere, so here we go. Are you ready for this?

It's the tail end of the duplicator cycle.

P1 is the duplicator phase, and that gets reset to 0 at the time a duplicator performs its function; for an object, P1 is the display character, so the object displays as the blank NUL graphic. Duplicators also reset their cycle to 3(9 − P2) every cycle, and for an object P2 is normally zero for unlocked, so that results in a cycle of 27 (or 24 if the object starts out locked). The object that gets scrambled is the one that has the same stat index on the new board as the duplicator did in the previous board. The duplicator code just never bothers to check whether the stats record it's now modifying is the same one it was modifying before. (Why would it, after all?)

Note that this implies that non-object records, such as for monsters, can be altered as well, with different resultant effects.

So put your sacrificial stats records at the same stat index as the triggering duplicators and you should be safe, I expect.

[Commodore]

which duplicators do this? Just the highest stated one, the lowest? Or all of them?

[premchai21]

Just whichever one is the trigger to move to the new board, I expect, though I haven't done a full experiment with multiple. There can be only one such trigger at a time, because <s>after it's processed (and possibly after further stuff is processed on the next board, but I don't think so based on my vague understanding of how pausing probably works) the player is paused on the new board</s>all the processing is serialized anyway.