[Spell] Explosion Spell

[Lordliw]

Hello, I'm wondering how I can create a passive spell that when a unit (in this case abomination) dies, they explode and deal damage to enemy units. I saw some triggers for when a specific unit dies they do the kaboom spell, but this is not the case. I want it to be a custom spell and every trained abomination to explode and deal damage to enemy units, if they have the passive spell researched and not if the spell is not researched. And I want them to have the cinematic abomination explosion when they do explode (aka die). Thanks in advance to those who reply.

 

[Uncle]

Didn't test it out but I think this should work.

• Abom Death
  • Events
    • Unit - A unit Dies
  • Conditions
    • (Unit-type of (Triggering unit)) Equal to Abomination
    • (Current research level of Explode for (Triggering player)) Equal to 1
  • Actions
    • Custom script: local location udg_AbomPoint = Location( GetUnitX(GetTriggerUnit()), GetUnitY(GetTriggerUnit()) )
    • -------- --------
    • Special Effect - Create a special effect at AbomPoint using Units\Undead\Abomination\AbominationExplosion.mdl
    • Special Effect - Set Color of (Last created special effect) to color of (Triggering player)
    • Special Effect - Destroy (Last created special effect)
    • -------- --------
    • Custom script: set bj_wantDestroyGroup = true
    • Unit Group - Pick every unit in (Units within 300.00 of AbomPoint.) and do (Actions)
      • Loop - Actions
        • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
          • If - Conditions
            • ((Picked unit) is alive) Equal to True
            • ((Picked unit) belongs to an enemy of (Owner of (Triggering unit)).) Equal to True
          • Then - Actions
            • Unit - Cause (Triggering unit) to damage (Picked unit), dealing 500.00 damage of attack type Spells and damage type Normal
          • Else - Actions
    • -------- --------
    • Custom script: call RemoveLocation (udg_AbomPoint)
    • Custom script: set udg_AbomPoint = null

If it doesn't work then you probably need to change all cases of (Triggering player) to (Owner of (Triggering unit)).

The Conditions in the If Then Else statement determine which units the explosion can damage. I made it damage any living enemy units by default, but you can add more Conditions like Picked unit is a Structure Equal to False, Picked unit is a Ground unit Equal to True, etc.

You'll see that the Area of Effect of the explosion is 300.00, which is determined in the Unit Group - Pick every unit function.
The Damage of the explosion is 500.00 which is determined in the Unit - Cause Damage function.

The Explode Upgrade is based on Fragmentation Shards, which provides no additional effects besides enabling the explode ability.
The Explode ability is based on Storm Hammers, which provides no additional effects besides a Tooltip/Icon. This uses the Explode Upgrade as a Requirement.
The Trigger simply checks to see if the Explode Upgrade is Researched before running.

 

[Lordliw]

Hey, first of all, thank you so much for your response. But I'm quite having a problem with loading the .w3m file, is it for reforged or for classic? And I'm not the best with triggers, so the conditions are kind of bugging me, I don't know what is what and where to find the correct ones. Besides, can I make a custom passive spell out of it and wouldn't it be more easier that way?

 

[Cheshire]

is it for reforged

yep. won't be able to open on old patches.

can I make a custom passive spell out of it and wouldn't it be more easier that way?

If you mean using only the object editor - you can only use that to make spells that do pretty much the same thing as standard abilities do. If there is an ability in game that does exactly what you want but with slightly different stats, then you can alter it to do what you want. Otherwise you will have to trigger it (this is a slight over-simplification).

as a rule of thumb when fishing for the right condition - things that aren't obvious are often boolean comparisons. And when copying from another trigger - if is says "equal to true" at the end of it - it is indeed a boolean comparison.

 

[Lordliw]

Thanks. So I am mainly supposed to do this through triggers? Because I'm not good with them, especially conditions, even now I don't know what the second condition in the condition section it is. And does it matter if it's reforged or classic? I'm quite stuck with the trigger Uncle sent.

 

[Cheshire]

Afaik this trigger will work for you. there are a few new functions in reforged (or the patch before it), but none of them are used in this trigger.

the second condition in the condition section

an integer comparison. the research level is a whole number (=an integer).

 

[Uncle]

You can figure out what a Condition is by it's value.

• (Current research level of Explode for (Triggering player)) Equal to 1

