[General] Basics of trigger events?

[SnowYell]

Pros and cons of having one or more trigger events with dying/entering unit etc?

So far whenever I've wanted something specific to happen after a unit dying, I have made a completely separate trigger with event dying unit to run it.

But I just thought of having one single dying unit event be the only trigger with dying unit event and make it check conditions and make it run other triggers for actions.

Is this how everyone but me have been doing triggers?

 

[Remixer]

A clear pro having separate triggers is that they're easier to edit and keep track of. I have had triggers with dozens of if/then/else's and it just becomes horrible and slow in the editor.

Efficiency wise I don't know if they differ from each other.

 

[Uncle]

It can be more efficient if handled properly, but it's really something that makes more sense when working in code, especially Lua.

I have done it before though:

• Events
  • Unit - A unit dies
• Conditions
• Actions
  • Set Variable DyingUnit = (Triggering unit)
  • Trigger - Run DeathTriggerA (checking conditions)
  • Trigger - Run DeathTriggerB (checking conditions)
  • Trigger - Run DeathTriggerC (checking conditions)

There's something important to note here. When a unit dies, any triggers with the "A unit dies" event will run IMMEDIATELY instead of the standard rules -> Create a new trigger instance and add it to the trigger queue.

For example, if another Unit were to die during the Actions of DeathTriggerA, it would become the new DyingUnit, and run these triggers again AS WELL as continue running B/C from before. This would break B/C completely since they would now be referencing the wrong dead unit.

I don't think any other Event suffers from this "instance/queue" problem, so this strategy should be fine in those cases.

 

[Pyrogasm]

Filtering trigger execution out by their triggerconditions returning false is, in my understanding, extremely efficient. (Compared to an I/T/E that interrupts execution.) To that end it’s perfectly fine to have many triggers with the same event as long as they all use their conditions properly.

I only try to combine triggers with similar events in two situations:

1. If it’s much easier to do filtering with I/T/E in the main trigger actions. Maybe this is because of the event responses available, or maybe because what I want to check has lots of repetition, or maybe because it would be annoying/inefficient to use a GUI triggercondition (like checking every item slot of the damage source every time any unit takes damage).

2. The triggers do almost identical things but just with different numbers. In such cases a couple variables will make it easy to combine the triggers.

 

[SnowYell]

It can be more efficient if handled properly, but it's really something that makes more sense when working in code, especially Lua.

I have done it before though:

• Events
  • Unit - A unit dies
• Conditions
• Actions
  • Set Variable DyingUnit = (Triggering unit)
  • Trigger - Run DeathTriggerA (checking conditions)
  • Trigger - Run DeathTriggerB (checking conditions)
  • Trigger - Run DeathTriggerC (checking conditions)

There's something important to note here. When a unit dies, any triggers with the "A unit dies" event will run IMMEDIATELY instead of the standard rules -> Create a new trigger instance and add it to the trigger queue.

For example, if another Unit were to die during the Actions of DeathTriggerA, it would become the new DyingUnit, and run these triggers again AS WELL as continue running B/C from before. This would break B/C completely since they would now be referencing the wrong dead unit.

I don't think any other Event suffers from this "instance/queue" problem, so this strategy should be fine in those cases.

That's exactly what I am afraid of, having multiple events trigger at once overlapping eachother.

Also if I have trigger:
Event Dying Unit
Condition Dummy Unit
Action set Dying_Unit
Action Remove Dying_Unit

And another trigger

Event Dying Unit
Condition Enemy Unit
Action set Dying_Unit
Action Make Dying_Unit do something

I am afraid of these overlapping (and any other general variable used in these triggers). Having this system where ONE trigger monitors every dying unit trigger would make me able to have ONE variable for dying units in the entire trigger editor?

 

[Uncle]

Having this system where ONE trigger monitors every dying unit trigger would make me able to have ONE variable for dying units in the entire trigger editor?

The "A unit Dies" Event is the only event that you DON'T want to do this with. Everything else should be fine.

The rule is simple: NEVER share variables inside of a "A unit Dies" event.

However, if you're confident in your understanding of the problem then it should be fine as long as you know that there won't be any conflicts.

Here's an example of using a shared variable that would break due to the nature of this Death event:

• Events
  • Unit - A unit Starts the effect of an ability
• Conditions
  • (Ability being cast) Equal to Super Cool Ability
• Actions
  • Set Variable MyUnit = (Casting unit)
  • Unit - Kill (Target unit of ability being cast)
  • Unit - Set life percentage of MyUnit to 100.00%

• Events
  • Unit - A unit Dies
• Conditions
• Actions
  • Set Variable MyUnit = (Dying unit)
  • Player - Add -100 gold to (Owner of MyUnit)

The outcome of these two triggers would be this:

• Events
  • Unit - A unit Starts the effect of an ability
• Conditions
  • (Ability being cast) Equal to Super Cool Ability
• Actions
  • Set Variable MyUnit = (Casting unit)
  • Unit - Kill (Target unit of ability being cast)
  • Set Variable MyUnit = (Dying unit)
  • Unit - Set life percentage of MyUnit to 100.00%
  • Player - Add -100 gold to (Owner of MyUnit)

The (Dying unit) will be healed for 100.00% instead of the (Casting unit) because "A unit Dies" doesn't follow the normal rules. The variable MyUnit gets overwritten and changes the expected results of the Ability trigger.

As far as I know, every other Event would be fine here and wouldn't cause this "melding of two triggers" to happen. Normally, triggers are separated in instances that get queued allowing things to happen in a sequential order and thus preventing any conflicts.

 

[SnowYell]

The "A unit Dies" Event is the only event that you DON'T want to do this with. Everything else should be fine.

So if I have multiple triggers with dying events and all these triggers share the same variables configured to DyingUnit, DyingInteger, DyingPoint etc...

And same goes for EnteringUnit, EnteringInteger, EnteringPoint.

Then I can have spell casts as UnitCaster, UnitTarget etc.

So if I have all triggers with events fired from Dying event, then it's ok for them all to share the same Dying variables?

 

[Uncle]

So if I have multiple triggers with dying events and all these triggers share the same variables configured to DyingUnit, DyingInteger, DyingPoint etc...

And same goes for EnteringUnit, EnteringInteger, EnteringPoint.

Then I can have spell casts as UnitCaster, UnitTarget etc.

So if I have all triggers with events fired from Dying event, then it's ok for them all to share the same Dying variables?

I'll be honest, I have no idea what you're asking but it sounds incorrect. I'll try to simplify it:

Does your trigger deal damage or kill units? If yes -> Does your trigger share variables with any "A unit dies" triggers? if yes -> PROBLEM!!!

Does you trigger deal damage or kill units? If no, it's ok to share the variables.

Again, I've only experienced this issue with the "A unit dies" event. But it could occur elsewhere. It's not a hard thing to test yourself with some text messages.