Warning The first suggestion for local variables is incorrect. While the use of multiple local variables is demonstrated, in fact only ONE local variable can be used in GUI. Until the tutorial is updated, please keep this in mind and either use only one local variable in GUI or consider using JASS for spells.
I've been looking through the spells section lately, and what I see greatly disappoints me. Most of the spells I've looked at - specifically the GUI ones aren't multi-instancible. What this means is that they cannot be cast by more than one unit at a time and still work properly. There are many reasons to why they don't work, and I will go over some of the problems and why they don't work right. After, I will go over methods on how (with little extra trouble) you can make your spell multi-instancible.
First example - waits
Probably one of the most common errors I see in GUI spells involves setting a single global variable to a unit - let's say the caster. The spell then does a bunch of actions and then uses a large wait action. After waiting, the user refers to the specific global variable to do things. Let's say the wait was around 10 seconds. What would happen if another unit cast the spell within 10 seconds of the first unit? Here's an example I'll walk through:
bloodL
This is a spell from a recent map I've been looking at - a real example of someone's work I've seen. Now, in the test map the spell may work find or at least seem to, but if you look closely enough you should be able to easily find the error. The ability is added to a unit, and many effects are created as well. Each of these are set to their own variable, and after 15 seconds are referenced. Well, now what happens if 2 units cast it within 15 seconds of another? I'll tell you what, the effects and the ability from the first round of the spell still remain on the hero - not a good sign!
Second example - periodic events and multiple triggers
This one is another one I see all the time. People need to create a spell that does a certain thing - such as knocking back repetitively over and over again. These people use another trigger and a periodic event in order to accomplish this. Sure it works for a single unit, but what if someone wants all the units in a map able to cast the spell? Let me show you an example of this:
Flurry
(This trigger is initially disabled)
FlurryReg
You could argue that this spell isn't coded very well, but that's not the point. As you can see, this spell turns on the disabled spell in the middle of the spell. The disabled spell moves a specific region to a unit's position every .01 seconds. The problem now is that this other trigger will be turned on for some time. If this spell were being cast again, the 'F_Archer' global variable would be changed to a different unit. The first and second trigger would then be referring to the second unit to cast the spell and not the first, this is a big problem!
Some Solutions
There is no single answer for fixing these kind of problems. Sometimes just better thinking can find you a better solution. If you're unable to find answers, here are some possible solutions:
GUI Local Variable Bug
Someone once found that local variables and global variables could share the same name, and that local variables are looked at before globals. Now, if you don't understand what I just said, here's the same thing in different terms. It means you can declare a local variable with the same name as a global variable, and then each time you refer to the global variable you will really be referencing the local variable. Here's an example of what I'm trying to say:
Untitled Trigger 001
Now, everything should make sense to you except for the first line. The first line uses some JASS to declare a local variable with the same name as a particular global. This means that we can use the name of the global variable to really refer to the local variable. You're still probably wondering how more than one unit can use this at once and not cause problems I'm sure. If you were to create a global variable 'Caster' and test this code, you'd see that it would work without failing. Once again, you may be a bit confused so I'll explain how local variables work. Local variables are called local variables for a reason, they're only able to be accessed by the function they're in. "Functions, isn't that some kind of confusing JASS thing?" you might say. Let me tell you that GUI is converted to JASS when the map is saved (inefficient JASS, but still JASS nonetheless). All the actions inside a specific trigger are all part of one function for the most part. There are exceptions to this, but I'll review those later. Local variables being specific to each function may not make sense to you, so I'll word it in terms you may understand. Creating a local variable is like creating a completely new variable each time the spell starts. Basically, this makes it so we'll be able to refer to the caster no matter how many units cast it at once.
Now, let's fix up the first spell to use this method:
bloodL
As you can see, we've added a local variable for each variable used after the wait in the spell. This spell is now MUI. Now, there's still some more explaining to do. All the global variables you make in the editor are renamed to "udg_Variable_Name" when the GUI is converted to JASS. So when you want to refer to a global variable in JASS, you need to add "udg_" to the front of the variable name and also replace any spaces with an underscore( the _ character).
I must mention one problem with using locals in GUI. The problem is that they cannot be used everywhere. For instance, you should not refer to local variables in if/then/else blocks and "pick every ..." blocks. The reason behind this is that if/then/else sometimes creates additional functions (even if they really are unnecessary) for the condition amongst other things. The "pick ever ..." blocks will always create an additional function that is called for each picked object. All of this information I just told you is hidden from you in GUI, which is why I'm warning you.
Implementing a Stack
Now, that solves one possible problem, but what if we need to use a separate trigger for periodic events? Local variables can't be used outside of the function they're created in. We'll have to be much cleverer to accomplish this task, but it's still possible. This method may be a bit confusing at first, but I'll try to explain it as best I can. I'll be showing you how you might make a knockback ability with this method.
This particular method I have in mind uses a "stack" of unique integers. When you need a unit to get knocked back, you "take" one of those integers off the stack and use it in conjunction with global arrays to put in data. The knockback trigger will then go through each index in use and do the proper actions. I realize what I said probably doesn't make sense, which is why I'll show you some triggers right now. Here is the trigger that would go off when the spell is cast:
Start
And here's the "loop" trigger that would handle moving the units:
Loop
Now, I've purposefully left out the other triggers being run so I can first explain what's going on here. The start trigger would go off whenever a unit started the effect of an ability. Next, we run the NewIndex trigger which will return a unique integer for use with this knockback spell. The unique integer is stored by the NewIndex function in the CurrentIndex variable. Now, we have also set up a bunch of global array variables. To be exact, there is one for each type of information we want to store. We have one for the unit being knocked back, one for how far the unit is moved each cycle, and how long the knockback should go on for. Next, we store the target unit, the distance we want, and the time in their respective global arrays with the index being the value in the CurrentIndex global variable (which is a
unique) integer for this spell.
Next is the Loop trigger which handles the actual moving of the units. We're going to loop through all the indexes that are being used. To do this, you must first know that the amount of indexes being used is stored in the KnockbackIndex variable. We run a "For each integer A from 1 to 50" action which will allow us to go through each index in use and perform the necessary actions. 50 is the maximum number of indexes, so this code will run through the loop 50 times. Of course, we will need to check the current index to make sure that the unit stored in KnockbackUnit isn't equal to "no unit" (which would mean that index isn't being used). The rest should be self-explanatory because I've commented the code. For those who don't know, (Integer A) will refer to the current index being "looked at" by the trigger.
Now I will move on to what's happening in the background. We have a stack of unique integers you might say. If you're one of those people who learns better visually, you're in luck. Here's a visual representation of the stack:
This stack is basically a container that starts out just holding the numbers 1 through 50. Now, when we request a new index, we "take" the value stored on the top of the stack and the next value will be treated as the top of the stack. This is what the stack would look like if we grabbed the value stored at the "top" of the stack.
Doing things like this will ensure the same number cannot be taken twice, which grants us 50 unique numbers. Now that's great, but unless we return numbers to the stack we'll have nothing left when we get to 50. That would definitely be a problem, so we'll have another trigger to return indexes back to the stack. Let's say the indexes 1 through 5 were already in use. Here's what our stack would look like:
Now, let's say the first index was done being used. We'll put it back on the stack to be able to be used in the future by our spell. The stack would look like so if we returned the first index:
Okay, I hope that gave you an understanding of how a stack works. If it didn't, that's too bad because I'm not going to really be covering it any longer. Next we need to implement this into trigger form. We obviously first need to have a stack before it can be used, so let's make an initializing trigger for it:
Init
Now, the KnockbackId will contain each of our unique ids to be used with the spell. We've filled the first 50 indexes of it (we shouldn't need any more indexes) with the numbers 1 - 50. We're also going to set the unit stored in each index used in the KnockbackUnit array to "no unit" which means that the index isn't being used. I'd go into further detail on how this trigger works, only I'm not really sure that there's anything more I could say.
Moving on, let's see how we're going to get a new index from this stack:
NewIndex
KnockbackIndex originally is set to 0, meaning the current amount of used ids from the stack is 0. This variable is equivalent to how many ids are currently in use. First thing this trigger does is increment the KnockbackIndex variable so that it will accurately show how many ids are in use. Next, we set the CurrentIndex variable to the value stored in at the "top" of the stack. Since this isn't really a stack, its size will always remain at 50 which is why we have our KnockbackIndex variable. This variable is really used to tell us which index we need to take the id from when we want a new id. Here's a visual representation first when the stack is full, and second when we're taking a value:
Full Stack:
| KnockbackIndex (0) -> | |
| 1 |
| 2 |
| ... |
| 50 |
Stack After KnockbackIndex is incremented:
| KnockbackIndex (1) -> | 1 |
| 2 |
| 3 |
| ... |
| 5 |
Stack After Id Taken:
| KnockbackIndex (1) -> | |
| 2 |
| 3 |
| 4 |
| ... |
| 50 |
This should give you an idea of what's going on with this trigger. Now we will move onto returning an index back to the stack. I'm hoping you will be able to better understand this example after the previous trigger. Here it is:
ReturnIndex
From the previous example, you saw that KnockbackIndex would actually point 1 space above where the top of the stack was. First, why not just place the index being returned right there on top of the stack where it belongs? Good question, let's do so first. After the index is placed one space above the stack, KnockbackIndex is pointing directly at it when it should be pointing one space above it. So, let's fix it by setting KnockbackIndex to KnockbackIndex - 1. We of course need to set KnockbackUnit on the id to be released to "no unit" for safety measures with the Loop trigger.
Just to clear things up, CurrentIndex is equal to one of the ids that was taken from the stack while KnockbackIndex represents a position on the stack.
This basically concludes things for now. I might choose to explain how you can make a spell just multi-instancible per player for those who have a hard time understanding the stack idea, but that will have to wait. I hope this has helped you and that you will be able to use these techniques in future projects.
A member of
Clan TDG - Quality mapmaking and playtesting.
Tired of boring old GUI? Want to learn JASS? Take a look at these
tutorials.
Events
Unit - A unit Begins channeling an ability
Conditions
(Ability being cast) Equal to Bloodrage
Actions
Set Luster = (Triggering unit)
Special Effect - Create a special effect attached to the right,hand of Luster using Abilities\Spells\Other\BreathOfFire\BreathOfFireDamage.mdl
Wait 15.00 seconds
Trigger - Turn on FlurryReg <gen>
-------- Line removed due to taking up too much space --------
Selection - Select F_Archer for (Owner of F_Archer)
Unit Group - Pick every unit in ArrowEffect[(Integer A)] and do (Unit - Remove (Picked unit) from the game)
Time - Every 0.01 seconds of game time
Region - Center Region 002 <gen> on ((Position of F_Archer) offset by 300.00 towards (Facing of F_Archer) degrees)
Map initialization
