• Listen to a special audio message from Bill Roper to the Hive Workshop community (Bill is a former Vice President of Blizzard Entertainment, Producer, Designer, Musician, Voice Actor) 🔗Click here to hear his message!
  • Read Evilhog's interview with Gregory Alper, the original composer of the music for WarCraft: Orcs & Humans 🔗Click here to read the full interview.

Such things as "Multi Trigger Instancibility"?

Level 6
Joined
Apr 15, 2016
Messages
118
This may be a silly and have an obvious answer, but I just can't remember.

Suppose you have a Trigger

Spell 1
Events - Starts the effect of an Ability
Conditions - Ability being cast equal to X
Actions - Set Mui = Mui + 1
Set Caster[Mui] = Tiger unit
Set AoE[Mui] = 666
If Mui is 1
Trigger turn on DamageLoop

And another Trigger

Spell 2
Events - Starts the effect of an Ability
Conditions - Ability being cast equal to Y
Actions - Set Mui = Mui + 1
Set Caster[Mui] = Tiger unit
Set AoE[Mui] = 300
If mui is 1
Trigger turn on DamageLoop

This being the loop trigger

DamageLoop
Event - Every 800 seconds
Conditions
Action - For integer Nui to 1 to Mui
Damage enemies of caster[Nui] at Aoe[Nui]


Now, question is, both spells, Y and X use the same variables and call the same loop trigger. I suppose these work fine, or do I have to create new Variables and looping for each spell, considering they have different values in their variables (which is why I can't use Multiple Conditions set to ability being cast equal to X and Y)? Instead of Ability being usable by more than one unit, some sort of Trigger being used by more than one Ability. A Multi Trigger Instancibility.
 
Level 45
Joined
Feb 27, 2007
Messages
5,578
(which is why I can't use Multiple Conditions set to ability being cast equal to X and Y)
You can check the ability and branch your logic in the trigger actions:
  • Events
    • Unit - A unit starts the effect of an ability
  • Conditions
    • Or - Any condition is true
      • (Ability being cast) equal to Spell A
      • (Ability being cast) equal to Spell B
  • Actions
    • Set C = (C + 1)
    • Set Caster[C] = (Triggering Unit)
    • If (All conditions are true) then do (Then actions) else do (Else actions)
      • If - Conditions
        • (Ability being cast) equal to Spell A
      • Then - Actions
        • Set AoE[C] = 2300.00
      • Else - Actions
        • Set AoE[C] = 150.00
    • If (All conditions are true) then do (Then actions) else do (Else actions)
      • If - Conditions
        • C equal to 0
      • Then - Actions
        • Trigger - Turn on Periodic <gen>
      • Else - Actions
In your trigger, all the AoEs will damage at exactly the same time (every 8 seconds). This means that a unit added to the list right before the timer goes off it'll only wait a short while, but a unit added after it goes off will have to wait a while. You can resolve this by making the frequency much higher and using some sort of integer counter variable to determine on which iterations the effects for that particular instance should occur. Here is a good resource if you have not seen it already: Visualize: Dynamic Indexing
 
Level 6
Joined
Apr 15, 2016
Messages
118
In your trigger, all the AoEs will damage at exactly the same time (every 8 seconds). This means that a unit added to the list right before the timer goes off it'll only wait a short while, but a unit added after it goes off will have to wait a while.
But isn't that why we use From each interger A from 1 to Z? So that it knows which Area [Z] it should damage?

I liked the way you handled it all in one trigger. I made this topic because in most systems from Hive, examples triggers are always separated, ie, knockback system has 12 examples that run Trigger - Turn on <Some Trigger> for different spells, and they are never in the same Trigger, like you did. Though I'm never sure if they just do like that because those are just examples, so they don't care much if it leaks, if they are inefficient or anything (as long as the SYSTEM TRIGGER works fine), so that's why the doubt.
Once or another I would stumble upon a High Quality Hive resource that had way too many leaks in their EXAMPLES Triggers.
 
Last edited:
Level 45
Joined
Feb 27, 2007
Messages
5,578
STOP WORRYING AND JUST MAKE YOUR TRIGGERS. You are nitpicking things that do not and will never matter to you in your mapping existence. There are numerous ways to solve every problem and sometimes people prioritize different methods/behavior/styles. WC3 maps are not high-performance situations where only the best perfect way is acceptable; just proceed normally without thinking too hard until you encounter unexpected or undesirable behavior.
ie, knockback system has 12 examples that run Trigger - Turn on <Some Trigger> for different spells
Did you perhaps think to look at the trigger that was being run? Or why it was being run? Or look at the variables set before the trigger is run? Since GUI cannot make its own functions easily, it is common practice to make an eventless trigger work as a function: set some variables and then run the trigger. Examples also often want to make it very clear why they are doing what they are doing, and for greater visual clarity may aggressively organize or separate its parts. Examples exist to show you how to use/interface/interact with the resource in question and should be perceived solely in that light.
Once or another I would stumble upon a High Quality Hive resource that had way too many leaks in their EXAMPLES Triggers.
An example trigger is clearly never intended to be used by anyone for any purpose other than to showcase something in a demo. Whether it leaks or not is largely irrelevant (because such leaks would not eat enough memory to matter while testing the map), and to be mad about such a thing is ludicrous.
But isn't that why we use From each interger A from 1 to Z? So that it knows which Area [Z] it should damage?
Reread my comment; it has nothing to do with area and everything to do with time. Every 8 seconds the entire list of units is looped over to create the damaging volumes. Every 8 seconds. The entire list together at the same time. All the damage happens at the same time; which is not the same thing as each instance damaging around its caster 8s after that specific cast was completed.
 
Top