I don't know what happens internally, but you could try this test (I would do it myself but right now I'm too ill/tired/whatever to turn on the computer):Isaac wrote: ↑Sun Mar 15, 2020 4:49 amThis is very good; best practice I think. (And thanks for the comment on it. )
But what really happens under the hood when the object is destroyed (by the usual method)? Is its position shifted? Can an entry be missed?
It seems to make sense to almost always (or to only) use destroyDelayed just as a matter of course, because it does bypass some nasty crashes in some situations. But does anyone know (or can reasonably speculate on) what could actually happen if an object gets destroyed in the iterator loop—and is never accessed again? Could it actually crash?
minmay will tell you (with good reason) that the monster.contents iterator is damaged, or broken; it DOES (or can? IIRC) cause crashes when it returns nil. I never had a crash with it after I added a 'pocket_lint' item before using it.
Put an alcove in your dungeon and put three different items in it.
Put a button next to it and connect it to a script.
In the script you do three things:
1) Iterate throught the contents and hudPrint the item-names. Shouldn't be too surprising.
2) Iterate through the contents and hudPrint the names, but destroy the first item (not destroyDelayed) after hudPrinting it. Are all three items now printed or only two, and if so, which two?
3) As in 2, but apart form destroying the item also spawn and add a new item. What happens now?
The answers might give you an idea (but no certainty) about the inner workings of the iteration.