Yes, there could be issues. Here is a simple example that demonstrates potential problems with "shared" variables:
-
Spell
-

Events
-


Unit - A unit starts the effect of an ability
-

Conditions
-

Actions
-


Set TempLoc = (Target point of ability being cast)
-


Unit - Kill (Triggering unit)
-


Special Effect - Add special effect at TempLoc using model "someEffect.mdl"
-


Special Effect - Destroy (Last created effect)
-


Custom script: call RemoveLocation(udg_TempLoc)
-
Unit Dies
-

Events
-

Conditions
-

Actions
-


Set TempLoc = (Position of (Triggering unit))
-


Unit - Create 1 Footman at TempLoc facing (Default facing) degrees
-


Custom script: call RemoveLocation(udg_TempLoc)
In the two triggers above, I use "TempLoc" in both triggers. Can you spot what could go wrong with these triggers when a unit casts a spell?
----
The issue is a bit subtle; it has to do with the order in which triggers are executed:
Block #1 is executed first. Once it finishes "Unit - Kill unit", it jumps over to any triggers that respond to "A unit dies". It completes all of those actions, and then returns back to complete Block #3.
In Block #2, we overwrite TempLoc and then remove it. So when we jump back to Block #3, we will end up creating an effect at a destroyed location (which ends up just going to the center of the map; coordinates (0, 0) ).
So the main problem are these actions which cause other events to happen. The situation above is a bit contrived, but this can happen really easily in maps since there are so many actions that can fire events: damaging a unit, moving a unit, ordering a unit to do something, etc.
There are a lot of ways to solve this problem, but the easiest is to just use separate variables for each trigger. Sometimes you can share variables when you know they won't collide, e.g. if you have a bunch of spell triggers and none of your spells will cause another spell to go off, then you can probably share the variables between them. Just be careful about it. That is why we require spells to use unique variables when they're submitted to our database.