That's an Integer comparison because the value is 1

• (Unit-type of (Triggering unit)) Equal to Abomination

That's a Unit-Type comparison because the value is a Unit-Type - like you'd find in the Object Editor
(not to be mixed up with a Unit comparison which is used to compare two specific units)

• ((Picked unit) is alive) Equal to True

That's a Boolean comparison because the value is either True or False

The most common conditions you'll find yourself using are:
Integer comparison - Whether something is Equal to or Not Equal to an integer value like 0, 1, 100. -> Is an ability level 3?
Real comparison - Whether something is Equal to or Not Equal to a real value like 0.1, 1.10, 100.00. -> Is the unit's life less than 50.00%?
Boolean comparison - Whether something is True or False. -> Is the unit alive? Is the unit owned by player 1? Is the player on team 1?

This holds true for Variables as well. Although in this case AbomPoint is confusing since I set it using Custom script (Jass).
But as you can see it's a Point variable as the name suggests.

Note that I'm using Custom script in order to prevent memory leaks as well as a special technique that allows pseudo-local variables. In this case the local variable was needed to prevent an issue when an Abomination would explode and deal lethal damage to another nearby Abomination causing that one to explode as well. If the trigger isn't designed in a way to handle this sort of chain reaction then things can go wrong. It takes a bit of practice and knowledge to figure out all of these edge cases but this is vital in making sure that your triggers are bug free.

Also, don't forget to use the Search For Text feature when looking for Actions. It can be very picky though so try different combinations of words or less words if nothing is showing up.

 

[Lordliw]

Nice, but in order to do this. Which spell am I gonna require in order to make this custom one with triggers? I presume I have to make an empty one, if it's possible.

 

[Uncle]

Nice, but in order to do this. Which spell am I gonna require in order to make this custom one with triggers? I presume I have to make an empty one, if it's possible.

Yep, Blizzard already has a few "empty" spells that they use in the core game. Take Storm Hammers for instance, it's just a Button that serves no purpose other than displaying a Tooltip and an Icon. The actual effects of Storm Hammer are handled in the Upgrade itself.

I updated my original post and went into greater detail concerning these things. My other post(s) should fill in the rest of the details.

 

[Lordliw]

Awesome. So what is the AbomPoint in your upper post? Is it a region or something? And if it is a region, where exactly?

 

[Cheshire]

its a point type variable. he set it in the first line of actions in custom script. If you don't want to CnP the line, you can create it with the GUI - set variable -> location of triggering unit.

 

[Lordliw]

Wait, but I want it to be for every trained abomination, not specifically one of them if it's a variable. If I understood that correctly.

 

[Cheshire]

a variable is just something we use as a placeholder, a pointer. every time an abomination dies and your trigger fires, it rewrites the definition of these temporary variables. you could have variables that you don't change the whole game, but the use of variables here is just to avoid memory leaks and to shorten the code (to not have to use - "location of (triggering unit)" every time you refer to it, but just "abompoint"). This will work for every abom that dies and has the ability.

 

[Lordliw]

Oh nice, how do I make that kind of variable, since I am practically very new to this type of triggering.

 

[Cheshire]

No problem, I was in your shoes not long ago. first you need to create the variable - you can do that easily by pressing the button with the green symbol on the top toolbar of the trigger editor. create a point type variable, and change it's name to what you want (triple click on it in the left panel to change the name). then, in the trigger add action-> set variable, and set the variable you created = location of triggering unit.

- also maybe read over this thread before asking the next question bc it seems like I'm repeating a lot of stuff uncle already wrote.

 

[Uncle]

I'd advise against using the GUI action and stick with the Custom script in this particular case. I'm using it to avoid a potential memory leak. To learn more about those check out -> Memory Leaks

All you need to do is create the AbomPoint variable inside of the Variable Editor (Control + D). Once the Variable "exists", it can be referenced in triggers.

In this case I reference it in the Custom script Action as well as some other places:

• Custom script: local location udg_AbomPoint = Location( GetUnitX(GetTriggerUnit()), GetUnitY(GetTriggerUnit()) )

Custom script is one of the easier things to recreate yourself. Simply highlight and copy this next line of text:
local location udg_AbomPoint = Location( GetUnitX(GetTriggerUnit()), GetUnitY(GetTriggerUnit()) )

