How does this even work?

[Wing-Span]

There are two triggers at the bottom. One deletes a unit, and the other displays text when a unit of a certain type enters the region. But these two triggers ALWAYS fire! Why? I've swapped them around and restarted the editor, but they still fire together, even though triggers should run top-to-bottom. Or am I missing something? Doesn't the unit ID become 0 or null after deletion?

• TTEESSTST
  • Events
    • Unit - A unit enters Region 030 <gen>
  • Conditions
    • (Unit-type of (Triggering unit)) Equal to Footman
  • Actions
    • Unit - Remove (Triggering unit) from the game

• TTEESSTST1
  • Events
    • Unit - A unit enters Region 030 <gen>
  • Conditions
    • (Unit-type of (Triggering unit)) Equal to Footman
  • Actions
    • Game - Display to (All players) the text: 123

 

[Chaosium]

Actions run top to bottom but triggers can fire at the same time right?

 

[Wing-Span]

Actions run top to bottom but triggers can fire at the same time right?

Yes, they work together, no matter how you rearrange them, although the unit should theoretically be removed, so it shouldn't pass the second trigger check.

 

[Uncle]

As far as I understand, removing a unit from the game doesn't necessarily mean it's data has been removed from memory. A unit is just an Integer (Handle ID) which gets passed into other data structures to get information about them. As long as those data structures (arrays, hashtables, structs, etc) haven't been cleared then the data they hold will still be accessible.

I'd assume that the moment a unit is removed from the game:
1. Positional based information is lost.
2. The unit stops ticking, rendering, pathing, AI, selection, etc.
3. Certain functions, like getting it's Unit-Type ID are still available.
4. Eventually it will be garbage collected and all functions will "fail" for it.

Regarding triggers, the game uses a trigger queue system which will execute things in a logical order, one after the other. Technically multiple things cannot happen "at the same time", but they can happen within the same frame which is basically simultaneous.

As far as I remember the triggers do NOT run from top to bottom and there's no way to control this behavior yourself.

Regarding events and using your triggers as an example, when the Footman enters the Region both Events will fire and both triggers will be added to the queue. One trigger is chosen to execute first, which I imagine is done at random. It's Conditions are checked top to bottom, then if all of those are True it proceeds to execute the Actions from top to bottom. Then after the first trigger is done with this process it will proceed to the second trigger.

Note that if any of those Actions were to cause another Event to fire then those associated triggers would be added to the end of the queue.
In very rare cases, like when using the "A unit Dies" Event, the queue rule is ignored and the trigger will run immediately. Luckily, this behavior is consistent so you can plan around it.

Also, note that these are actually INSTANCES of triggers that are being queued, which is why a trigger can fire multiple times at once and doesn't "restart". It's also why a trigger can run into issues when incorporating Waits and other delays, since you create something known as race conditions.

 

[Wing-Span]

As far as I understand, removing a unit from the game doesn't necessarily mean it's data has been removed from memory. A unit is just an Integer (Handle ID) which gets passed into other data structures to get information about them. As long as those data structures (arrays, hashtables, structs, etc) haven't been cleared then the data they hold will still be accessible.

I'd assume that the moment a unit is removed from the game:
1. Positional based information is lost.
2. The unit stops ticking, rendering, pathing, AI, selection, etc.
3. Certain functions, like getting it's Unit-Type ID are still readily available.
4. Eventually it will be garbage collected and all functions will start to "fail" on it.

Regarding triggers, the game uses a trigger queue system which will execute things in a logical order one after the other. Technically things cannot happen "at the same time", but things can happen within the same frame which is basically simultaneous.

As far as I remember the triggers do NOT run from top to bottom and there's no way to control this behavior yourself.

Regarding events and using your triggers as an example, when the Footman enters the Region both Events will fire and both triggers will be added to the queue. One trigger is chosen to execute first, which I imagine is done at random. It's Conditions are checked top to bottom, then if all of those are True it proceeds to execute the Actions from top to bottom. After the first trigger is done with this process the second trigger will proceed to do the very same thing.

Note that if any of those Actions were to cause another Event to fire then those associated triggers would be added to the end of the queue.
In very rare cases, like when using the "A unit Dies" Event, the queue rule is ignored and the trigger will run immediately. Luckily, this behavior is consistent so you can easily plan around it.

Also, note that these are actually INSTANCES of triggers that are being queued, which is why a trigger can fire multiple times at once. It's also why it's so easy to run into issues when incorporating Waits and other delays into your triggers, since you create something known as race conditions.

Thanks for the analysis. It sounds quite reasonable.