What DSB guarantees

[Sophia]

What may be useful for dungeon designers (or maybe just for me to preserve my own sanity) is a list of things related to triggers that DSB makes guarantees* about.

All triggers in a given square will be executed. The only interruption will be if an operating instance is destroyed.
Constant weight triggers will always send their "on" message before their "off" message, and the messages will always come in pairs, unless the trigger itself is destroyed.
Messages with a delay of n will always arrive before messages with a delay of n+1.
Messages sent together as part of a single trigger will arrive in the order they are listed. That is, if a floor trigger sends a {M_ACTIVATE, M_DEACTIVATE} (with the same delay) then the activate will always arrive before the deactivate.
As a more general case of the above, calls to dsb_msg within the same call into Lua will queue up their messages in the same order.

Relatedly, here is a list of things that DSB does not guarantee:

Triggers will not necessarily execute in the order they are put down in the editor. I've made every effort to do the sane thing, but, to be absolutely sure, either use a single trigger or custom code.
Messages sent on different ticks will arrive in an undefined order. If, on tick 6, a pit receives a M_ACTIVATE sent on tick 4 with a delay of 2 and a M_DEACTIVATE sent on tick 5 with a delay of 1, do not rely on the pit being open or closed.
Messages arriving at the same target not sent as part of a single trigger's list of targets will arrive in an undefined order. If two different triggers send messages to a pit on the same tick, one M_ACTIVATE and one M_DEACTIVATE, again, do not rely on the pit being open or closed.
As a more general case of the above, calls (or groups of calls) to dsb_msg from within different calls into Lua will not necessarily deliver their messages in the same order that the different Lua functions were called.

* By "guarantee," I mean that this is a thing that is defined as part of the specification. That's not to say it's going to be what DSB actually does, but if it does the wrong thing, you can quite fairly call it a bug and I will fix it. This in no way constitutes any sort of a legal guarantee, product warranty, or other EULA nonsense.

[Paul Stevens]

In CSBwin I found it necessary, perhaps to help Zyx maintain
his sanity, to guarantee that 'similar' messages arriving at
the same tick of the clock arrive in the order they were
generated. I had to modify the original Atari code to do this.
(I added a 'serial number' to each message as I recall.)

What 'similar' means, I do not remember. Some messages
are forced to arrive before others. For example (and this
is just an example, not a fact), it might be that
monster movement messages are forced to precede door
movement messages. But all messages to manipulate doors,
pits, and walls are certainly 'similar'. (Set, Clear, and Toggle
messages in the editor).