Then paste it into a Custom script action.

• Custom script:

Also, make sure that your variable's name is AbomPoint, case sensitive.

 

[Cheshire]

I'd advise against using the GUI action and stick with the Custom script in this particular case. I'm using it to avoid a potential memory leak. To learn more about those I have a link in my signature (Things That Leak).

creating a variable there (location of triggering unit) and later destroying it still leaks?

 

[Lordliw]

Is this how it should be?

 

[Uncle]

Is this how it should be?

That's almost perfect, one of your Conditions is incorrect though.

Triggering unit belongs to an enemy of Owner of triggering unit -> Picked unit belongs to an enemy of Owner of triggering unit

Also -> How To Post Your Trigger

@Cheshire
If it's a global point variable then it can leak if the abomination's explosion damage causes the trigger to run again. That is if an exploding abom kills another exploding abom then the trigger will run again in the middle of the execution of the previous trigger.

This is where global variables run into problems as their values can be overwritten in these types of situations. That's why I use the Shadowing technique shown here -> local udg_

I'm converting AbomPoint into a local variable while still retaining it's ability to be referenced inside of GUI actions. The major downside of this method is that these "Shadowed" globals cannot be referenced in the Conditions block (so no using them in the Conditions of an If Then Else statement).
Fortunately, we don't need to do that here so it's not a problem.

It's arguably overkill to care this much about memory leaks but I figured it was a small enough trigger that it wouldn't hurt to use such an unusual solution. The trigger would still function properly if a Global Point variable was used, it would just have the potential to leak a Point.

 

[Lordliw]

Hey it works! Thank you so much! But there's a problem, the abomination has two death animations. The default one and the cinematic one, what do I do to remove the default one?

 

[Uncle]

Hey it works! Thank you so much! But there's a problem, the abomination has two death animations. The default one and the cinematic one, what do I do to remove the default one?

• Animation - Change (Triggering unit)'s vertex coloring to (100.00%, 100.00%, 100.00%) with 100.00% transparency

Try adding that to the trigger. You can place it right before you create the special effect.

 

[Lordliw]

It works. Thank you so so so so much! One more thing. The enemy abomination actually changes the color to mine when it dies, precisely on explosion when it plays the cinematic death animation, the color of it changes to mine, how do I fix that?

 

[Cheshire]

if an exploding abom kills another exploding abom then the trigger will run again in the middle of the execution of the previous trigger.

I thought instant triggers (no waits etc) never had to worry about this and it would always finish executing the current trigger first. Is this a multithreading thing?

 

[Uncle]

It works. Thank you so so so so much! One more thing. The enemy abomination actually changes the color to mine when it dies, precisely on explosion when it plays the cinematic death animation, the color of it changes to mine, how do I fix that?

Try changing Triggering Player to Owner of Triggering Unit in the change color Action. If that fixes it then make sure to change ALL instances of Triggering Player to Owner of Triggering Unit.

@Cheshire
The first trigger takes the Actions of the second trigger and inserts them right after the Action that caused the second trigger to run.

So for example:

• Unit - Cause (Triggering unit) to damage (Picked unit), dealing 500.00 damage of attack type Spells and damage type Normal

If that damage is lethal then any triggers that use the "A unit dies" Event will run right then and there.

• Unit - Cause (Triggering unit) to damage (Picked unit), dealing 500.00 damage of attack type Spells and damage type Normal
• INSERT ACTIONS HERE:
• A unit dies -> Set Point var, Create special effect, Pick every unit, etc.
• Point leaks because it's Set again before the original one was removed

 

[Lordliw]

Alright, wonderful. All is as it should be. But I do recall that the abominations don't use their death sound if they are killed by catapults, throwers, etc. But when they are killed like this, they do have one. Is it possible to turn it off somehow (if it's researched)?

 

[Uncle]

Alright, wonderful. All is as it should be. But I do recall that the abominations don't use their death sound if they are killed by catapults, throwers, etc. But when they are killed like this, they do have one. Is it possible to turn it off somehow (if it's researched)?

Well, you can Remove the unit to fix this. But that has the unwanted side effect of removing it's corpse as well. I assumed you wanted a corpse to remain behind so that's why I suggested adjusting it's transparency.

