• 🏆 Texturing Contest #33 is OPEN! Contestants must re-texture a SD unit model found in-game (Warcraft 3 Classic), recreating the unit into a peaceful NPC version. 🔗Click here to enter!
  • It's time for the first HD Modeling Contest of 2024. Join the theme discussion for Hive's HD Modeling Contest #6! Click here to post your idea!

My Trigger Breaks when I delete the wait action.

Status
Not open for further replies.
Level 16
Joined
May 2, 2011
Messages
1,345
Hello,
when I delete the wait action, both items are dropped by the same unit. How do I fix that? Here are the two triggers. It is important to delete the wait because both units can die from single splash attacks: e.g. mortar teams or cannon tower.

  • ItemOfTheMagus01
    • Events
      • Unit - A unit owned by Player 5 (Yellow) Dies
    • Conditions
      • (Unit-type of (Dying unit)) Equal to Elite Necromancer
    • Actions
      • Trigger - Turn off (This trigger)
      • Set TempPoint003 = (Position of (Dying unit))
      • Item - Create Robe of the Magi +6 at TempPoint003
      • Custom script: call RemoveLocation(udg_TempPoint003)
      • Wait 0.03 seconds
      • Trigger - Turn on ItemOfTheMagus02 <gen>
  • ItemOfTheMagus02
    • Events
      • Unit - A unit owned by Player 5 (Yellow) Dies
    • Conditions
      • (Unit-type of (Dying unit)) Equal to Elite Necromancer
    • Actions
      • Trigger - Turn off (This trigger)
      • Set TempPoint004 = (Position of (Dying unit))
      • Item - Create Sobi Mask at TempPoint004
      • Custom script: call RemoveLocation(udg_TempPoint004)
 

Dr Super Good

Spell Reviewer
Level 64
Joined
Jan 18, 2005
Messages
27,198
There are two solutions. Either reference specific units (not unit types) or make a list of items the unit type can drop and remove and drop one item from the list for each unit of the unit type that dies.

If these units are not present at map initialization one could assign them to a unit array upon creation for tracking by the triggers. The condition would then check if the dying unit is equal to one of those specific units. The trigger only needs to be turned on when the unit is created and can be turned off after it fires.

The list approach would use an array of item types with an integer variable to track the number of indices populated. For each of the units that die, create the last index item type and decrement the counter by 1. Again the trigger only needs to be turned on when the units are created and can be turned off once the list is empty (counter is 0).

In 1.31 if one uses Lua as the underlying scripting language one can potentially solve location leaks automatically through garbage collection.
 
Level 39
Joined
Feb 27, 2007
Messages
5,010
You have two triggers with identical events and identical conditions, and one of them disables the other one when it runs. What are you actually trying to do? Why can't you just use one trigger? If the units are pre-placed then you can just add the items to their drop table by double-clicking the unit.

My best guess is you're trying to make each of 2 different necromancers drop a different item?
  • ItemOfTheMagus
    • Events
      • Unit - A unit owned by Player 5 (Yellow) Dies
    • Conditions
      • (Unit-type of (Dying unit)) Equal to Elite Necromancer
    • Actions
      • If (All conditions are true) then do (Then actions) else do (else actions)
        • If - Conditions
          • CounterVar = 0 //hasn't been incremented
        • Then - Actions
          • Set ItemType = Robe of the Magi +6
          • Set CounterVar = (CounterVar + 1)
        • Else - Actions
          • Set ItemType = Sobi Mask
      • Set TempPoint003 = (Position of (Dying unit))
      • Item - Create ItemType at TempPoint003
      • Custom script: call RemoveLocation(udg_TempPoint003)
 
Level 16
Joined
May 2, 2011
Messages
1,345
You have two triggers with identical events and identical conditions, and one of them disables the other one when it runs. What are you actually trying to do? Why can't you just use one trigger? If the units are pre-placed then you can just add the items to their drop table by double-clicking the unit.

My best guess is you're trying to make each of 2 different necromancers drop a different item?
I guess your trigger will do.

each of my triggers disable itself. one of them is initially off. the first one will drop the item and then enable the other one.

I guess its just a trigger thing where the order of actions wont matter. my initial thought was that when I turn the second one on, only after that the trigger can fire. but they happen to fire similtanuously actually -_-!
 
Level 9
Joined
Jul 30, 2018
Messages
445
You just have to move the trigger higher, so that the second drop is ran before the first drop.

Sieppaa.PNG
 
Level 9
Joined
Jul 30, 2018
Messages
445
Yes. Most coding is so called procedural programming, so unless any given any other instruction, the code is ran line by line from top to the bottom. This works for individual actions inside a trigger as well as the triggers themselves. All the triggers are actually converted to one sheet of code all running after one other. (You can see this when you have an error in the code and you are prompted with the error window: there you can scroll the list and see that even all the GUI triggers are just "converted" to JASS and exist there just like all Custom Scripts would.)

Alternatively you could just have the drops inside the one trigger and run an if-statement. You would have to apply that same reverse order. For example:

  • If - Conditions
    • DropIndex equal 1
  • Then - Actions
    • Drop Item 2
  • If - Conditions
    • DropIndex equal 0
  • Then - Actions
    • Drop Item 1
    • Set DropIndex = 1
 
Level 9
Joined
Jul 30, 2018
Messages
445
This could very well be a 1.31 or newer feature. Pre 1.31 the order the triggers are run is the order the triggers were created and not the order they are in the trigger list.

Interesting. I have always just assumed it works this way. Never have needed to rearrange the triggers in such way, so never have gotten to test it. Well, this is a good example why such things would be better done inside one trigger: there at least one can be sure about the order in which the actions are ran.
 
Status
Not open for further replies.
Top