Sooda
Diversity enchants
- Reaction score
- 318
It should be moved to Graveyard. Last time I made "tutorial" too short, now I have managed to make it too long without reaching to parts which I wanted to explain.
I started it because in my opinion MUI and waits deserve tutorials. There aren't any of them and many people are asking how to do this or that MUi in GUI. There is local variable tutorials, but it is possible to make MUI also with global variables.
Then there is problem with handle variables, outdated 'memory leak' tutorials suggest to destroy everything after use, JASS'ers know it isn't like that. It is touched in 'Variable' part of this wannabe tutorial.
If there are any who are able to make short and understandable tutorial about 'how trigger works -- MUI' go ahead, knowledge to masses
That is what I try to do. Maybe I go on third attempt and try to make light version -- short and informative.
This wall of text explains basics which most of you know. Only very detailed, step by step. I hope maybe someone finds this when they search forum, could be handy for informative purposes:
Triggered Abilities: Know How
by Sooda
Point of this tutorial is to teach writing triggered abilities. It is meant for beginners with no experience
with editor. Tutorial basic part explains how triggers are made and work while second part concentrates
on specific ability types. Tutorial is written from beginner to beginner style.
Table of Content
Tutorial Basic Part:
1. Trigger
2. Variables
3. How variables work
4. Commonly used action functions (actions)
1. Triggers
Triggers are used to create abilities which do not exist in game. Trigger itself is made of three parts --
events, conditions and actions.
Events
Event is alarm which activates when something happens in game. For example event is unit casting ability. Specific event which you add to your trigger allows you to access only that event responses. Lets look commonly used event in triggered abilities like:
This event fires after unit uses ability. When ability is used required mana is removed and ability starts to cool down. Event unlocks three event responses:
In conditions event response -- ability being cast. It shows which ability cast fired trigger.
In actions two event responses unlock. First is casting unit which points to unit who used ability and second is:
This event response points to target on who ability was used.
You can add different events to same trigger. All added events are capable of firing trigger, but never more than one event fires trigger at same time. It means from many events only one fires trigger and that event responses become unlocked.
Conditions
Conditions allow or deny further trigger firing. They are questions about trigger event. If you can answer to all questions true trigger continues else trigger stops there. In conditions you can use additionally to event responses functions. Great is that functions are not connected to events in any way. That means you can use them independently from events. In condition functions allow you to access to info what is happening on map when event fires. From now on we are using functions combined with event responses. Conditions are divided into main groups. First pops up boolean conditions. These are questions which can answered only true or false. Good example would be:
This is boolean condition and asks is ability target enemy. We use 'Target unit of ability being cast' and 'Casting unit' which are specific event responses. Remember how other unrelated event responses are locked? I do not risk to give wrong example as people remember such things better.
Then there are numeric conditions. They consist of integers and reals. Integers are numbers like -23, -1, 0, 1, 5, 8, 11, 1001, etc. Integer condition is this:
Condition asks is ability level 1. For that we use ability function which compares ability level on caster with our integer which is 1. Ability on unit can not be 1.5. Though it can be 1 or 2, 3, 4, 5, ... and so on.
1.5 is actually a real number. Notice the '.5' part? Such look real numbers. More real numbers: 0.9; 5.678; -109.439; 17892.23, -10.9, etc. Now difference between integer and real numbers should be more clear.
Unit healt, mana and move speed use real number, they are only few which use reals. Here is real number condition:
Condition asks: "Is enemy life less than 300 health? ". For that we used unit function which gives us info about its state. Using 'Target unit of ability being cast' as unit whos life we check, which is familiar event response from previous examples.
From conditions remember all conditions need to be true else trigger actions will not run. Condition functions are independent from event itself. They give you info about things on map. To remind only relevant event responses can be used which connect with trigger event.
Actions
Actions let you create or modify existing things. When you create unit you can refer back to it until you create new unit. Example helps much:
It creates unit, Footman for player 1 at center of map. Next lets make him invurnable. New unit gets stored to function 'Last Created Unit':
This does our created unit invurnable, keep in mind that 'Last Created Unit' stores only newest unit created on map. When we would create after those actions new unit, Knight then 'Last Created Unit' points to knight from now, lets make him also invurnable:
That makes both of them invurnable. By doing so we lost chance to refer back to Footman, currently only Knight is available to us. Do not worry there are many ways to control Footman again which will be explained later. It is important that you understand how 'Last Created Unit' works. There are many other things which you can create and refer back same way.
Most triggered abilities use dummy unit to cast abilities on targets. Dummy unit is transparent, invurnable with no collision size immobile unit which has plenty mana with maximum mana regeneration. Pretty mighty wizard I must say. That unit needs to be set up in Object Editor first. I write down what you have to change on Flying Sheep to turn it into dummy unit. I picked Flying Sheep because few modifications need to be done.
Open Object Editor (F6 key) and press Crtl + G and type in name: 'Flying Sheep' (without '', also you can press Crtl + G for next match while searching) now copy paste Flying Sheep and start to change fields on copy:
Abilities - Normal: Delete everything from there and replace with ability called Locust (press letter 'L' on keyboard for faster search).
Art - Has Water Shadow: False
Art - Model File: Elevator Wall <Base>, ... (under Destructible category)
Movement - Type: None
Sound - Random: None
Sound - Unit Sound Set: None
Stats - Can Flee: False
Stats - Hide Minimap Display: True
Stats - Hit Points Maximum (Base): 500 000 (type in 999999 and press 'OK', it snaps to max value)
Stats - Hit Points Regeneration Rate: 1000
Stats - Mana Initaial Amount: 100 000
Stats - Mana Maximum: 100 000
Stats - Mana Regeneration: 1000
Stats - Sight Radius (Day): 0
Stats - Sight Radius (Night): 0
Text - Name: Dummy Unit
Path to Dummy Unit in Unit Palette is: Neutral Passive > Neautral > Custom > Special > Dummy Unit
For practise we make simple ability which on cast damages nearby enemies with poison. I choose for my base ability Night Elf Roar because it is with area of effect (AoE) ability with instant cast (player does not need to choose target):
Caster spends mana, cool down starts and ability used was Roar, simple enough. In actions it gets more complicated. We pick all enemy units around caster first. In 'Pick Every Unit In' exists similar function like 'Last Created Unit' instead it is called 'Matching Unit'. It is unit who is in range and is checked for conditions. If every check (condition) gives true answer actions are done to that unit:
It checks all units one by one in circular area. When it finds unit who is enemy of caster it wants to do instantly actions to him. I will cast on found enemy Shadow Strike (Neutral Hostile). Here comes into play Dummy Unit, we create for each enemy dummy unit and order him to cast ability. Dummy Unit
has no abilities himself exept Locust. Lets give Shadow Strike to dummy too:
Per each found enemy Dummy unit is created for owner of caster. Then to newly created unit is given neutral hostile Shadow Strike. Now 'Picked Unit' needs explaining. In condition we used 'Matching Unit' that now in actions becomes 'Picked Unit'. They both point to same unit -- the choosen enemy from area. Important is to know that they can not replace each others. 'Picked Unit' only works in Actions part and 'Matching Unit' only in Conditions part of 'Pick Every Unit In'. Think it as being unsure is it right man, if we have made it sure (he passed conditions, which gave true answers). He is marked as 'Picked Unit' and green light is given -- do what you want in 'Actions' part now. Prison example, I' m not relly happy about it. Remember that 'Matching Unit' can only be used in conditions and 'Picked Unit' is meant to be used only in 'Group Pick Every Unit In' actions. 'Picked Unit' does not work outside of that function.
Common thing to do with un-necessary dummy units is to give them life time which takes care of them. Because our ability is with instant nature we do not need to give them long life, three seconds is more than enough. That was last thing in our very first triggered ability:
Ordinary Roar is enchanted with poison now, your enemies will fear it. Go try it in game and feel proud of yourself -- you have made very first triggered ability. Very well done, take a good rest and when you feel ready come back and continue with tutorial.
2. Variables
First many good tutorials about variables exist at thehelper.net tutorial repository. I suggest you to check them out. I try to explain them myself too and I have took many tricks from already existing ones. Credits to them for that.
Variable is like bag, its purpose is to store things which you can later use. You can access from Trigger
Editor (F4) to Variable Editor (Crtl + B). It is good tradition to give variable descriptive names, it helps you afterwards remember what purpose each variable has in trigger.
There are different variable (bag) types to store different things like units, unit groups, players, player groups, numbers (integer and real) and booleans (true or false values), special effects and many more. Which I just counted are mostly used in triggered abilities.
Open Variable Editor and lets make unit type variable. Because you can not have many variables with
same name prefix is used to distinguish them. It has become tradition to use your shorten form of triggered ability name as prefix. We are going to store Venoumous Roar caster to variable with name:
It follows most variable naming rules -- variable name starts with always lower case letter, each new word starts with upercase letter, has prefix which is separated with underscore,describes which that variable stores.
Choose from 'Variable Type' menu 'Unit' -- it makes our variable (bag) unit type. Means only units can be stored to that variable. Do not tick box which says 'Array', I will explain which it does bit later. 'Initial Value' allows you to give it starting value, we do not need it now and let it be 'None'.
Best thing about variables is that they can be accessed from any trigger, they are not like event responses which work only with specific trigger. For practise we make configuration trigger which runs at map initialization and sets up our Venomous Roar triggered ability and some speed tweaks inside ability trigger with variables.
We will change our so far trigger build to make it better than before. You could change same trigger
or when started to read from here follow me and make it from scratch. Trigger starts like this:
This stores our caster to unit variable which we can use from now on instead of event response. First of using variable makes trigger bit faster to run (I know it is not car tuning contest, but still) and more dynamic. When we add more variables it becomes clear how exactly more dynamic. Do not forget that
as first thing you have to set variable value like we did before you can start to use variable!
Now we modify trigger condition to use variable. For that create variable named 'venoRoar_abilId' (without '', 'abil' is short for ability and Id stands for identification). Now these things clear we can aproach to our configuration trigger. Pick from variable type ability, it behaves similary like unit variable but instead of unit it can only store abilities. When done, hit 'OK' button. Create new trigger and name it 'Venomous Roar Config', we want this trigger to run on map initialization to set things up before units actually can use our triggered ability:
Configuration trigger seems empty, but soon we add more things. Lets go back to Venomous Roar trigger and change our condition to use variable instead of preset robust ability:
If you have hard time finding where to choose variable it is located at top when box pops up. It is strange to see instead of ability some variable name and here comes handy when they got descriptive and still short names.
As you noticed before our ability did not had any levels, lets make it levelable hero ability. Hero level
can be stored to integer variable (Integers are numbers like -2; -1; 0; 1; 2; 3; 10; etc). Name variable like 'venoRoar_abilLevel'. Now comes interesting line:
It might seem even confusing at start. It stores current Roar level for caster to integer variable. I can tell that for such things you start to love variables later. 'venoRoar_caster' holds unit who cast ability, we set that variable to hold caster line before and 'venoRoar_abilId' holds Roar ability which we set from another trigger at map initialization. It should make sense how we set ability level variable now.
Lets make our ability to do even more initial damage when cast. Time to show how variable array is used. Create variable of type real named 'venoRoar_baseDmg' and tick box which says array. It enables you to choose array size. Array is bunch of similar variables (bags), each having their unique number. It helps to pick right one (variable) afterwards from stack when you need to use exactly that variable and no other one. Remember how I told to first set variable to some value before you use it. It is because otherwise you can not use them and when still used in trigger, it breaks trigger. We do not want to break our trigger and that is why we always set variable value before we use it (Hugh... was long sentence).
Hero abilities usually have 3 levels, we need variable array with 3 indexes. For practise set array number to 3. It makes all three variables use same starting value which by default is 0. Like that it is safer, it reminds me user from our forum who had in his custom title: "Safety never takes holiday, Malcop." or similar). Array index number 4 stays empty and when used like that in trigger breaks trigger. No need to give each array index from 0 to 8191 (which is maximum) starting value. With some practise you know exactly which arrays you need to set and which not. To be honest we will now set that array to our values:
Instead of making three separate real variables we have one real variable array where they are all together. Each real variable in that array can be accessed by using number (they range from 0 to 8191). We use here hero ability level and variable index similarity (Index is called number between [] -- [1] is index number one). Each ability level on hero when used as array index gives us always specific value -- level 1 gives 100.00, level 2 gives 150.00, level 3 gives 200.00 and so on. You will be using often this similarity in your future triggered abilities. Now it is safe to use these three array indexes. It is up to you will you give arrays same starting value in Variable Editor or in our case you could had only ticked 'Array' box and leaved array size to 1 and manually set needed array indexes to value before we actually start to use them.
Trigger Editor has its flaws like we all and with each cast all enemies are picked and put to unit group, afterwards that unit group gets lost. We can avoid it by using same unit group variable over and over again. First of all condition which finds us enemies in range uses player function. For better performance we can store that player to player variable and use variable instead of function. That function always gives same player -- owner of caster. When we use player variable instead we save much repetitive function calls. You should be familiar how to create variables for now, create player variable and name it 'venoRoar_casterOwner', we set first variable to store caster owner before we use it again:
Familiar to our technique where we use variables as much as possible if they are before given value?
Player variable is set up to use in condition. Now we create unit group variable and name it 'venoRoar_enemyGroup'. As first thing we each time clean that group to remove enemies from earlier cast, of course with first cast there are no units in unit group, but from there on old enemies stay in that unit group until new cast cleans unit group variable before use again:
When variable is empty we find new enemies around caster and store them to that variable. 'Matching unit' is explained in trigger tutorial and if you do not know what it does read it before continuing (Simple search text and read bit about 'Matching Unit' and 'Picked Unit'):
All enemies in range have been caught and next we can damage them, not much, just little bit so they do not have will to attack our hero anymore in long time.
For that we use 'Pick every unit in <unit group> action, from popup menu choose variable from top named 'venoRoar_enemyGroup':
As you can see we short out enemies one line before and now for each enemy in that group we do damage. In loop actions we store 'Picked Unit' to variable and use that variable, again its faster, better and more dynamic that way. For that we create unit variable named 'venoRoar_enemy':
Now in all loop action we are going to use our previously set variables as much as possible:
becomes to:
stays same,
becomes:
We set up additional damage per level in our configuration trigger, it would be good time to do that extra damage now. Again we use mostly variables:
That line damages 'enemy' by 'caster'. How much exactly damage is done depends on this part 'venoRoar_baseDmg[venoRoar_abilLevel]', you know that ' venoRoar_baseDmg' was array with size of 3. ' venoRoar_abilLevel' variable holds caster ability level which can be from 1 to 3. When you replace in mind ' venoRoar_abilLevel' with number from 1 t o3 it should make sense how much damage caster can do.
As last loop action we add expiration timer to our dummy unit:
That is it, we have successfully converted our first trigger version to use variables. To sum things
up variables need to be first set before you can use them or they will break trigger. Variable array
is collection of same variable types with each having their unique array number. Array size ranges
from 0 to 8191. For memorizing -- ' venoRoar_baseDmg [1]' where 'venoRoar_baseDmg' is variable array and '[1]' is unique array number also called array index.
Changed triggered ability now looks this:
I suggests you to take good rest now and come back when you are ready again.
3. How variables work
This part promises to be short. Actually there is not much to learn how variables work. When you create unit on empty map and store it to unit variable then that variable is called pointer. Why so?
Because there is only one unit, you can set many variables to hold that unit. But that does not multiple
unit on map! All variables and that unit are connected -- all variables point to same unit. Now when ever you use one of those variables it affects only that unit on map. Simple example shows what I am trying to tell here:
'exampleUnit_1' and 'exampleUnit_2' are both unit variables:
It creates on map initialization (map loading) at centre of map one Footman. Then sets first unit variable to that Footman and second unit variable also to Footman.
That action only made both variables to point Footman -- whatever I do to these variables affects our Footman directly. On map there is only one Footman that action did not produce second Footman on map.
Now our test trigger which shows how these two variables and Footman are connected:
Though we kill unit in variable 'exampleUnit_1' which is Footman and check different variable named 'exampleUnit_2' it still shows message! That is because both variables point to same unit. First action kills unit and now its dead, other variable points to exactly same unit and 'Footman (exampleUnit_2) is dead Equal to True'.
Footman is object -- a game object. All things which you can create and destroy are objects. These objects are reffered with pointer variables. When you do something with one variable it affects instantly all other variables which point to same object in our case Footman.
Then there are independent variables like integer, real, boolean and some others. They are not connected with object and stand alone. When you do something to that variable it only affects that variable and no others. Example:
'startNumber', 'numberOne' and 'NumberTwo' are integer variables.
It shows that even when I set two variables from same variable they are independent. I give new value to second variable and it does not change first variable value -- that is difference between 'create/ destroy' variables and independent variables.
To sum it up 'create/ destroy' variables point to game objects like Footman. Independent variables like integer, real and boolean which you can not create but only set are independent. Changing one of such variables only changes that particular variable and not others.
Unit group can be created which makes it game object and when you destroy it from one pointer variable (unit group variable) all other unit group variables which point to same unit group also become empty -- not set, without value (null). From variable part we know that unset variable breaks trigger. That is common mistake done my beginners. Many triggered abilities may stop working because of that silly mistake. Try to avoid it.
4. Commonly used action functions (actions)
(For Variable Loop, For Loop, timer)
I started it because in my opinion MUI and waits deserve tutorials. There aren't any of them and many people are asking how to do this or that MUi in GUI. There is local variable tutorials, but it is possible to make MUI also with global variables.
Then there is problem with handle variables, outdated 'memory leak' tutorials suggest to destroy everything after use, JASS'ers know it isn't like that. It is touched in 'Variable' part of this wannabe tutorial.
If there are any who are able to make short and understandable tutorial about 'how trigger works -- MUI' go ahead, knowledge to masses
That is what I try to do. Maybe I go on third attempt and try to make light version -- short and informative.This wall of text explains basics which most of you know. Only very detailed, step by step. I hope maybe someone finds this when they search forum, could be handy for informative purposes:
Triggered Abilities: Know How
by Sooda
Point of this tutorial is to teach writing triggered abilities. It is meant for beginners with no experience
with editor. Tutorial basic part explains how triggers are made and work while second part concentrates
on specific ability types. Tutorial is written from beginner to beginner style.
Table of Content
Tutorial Basic Part:
1. Trigger
2. Variables
3. How variables work
4. Commonly used action functions (actions)
1. Triggers
Triggers are used to create abilities which do not exist in game. Trigger itself is made of three parts --
events, conditions and actions.
Events
Event is alarm which activates when something happens in game. For example event is unit casting ability. Specific event which you add to your trigger allows you to access only that event responses. Lets look commonly used event in triggered abilities like:
Trigger:
- Events
- Unit - A unit Starts the effect of an ability
This event fires after unit uses ability. When ability is used required mana is removed and ability starts to cool down. Event unlocks three event responses:
Trigger:
- Conditions
- (Ability being cast) Equal to Storm Bolt
In conditions event response -- ability being cast. It shows which ability cast fired trigger.
Trigger:
- Actions
- Unit - Set life of (Casting unit) to 100.00%
In actions two event responses unlock. First is casting unit which points to unit who used ability and second is:
Trigger:
- Actions
- Unit - Set life of (Target unit of ability being cast) to 100.00%
This event response points to target on who ability was used.
You can add different events to same trigger. All added events are capable of firing trigger, but never more than one event fires trigger at same time. It means from many events only one fires trigger and that event responses become unlocked.
Conditions
Conditions allow or deny further trigger firing. They are questions about trigger event. If you can answer to all questions true trigger continues else trigger stops there. In conditions you can use additionally to event responses functions. Great is that functions are not connected to events in any way. That means you can use them independently from events. In condition functions allow you to access to info what is happening on map when event fires. From now on we are using functions combined with event responses. Conditions are divided into main groups. First pops up boolean conditions. These are questions which can answered only true or false. Good example would be:
Trigger:
- ((Target unit of ability being cast) belongs to an enemy of (Owner of (Casting unit))) Equal to True
This is boolean condition and asks is ability target enemy. We use 'Target unit of ability being cast' and 'Casting unit' which are specific event responses. Remember how other unrelated event responses are locked? I do not risk to give wrong example as people remember such things better.
Then there are numeric conditions. They consist of integers and reals. Integers are numbers like -23, -1, 0, 1, 5, 8, 11, 1001, etc. Integer condition is this:
Trigger:
- (Level of Storm Bolt for (Casting unit)) Equal to 1
Condition asks is ability level 1. For that we use ability function which compares ability level on caster with our integer which is 1. Ability on unit can not be 1.5. Though it can be 1 or 2, 3, 4, 5, ... and so on.
1.5 is actually a real number. Notice the '.5' part? Such look real numbers. More real numbers: 0.9; 5.678; -109.439; 17892.23, -10.9, etc. Now difference between integer and real numbers should be more clear.
Unit healt, mana and move speed use real number, they are only few which use reals. Here is real number condition:
Trigger:
- (Life of (Target unit of ability being cast)) Less than 300.00
Condition asks: "Is enemy life less than 300 health? ". For that we used unit function which gives us info about its state. Using 'Target unit of ability being cast' as unit whos life we check, which is familiar event response from previous examples.
From conditions remember all conditions need to be true else trigger actions will not run. Condition functions are independent from event itself. They give you info about things on map. To remind only relevant event responses can be used which connect with trigger event.
Actions
Actions let you create or modify existing things. When you create unit you can refer back to it until you create new unit. Example helps much:
Trigger:
- Actions
- Unit - Create 1 Footman for Player 1 (Red) at (Center of (Playable map area)) facing Default building facing degrees
It creates unit, Footman for player 1 at center of map. Next lets make him invurnable. New unit gets stored to function 'Last Created Unit':
Trigger:
- Unit - Make (Last created unit) Invulnerable
This does our created unit invurnable, keep in mind that 'Last Created Unit' stores only newest unit created on map. When we would create after those actions new unit, Knight then 'Last Created Unit' points to knight from now, lets make him also invurnable:
Trigger:
- Actions
- Unit - Create 1 Footman for Player 1 (Red) at (Center of (Playable map area)) facing Default building facing degrees
- Unit - Make (Last created unit) Invulnerable
- Unit - Create 1 Knight for Player 1 (Red) at (Center of (Playable map area)) facing Default building facing degrees
- Unit - Make (Last created unit) Invulnerable
That makes both of them invurnable. By doing so we lost chance to refer back to Footman, currently only Knight is available to us. Do not worry there are many ways to control Footman again which will be explained later. It is important that you understand how 'Last Created Unit' works. There are many other things which you can create and refer back same way.
Most triggered abilities use dummy unit to cast abilities on targets. Dummy unit is transparent, invurnable with no collision size immobile unit which has plenty mana with maximum mana regeneration. Pretty mighty wizard I must say. That unit needs to be set up in Object Editor first. I write down what you have to change on Flying Sheep to turn it into dummy unit. I picked Flying Sheep because few modifications need to be done.
Open Object Editor (F6 key) and press Crtl + G and type in name: 'Flying Sheep' (without '', also you can press Crtl + G for next match while searching) now copy paste Flying Sheep and start to change fields on copy:
Abilities - Normal: Delete everything from there and replace with ability called Locust (press letter 'L' on keyboard for faster search).
Art - Has Water Shadow: False
Art - Model File: Elevator Wall <Base>, ... (under Destructible category)
Movement - Type: None
Sound - Random: None
Sound - Unit Sound Set: None
Stats - Can Flee: False
Stats - Hide Minimap Display: True
Stats - Hit Points Maximum (Base): 500 000 (type in 999999 and press 'OK', it snaps to max value)
Stats - Hit Points Regeneration Rate: 1000
Stats - Mana Initaial Amount: 100 000
Stats - Mana Maximum: 100 000
Stats - Mana Regeneration: 1000
Stats - Sight Radius (Day): 0
Stats - Sight Radius (Night): 0
Text - Name: Dummy Unit
Path to Dummy Unit in Unit Palette is: Neutral Passive > Neautral > Custom > Special > Dummy Unit
For practise we make simple ability which on cast damages nearby enemies with poison. I choose for my base ability Night Elf Roar because it is with area of effect (AoE) ability with instant cast (player does not need to choose target):
Trigger:
- Venomous Roar
- Events
- Unit - A unit Starts the effect of an ability
- Conditions
- (Ability being cast) Equal to Roar
- Actions
- Events
Caster spends mana, cool down starts and ability used was Roar, simple enough. In actions it gets more complicated. We pick all enemy units around caster first. In 'Pick Every Unit In' exists similar function like 'Last Created Unit' instead it is called 'Matching Unit'. It is unit who is in range and is checked for conditions. If every check (condition) gives true answer actions are done to that unit:
Trigger:
- Actions
- Unit Group - Pick every unit in (Units within 512.00 of (Position of (Casting unit)) matching (((Matching unit) belongs to an enemy of (Owner of (Casting unit))) Equal to True)) and do (Actions)
- Loop - Actions
- Unit Group - Pick every unit in (Units within 512.00 of (Position of (Casting unit)) matching (((Matching unit) belongs to an enemy of (Owner of (Casting unit))) Equal to True)) and do (Actions)
It checks all units one by one in circular area. When it finds unit who is enemy of caster it wants to do instantly actions to him. I will cast on found enemy Shadow Strike (Neutral Hostile). Here comes into play Dummy Unit, we create for each enemy dummy unit and order him to cast ability. Dummy Unit
has no abilities himself exept Locust. Lets give Shadow Strike to dummy too:
Trigger:
- Unit Group - Pick every unit in (Units within 512.00 of (Position of (Casting unit)) matching (((Matching unit) belongs to an enemy of (Owner of (Casting unit))) Equal to True)) and do (Actions)
- Loop - Actions
- Unit - Create 1 Dummy Unit for (Owner of (Casting unit)) at (Position of (Picked unit)) facing Default building facing degrees
- Unit - Add Shadow Strike (Neutral Hostile) to (Last created unit)
- Unit - Order (Last created unit) to Night Elf Warden - Shadow Strike (Picked unit)
- Loop - Actions
Per each found enemy Dummy unit is created for owner of caster. Then to newly created unit is given neutral hostile Shadow Strike. Now 'Picked Unit' needs explaining. In condition we used 'Matching Unit' that now in actions becomes 'Picked Unit'. They both point to same unit -- the choosen enemy from area. Important is to know that they can not replace each others. 'Picked Unit' only works in Actions part and 'Matching Unit' only in Conditions part of 'Pick Every Unit In'. Think it as being unsure is it right man, if we have made it sure (he passed conditions, which gave true answers). He is marked as 'Picked Unit' and green light is given -- do what you want in 'Actions' part now. Prison example, I' m not relly happy about it. Remember that 'Matching Unit' can only be used in conditions and 'Picked Unit' is meant to be used only in 'Group Pick Every Unit In' actions. 'Picked Unit' does not work outside of that function.
Common thing to do with un-necessary dummy units is to give them life time which takes care of them. Because our ability is with instant nature we do not need to give them long life, three seconds is more than enough. That was last thing in our very first triggered ability:
Trigger:
- Venomous Roar
- Events
- Unit - A unit Starts the effect of an ability
- Conditions
- (Ability being cast) Equal to Roar
- Actions
- Unit Group - Pick every unit in (Units within 512.00 of (Position of (Casting unit)) matching (((Matching unit) belongs to an enemy of (Owner of (Casting unit))) Equal to True)) and do (Actions)
- Loop - Actions
- Unit - Create 1 Dummy Unit for (Owner of (Casting unit)) at (Position of (Picked unit)) facing Default building facing degrees
- Unit - Add Shadow Strike (Neutral Hostile) to (Last created unit)
- Unit - Order (Last created unit) to Night Elf Warden - Shadow Strike (Picked unit)
- Unit - Add a 3.00 second Generic expiration timer to (Last created unit)
- Loop - Actions
- Unit Group - Pick every unit in (Units within 512.00 of (Position of (Casting unit)) matching (((Matching unit) belongs to an enemy of (Owner of (Casting unit))) Equal to True)) and do (Actions)
- Events
Ordinary Roar is enchanted with poison now, your enemies will fear it. Go try it in game and feel proud of yourself -- you have made very first triggered ability. Very well done, take a good rest and when you feel ready come back and continue with tutorial.
2. Variables
First many good tutorials about variables exist at thehelper.net tutorial repository. I suggest you to check them out. I try to explain them myself too and I have took many tricks from already existing ones. Credits to them for that.
Variable is like bag, its purpose is to store things which you can later use. You can access from Trigger
Editor (F4) to Variable Editor (Crtl + B). It is good tradition to give variable descriptive names, it helps you afterwards remember what purpose each variable has in trigger.
There are different variable (bag) types to store different things like units, unit groups, players, player groups, numbers (integer and real) and booleans (true or false values), special effects and many more. Which I just counted are mostly used in triggered abilities.
Open Variable Editor and lets make unit type variable. Because you can not have many variables with
same name prefix is used to distinguish them. It has become tradition to use your shorten form of triggered ability name as prefix. We are going to store Venoumous Roar caster to variable with name:
Code:
venoRoar_casterChoose from 'Variable Type' menu 'Unit' -- it makes our variable (bag) unit type. Means only units can be stored to that variable. Do not tick box which says 'Array', I will explain which it does bit later. 'Initial Value' allows you to give it starting value, we do not need it now and let it be 'None'.
Best thing about variables is that they can be accessed from any trigger, they are not like event responses which work only with specific trigger. For practise we make configuration trigger which runs at map initialization and sets up our Venomous Roar triggered ability and some speed tweaks inside ability trigger with variables.
We will change our so far trigger build to make it better than before. You could change same trigger
or when started to read from here follow me and make it from scratch. Trigger starts like this:
Trigger:
- Venomous Roar
- Events
- Unit - A unit Starts the effect of an ability
- Conditions
- (Ability being cast) Equal to Roar
- Actions
- Set venoRoar_caster = (Casting unit)
- Events
This stores our caster to unit variable which we can use from now on instead of event response. First of using variable makes trigger bit faster to run (I know it is not car tuning contest, but still) and more dynamic. When we add more variables it becomes clear how exactly more dynamic. Do not forget that
as first thing you have to set variable value like we did before you can start to use variable!
Now we modify trigger condition to use variable. For that create variable named 'venoRoar_abilId' (without '', 'abil' is short for ability and Id stands for identification). Now these things clear we can aproach to our configuration trigger. Pick from variable type ability, it behaves similary like unit variable but instead of unit it can only store abilities. When done, hit 'OK' button. Create new trigger and name it 'Venomous Roar Config', we want this trigger to run on map initialization to set things up before units actually can use our triggered ability:
Trigger:
- Venomous Roar Config
- Events
- Map initialization
- Conditions
- Actions
- Set venoRoar_abilId = Roar
- Events
Configuration trigger seems empty, but soon we add more things. Lets go back to Venomous Roar trigger and change our condition to use variable instead of preset robust ability:
Trigger:
- Venomous Roar
- Events
- Unit - A unit Starts the effect of an ability
- Conditions
- (Ability being cast) Equal to venoRoar_abilId
- Actions
- Set venoRoar_caster = (Casting unit)
- Events
If you have hard time finding where to choose variable it is located at top when box pops up. It is strange to see instead of ability some variable name and here comes handy when they got descriptive and still short names.
As you noticed before our ability did not had any levels, lets make it levelable hero ability. Hero level
can be stored to integer variable (Integers are numbers like -2; -1; 0; 1; 2; 3; 10; etc). Name variable like 'venoRoar_abilLevel'. Now comes interesting line:
Trigger:
- Venomous Roar
- Events
- Unit - A unit Starts the effect of an ability
- Conditions
- (Ability being cast) Equal to venoRoar_abilId
- Actions
- Set venoRoar_caster = (Casting unit)
- Set venoRoar_abilLevel = (Level of venoRoar_abilId for venoRoar_caster)
- Events
It might seem even confusing at start. It stores current Roar level for caster to integer variable. I can tell that for such things you start to love variables later. 'venoRoar_caster' holds unit who cast ability, we set that variable to hold caster line before and 'venoRoar_abilId' holds Roar ability which we set from another trigger at map initialization. It should make sense how we set ability level variable now.
Lets make our ability to do even more initial damage when cast. Time to show how variable array is used. Create variable of type real named 'venoRoar_baseDmg' and tick box which says array. It enables you to choose array size. Array is bunch of similar variables (bags), each having their unique number. It helps to pick right one (variable) afterwards from stack when you need to use exactly that variable and no other one. Remember how I told to first set variable to some value before you use it. It is because otherwise you can not use them and when still used in trigger, it breaks trigger. We do not want to break our trigger and that is why we always set variable value before we use it (Hugh... was long sentence).
Hero abilities usually have 3 levels, we need variable array with 3 indexes. For practise set array number to 3. It makes all three variables use same starting value which by default is 0. Like that it is safer, it reminds me user from our forum who had in his custom title: "Safety never takes holiday, Malcop." or similar
). Array index number 4 stays empty and when used like that in trigger breaks trigger. No need to give each array index from 0 to 8191 (which is maximum) starting value. With some practise you know exactly which arrays you need to set and which not. To be honest we will now set that array to our values:Trigger:
- Venomous Roar Config
- Events
- Map initialization
- Conditions
- Actions
- Set venoRoar_abilId = Roar
- Set venoRoar_baseDmg[1] = 100.00
- Set venoRoar_baseDmg[2] = 150.00
- Set venoRoar_baseDmg[3] = 200.00
- Events
Instead of making three separate real variables we have one real variable array where they are all together. Each real variable in that array can be accessed by using number (they range from 0 to 8191). We use here hero ability level and variable index similarity (Index is called number between [] -- [1] is index number one). Each ability level on hero when used as array index gives us always specific value -- level 1 gives 100.00, level 2 gives 150.00, level 3 gives 200.00 and so on. You will be using often this similarity in your future triggered abilities. Now it is safe to use these three array indexes. It is up to you will you give arrays same starting value in Variable Editor or in our case you could had only ticked 'Array' box and leaved array size to 1 and manually set needed array indexes to value before we actually start to use them.
Trigger Editor has its flaws like we all
and with each cast all enemies are picked and put to unit group, afterwards that unit group gets lost. We can avoid it by using same unit group variable over and over again. First of all condition which finds us enemies in range uses player function. For better performance we can store that player to player variable and use variable instead of function. That function always gives same player -- owner of caster. When we use player variable instead we save much repetitive function calls. You should be familiar how to create variables for now, create player variable and name it 'venoRoar_casterOwner', we set first variable to store caster owner before we use it again:Trigger:
- Venomous Roar
- Events
- Unit - A unit Starts the effect of an ability
- Conditions
- (Ability being cast) Equal to venoRoar_abilId
- Actions
- Set venoRoar_caster = (Casting unit)
- Set venoRoar_abilLevel = (Level of venoRoar_abilId for venoRoar_caster)
- Set venoRoar_casterOwner = (Owner of venoRoar_caster)
- Events
Familiar to our technique where we use variables as much as possible if they are before given value?
Player variable is set up to use in condition. Now we create unit group variable and name it 'venoRoar_enemyGroup'. As first thing we each time clean that group to remove enemies from earlier cast, of course with first cast there are no units in unit group, but from there on old enemies stay in that unit group until new cast cleans unit group variable before use again:
Trigger:
- Venomous Roar
- Events
- Unit - A unit Starts the effect of an ability
- Conditions
- (Ability being cast) Equal to venoRoar_abilId
- Actions
- Set venoRoar_caster = (Casting unit)
- Set venoRoar_abilLevel = (Level of venoRoar_abilId for venoRoar_caster)
- Set venoRoar_casterOwner = (Owner of venoRoar_caster)
- Unit Group - Remove all units from venoRoar_enemyGroup
- Events
When variable is empty we find new enemies around caster and store them to that variable. 'Matching unit' is explained in trigger tutorial and if you do not know what it does read it before continuing (Simple search text and read bit about 'Matching Unit' and 'Picked Unit'):
Trigger:
- Venomous Roar
- Events
- Unit - A unit Starts the effect of an ability
- Conditions
- (Ability being cast) Equal to venoRoar_abilId
- Actions
- Set venoRoar_caster = (Casting unit)
- Set venoRoar_abilLevel = (Level of venoRoar_abilId for venoRoar_caster)
- Set venoRoar_casterOwner = (Owner of venoRoar_caster)
- Unit Group - Remove all units from venoRoar_enemyGroup
- Set venoRoar_enemyGroup = (Units within 512.00 of (Position of venoRoar_caster) matching (((Matching unit) belongs to an enemy of venoRoar_casterOwner) Equal to True))
- Events
All enemies in range have been caught and next we can damage them, not much, just little bit so they do not have will to attack our hero anymore in long time.
For that we use 'Pick every unit in <unit group> action, from popup menu choose variable from top named 'venoRoar_enemyGroup':
Trigger:
- Venomous Roar
- Events
- Unit - A unit Starts the effect of an ability
- Conditions
- (Ability being cast) Equal to venoRoar_abilId
- Actions
- Set venoRoar_caster = (Casting unit)
- Set venoRoar_abilLevel = (Level of venoRoar_abilId for venoRoar_caster)
- Set venoRoar_casterOwner = (Owner of venoRoar_caster)
- Unit Group - Remove all units from venoRoar_enemyGroup
- Set venoRoar_enemyGroup = (Units within 512.00 of (Position of venoRoar_caster) matching (((Matching unit) belongs to an enemy of venoRoar_casterOwner) Equal to True))
- Unit Group - Pick every unit in venoRoar_enemyGroup and do (Actions)
- Loop - Actions
- Events
As you can see we short out enemies one line before and now for each enemy in that group we do damage. In loop actions we store 'Picked Unit' to variable and use that variable, again its faster, better and more dynamic that way. For that we create unit variable named 'venoRoar_enemy':
Trigger:
- Unit Group - Pick every unit in venoRoar_enemyGroup and do (Actions)
- Loop - Actions
- Set venoRoar_enemy = (Picked unit)
- Loop - Actions
Now in all loop action we are going to use our previously set variables as much as possible:
Trigger:
- Unit Group - Pick every unit in venoRoar_enemyGroup and do (Actions)
- Loop - Actions
- Set venoRoar_enemy = (Picked unit)
- Unit - Create 1 Dummy Unit for (Owner of (Casting unit)) at (Position of (Picked unit)) facing Default building facing degrees
- Loop - Actions
becomes to:
Trigger:
- Unit Group - Pick every unit in venoRoar_enemyGroup and do (Actions)
- Loop - Actions
- Set venoRoar_enemy = (Picked unit)
- Unit - Create 1 Dummy Unit for venoRoar_casterOwner at (Position of venoRoar_enemy) facing Default building facing degrees
- Loop - Actions
Trigger:
- Unit - Add Shadow Strike (Neutral Hostile) to (Last created unit)
stays same,
Trigger:
- Unit - Order (Last created unit) to Night Elf Warden - Shadow Strike (Picked unit)
becomes:
Trigger:
- Unit - Order (Last created unit) to Night Elf Warden - Shadow Strike venoRoar_enemy
We set up additional damage per level in our configuration trigger, it would be good time to do that extra damage now. Again we use mostly variables:
Trigger:
- Unit - Cause venoRoar_caster to damage venoRoar_enemy, dealing venoRoar_baseDmg[venoRoar_abilLevel] damage of attack type Spells and damage type Normal
That line damages 'enemy' by 'caster'. How much exactly damage is done depends on this part 'venoRoar_baseDmg[venoRoar_abilLevel]', you know that ' venoRoar_baseDmg' was array with size of 3. ' venoRoar_abilLevel' variable holds caster ability level which can be from 1 to 3. When you replace in mind ' venoRoar_abilLevel' with number from 1 t o3 it should make sense how much damage caster can do.
As last loop action we add expiration timer to our dummy unit:
Trigger:
- Unit Group - Pick every unit in venoRoar_enemyGroup and do (Actions)
- Loop - Actions
- Set venoRoar_enemy = (Picked unit)
- Unit - Create 1 Dummy Unit for venoRoar_casterOwner at (Position of venoRoar_enemy) facing Default building facing degrees
- Unit - Add Shadow Strike (Neutral Hostile) to (Last created unit)
- Unit - Order (Last created unit) to Night Elf Warden - Shadow Strike venoRoar_enemy
- Unit - Cause venoRoar_caster to damage venoRoar_enemy, dealing venoRoar_baseDmg[venoRoar_abilLevel] damage of attack type Spells and damage type Normal
- Unit - Add a 3.00 second Generic expiration timer to (Last created unit)
- Loop - Actions
That is it, we have successfully converted our first trigger version to use variables. To sum things
up variables need to be first set before you can use them or they will break trigger. Variable array
is collection of same variable types with each having their unique array number. Array size ranges
from 0 to 8191. For memorizing -- ' venoRoar_baseDmg [1]' where 'venoRoar_baseDmg' is variable array and '[1]' is unique array number also called array index.
Changed triggered ability now looks this:
Trigger:
- Venomous Roar
- Events
- Unit - A unit Starts the effect of an ability
- Conditions
- (Ability being cast) Equal to venoRoar_abilId
- Actions
- Set venoRoar_caster = (Casting unit)
- Set venoRoar_abilLevel = (Level of venoRoar_abilId for venoRoar_caster)
- Set venoRoar_casterOwner = (Owner of venoRoar_caster)
- Unit Group - Remove all units from venoRoar_enemyGroup
- Set venoRoar_enemyGroup = (Units within 512.00 of (Position of venoRoar_caster) matching (((Matching unit) belongs to an enemy of venoRoar_casterOwner) Equal to True))
- Unit Group - Pick every unit in venoRoar_enemyGroup and do (Actions)
- Loop - Actions
- Set venoRoar_enemy = (Picked unit)
- Unit - Create 1 Dummy Unit for venoRoar_casterOwner at (Position of venoRoar_enemy) facing Default building facing degrees
- Unit - Add Shadow Strike (Neutral Hostile) to (Last created unit)
- Unit - Order (Last created unit) to Night Elf Warden - Shadow Strike venoRoar_enemy
- Unit - Cause venoRoar_caster to damage venoRoar_enemy, dealing venoRoar_baseDmg[venoRoar_abilLevel] damage of attack type Spells and damage type Normal
- Unit - Add a 3.00 second Generic expiration timer to (Last created unit)
- Loop - Actions
- Events
I suggests you to take good rest now and come back when you are ready again.
3. How variables work
This part promises to be short. Actually there is not much to learn how variables work. When you create unit on empty map and store it to unit variable then that variable is called pointer. Why so?
Because there is only one unit, you can set many variables to hold that unit. But that does not multiple
unit on map! All variables and that unit are connected -- all variables point to same unit. Now when ever you use one of those variables it affects only that unit on map. Simple example shows what I am trying to tell here:
'exampleUnit_1' and 'exampleUnit_2' are both unit variables:
Trigger:
- Pointer Variable Example
- Events
- Map initialization
- Conditions
- Actions
- Unit - Create 1 Footman for Player 1 (Red) at (Center of (Playable map area)) facing Default building facing degrees
- Set exampleUnit_1 = (Last created unit)
- Set exampleUnit_2 = (Last created unit)
- Events
It creates on map initialization (map loading) at centre of map one Footman. Then sets first unit variable to that Footman and second unit variable also to Footman.
That action only made both variables to point Footman -- whatever I do to these variables affects our Footman directly. On map there is only one Footman that action did not produce second Footman on map.
Now our test trigger which shows how these two variables and Footman are connected:
Trigger:
- Pointer Variable Test 1
- Events
- Player - Player 1 (Red) skips a cinematic sequence
- Conditions
- Actions
- Unit - Kill exampleUnit_1
- If (All Conditions are True) then do (Then Actions) else do (Else Actions)
- If - Conditions
- (exampleUnit_2 is dead) Equal to True
- Then - Actions
- Game - Display to (All players) the text: Unit died!
- Else - Actions
- If - Conditions
- Events
Though we kill unit in variable 'exampleUnit_1' which is Footman and check different variable named 'exampleUnit_2' it still shows message! That is because both variables point to same unit. First action kills unit and now its dead, other variable points to exactly same unit and 'Footman (exampleUnit_2) is dead Equal to True'.
Footman is object -- a game object. All things which you can create and destroy are objects. These objects are reffered with pointer variables. When you do something with one variable it affects instantly all other variables which point to same object in our case Footman.
Then there are independent variables like integer, real, boolean and some others. They are not connected with object and stand alone. When you do something to that variable it only affects that variable and no others. Example:
'startNumber', 'numberOne' and 'NumberTwo' are integer variables.
Trigger:
- Independent Variable Example 1
- Events
- Time - Elapsed game time is 2.00 seconds
- Conditions
- Actions
- Set startNumber = 0
- Set numberOne = startNumber
- Set NumberTwo = startNumber
- -------- 'NumberOne equals 0' --------
- -------- 'NumberTwo equals 0' --------
- Game - Display to (All players) the text: (String(numberOne))
- Game - Display to (All players) the text: (String(NumberTwo))
- Set NumberTwo = 2
- -------- They are independent! --------
- -------- 'NumberOne equals 0' --------
- -------- 'NumberTwo equals 2' --------
- Game - Display to (All players) the text: (String(numberOne))
- Game - Display to (All players) the text: (String(NumberTwo))
- Events
It shows that even when I set two variables from same variable they are independent. I give new value to second variable and it does not change first variable value -- that is difference between 'create/ destroy' variables and independent variables.
To sum it up 'create/ destroy' variables point to game objects like Footman. Independent variables like integer, real and boolean which you can not create but only set are independent. Changing one of such variables only changes that particular variable and not others.
Unit group can be created which makes it game object and when you destroy it from one pointer variable (unit group variable) all other unit group variables which point to same unit group also become empty -- not set, without value (null). From variable part we know that unset variable breaks trigger. That is common mistake done my beginners. Many triggered abilities may stop working because of that silly mistake. Try to avoid it.
4. Commonly used action functions (actions)
(For Variable Loop, For Loop, timer)