• Abom Death
  • Events
    • Unit - A unit Dies
  • Conditions
    • (Unit-type of (Triggering unit)) Equal to Abomination
    • (Current research level of Explode for (Owner of (Triggering unit)) Equal to 1
  • Actions
    • Custom script: local location udg_AbomPoint = Location( GetUnitX(GetTriggerUnit()), GetUnitY(GetTriggerUnit()) )
    • -------- --------
    • Special Effect - Create a special effect at AbomPoint using Units\Undead\Abomination\AbominationExplosion.mdl
    • Special Effect - Set Color of (Last created special effect) to color of (Owner of (Triggering unit))
    • Special Effect - Destroy (Last created special effect)
    • -------- --------
    • Custom script: set bj_wantDestroyGroup = true
    • Unit Group - Pick every unit in (Units within 300.00 of AbomPoint.) and do (Actions)
      • Loop - Actions
        • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
          • If - Conditions
            • ((Picked unit) is alive) Equal to True
            • ((Picked unit) belongs to an enemy of (Owner of (Triggering unit)).) Equal to True
          • Then - Actions
            • Unit - Cause (Triggering unit) to damage (Picked unit), dealing 500.00 damage of attack type Spells and damage type Normal
          • Else - Actions
    • Unit - Remove (Triggering unit) from the game
    • -------- --------
    • Custom script: call RemoveLocation (udg_AbomPoint)
    • Custom script: set udg_AbomPoint = null

^ Remove the Triggering unit right after the Pick every unit function.

Also, just to repeat in case you missed it:
Change ALL instances of Triggering Player to Owner of Triggering Unit.

 

[Lordliw]

Nevermind then. But there's another bug that just popped out. When I use a skill to kill an abomination, it changes the color to mine, but when I kill them with a physical attack (no spells) they keep their color. I think that's because I changed it to Owner of Triggering Unit for some triggers. Also, why is it important to change all of the instances to Owner of Triggering Unit?

 

[Uncle]

Nevermind then. But there's another bug that just popped out. When I use a skill to kill an abomination, it changes the color to mine, but when I kill them with a physical attack (no spells) they keep their color. I think that's because I changed it to Owner of Triggering Unit for some triggers. Also, why is it important to change all of the instances to Owner of Triggering Unit?

Triggering Player may refer to the wrong player. Owner of Triggering Unit is the player that owns the dying unit.

And idk about that bug, I'd have to know which skill killed the abomination and what other triggers you use.

 

[Lordliw]

Finger of Death, and those are the only triggers I used.

 

[Cheshire]

The first trigger takes the Actions of the second trigger and inserts them right after the Action that caused the second trigger to run.

So for example:

• 
  Unit - Cause (Triggering unit) to damage (Picked unit), dealing 500.00 damage of attack type Spells and damage type Normal

If that damage is lethal then any triggers that use the "A unit dies" Event will run right then and there.

• 
  Unit - Cause (Triggering unit) to damage (Picked unit), dealing 500.00 damage of attack type Spells and damage type Normal
• 
  INSERT ACTIONS HERE:
• 
  A unit dies -> Set Point var, Create special effect, Pick every unit, etc.
• 
  Point leaks because it's Set again before the original one was removed

that is very strange.

so in the case of your example it would only "come back" and finish the execution of the first trigger after it finishes the second trigger. I don't get why that takes precedence and the default isn't to finish the current trigger first (unless it encounters waits and stuff). GUI is a strange and fickle beast (and my previous maps are probably broken... ).

edit: oh, and sorry for hijacking your thread @Lordliw

 

[Lordliw]

It's not a problem Cheshire.

 

[Lordliw]

It looks like there hasn't been a message in a while. I want to say that the abomination doesn't change the color to my color when I use finger of death to kill it. It just changes it to red for some reason, any ideas why?

 

[Daffa]

It looks like there hasn't been a message in a while. I want to say that the abomination doesn't change the color to my color when I use finger of death to kill it. It just changes it to red for some reason, any ideas why?

Finger of Death has been notable for being weird in its behavior. Anyway, is your alliance setting set to the one where all player colors are shown properly?

 

[Lordliw]

I don't know where that is?

 

[Cheshire]

by the minimap there are different buttons - one of them sets the ally display color. (so you are blue allies teal, enemies red - that stuff). sometimes if you are not on the setting that shows your true player color it can be buggy.

 

[Lordliw]

Yeah, they are set properly.