Well, to clarify: Wait in SC2 works exactly the same way as it did in WC3. If anything you do with the wait is multi unit instanceable depends on what you are actually doing with the wait. You cannot even say, if the wait function is multi unit instanceable or not, since the actual wait has nothing to do with the unit.
You can make a trigger containing a wait for a unit, which for example resembles a spell. The spell would be MUI, or not, depending on how the trigger is realized. You can make MUI-Spells as well as non-MUI-Spells with waits in WC3 just like you can do in SC2.
However, since in SC2 local variables are available in Gui, MUI is a lot easier to achieve in Gui for most people than it was in WC3.
The greatest problem in WC3 was that all system variables that started with "Last" (like "Last Created Unit") weren't local. In SC2 they are, so there won't appear a problem by using them.
Well, in SC2 Triggering unit seems to be not wait resistant anymore, which it used to be in WC3. Still, by adding local variables to the Gui, Blizzard made most of these problems easily solveable.
This thread is a good read for people (to have this knowledge).
1. Using last created unit or triggering unit etc... in a trigger with a wait seems to forget that reference. Thus, for any triggers with "Wait XX seconds", store any units or players in local variables and reference those instead of 'triggering unit'.
2. Local variables in a trigger are your friend! If you want something to run for 100 units around similar times, e.g. when a unit attacks... then running actions or a trigger using local variables in that trigger will be separate for all instances of the trigger. Meaning: If two units attack around the same time, and you have a trigger with event of a unit is damaged, and a local variable getting the damage amount, and then actions that do stuff based on that... the trigger will be run twice for each attack and the LV (not louis vuitton, LOCAL VARIABLE!) will be only referring to the current instance of the trigger. This is good news :D:D
Last Created Unit (and Actor/etc) is not local as far as I'm aware (why would it be? It is not an event response)
Just to clarify; triggering unit was local in WC3, but damaging unit/entering unit/ leaving unit/attacking unit/etc. were not. These are all local in SC2, however, so go right on ahead and use them with waits in between.
Either way; now that local variables are easy to use in GUI (they were usable in GUI in WC3, but you'd have to use custom script to create them and store them in a temporary global variable) waits are pretty much always MUI. However, do note that waits are not precise as they will deactivate for the wait amount and then queue up behind other triggers to continue the progress. Don't rely on waits to wait exactly the time interval because it will fail you. Use timers if you need exact times (however, these are harder to make MUI)
Last Created Unit (and Actor/etc) is not local as far as I'm aware (why would it be? It is not an event response)
Just to clarify; triggering unit was local in WC3, but damaging unit/entering unit/ leaving unit/attacking unit/etc. were not. These are all local in SC2, however, so go right on ahead and use them with waits in between.
Either way; now that local variables are easy to use in GUI (they were usable in GUI in WC3, but you'd have to use custom script to create them and store them in a temporary global variable) waits are pretty much always MUI. However, do note that waits are not precise as they will deactivate for the wait amount and then queue up behind other triggers to continue the progress. Don't rely on waits to wait exactly the time interval because it will fail you. Use timers if you need exact times (however, these are harder to make MUI)
All these things were local in Wc3 too - they just weren't consistent. I'm picky about that :)
And waits aren't unprecise because everything after them gets queued up. That doesn't even really happen. Functions can only run parallel when they're in different threads, and things in different threads don't get queued together.
And things in the same thread are always run one-by-one, no matter the amount of waits.
Of course, technically everything gets queued, as a computer cannot do two actions at once. But that amounts to microseconds, if not nanoseconds. And this delay is also always present, no matter if you have waits or not.
The reason why waits aren't precise are that they delay the function by a certain amount of game ticks, rather than a certain amount of time. One game tick is 1/32nd of a second. Because of some reason the Wait command usually waits in steps of 2 game ticks.
So basically you can only wait a multiple of 1/16th of a second, and it's always rounded up.
If you want to wait 0.2 seconds you'll actually wait 0.25 seconds (4/16th).
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Hello helpful friend!
I was wondering if Waiting is MUI or Multi-Unit Instance-able. In WC3 it was not, but I read somewhere that in SC2 it is. I just want to confirm!
Thanks!
It is MUI.
@zenx1: Go
It is? Hoooooray! Thanks for the confirmation!
the same old question...
if you use only locals and not globals. Yes!
@HellGateSc2: Go
Good to know, or more specifically, to be reminded *(Already knew that =] )
Well, to clarify: Wait in SC2 works exactly the same way as it did in WC3. If anything you do with the wait is multi unit instanceable depends on what you are actually doing with the wait. You cannot even say, if the wait function is multi unit instanceable or not, since the actual wait has nothing to do with the unit.
You can make a trigger containing a wait for a unit, which for example resembles a spell. The spell would be MUI, or not, depending on how the trigger is realized. You can make MUI-Spells as well as non-MUI-Spells with waits in WC3 just like you can do in SC2.
However, since in SC2 local variables are available in Gui, MUI is a lot easier to achieve in Gui for most people than it was in WC3.
@Kueken531: Go
The greatest problem in WC3 was that all system variables that started with "Last" (like "Last Created Unit") weren't local. In SC2 they are, so there won't appear a problem by using them.
Well, in SC2 Triggering unit seems to be not wait resistant anymore, which it used to be in WC3. Still, by adding local variables to the Gui, Blizzard made most of these problems easily solveable.
if you use wait in an action definition with the "thread" option checked, it will run simultaneously with other wait threads
Same with separate triggers, since internally the "thread" option does nothing more but creating a new trigger for the function ;)
use locals and it will become MUI. Yes waits can over-ride global variables. So it depends what you are using.
This thread is a good read for people (to have this knowledge).
1. Using last created unit or triggering unit etc... in a trigger with a wait seems to forget that reference. Thus, for any triggers with "Wait XX seconds", store any units or players in local variables and reference those instead of 'triggering unit'.
2. Local variables in a trigger are your friend! If you want something to run for 100 units around similar times, e.g. when a unit attacks... then running actions or a trigger using local variables in that trigger will be separate for all instances of the trigger. Meaning: If two units attack around the same time, and you have a trigger with event of a unit is damaged, and a local variable getting the damage amount, and then actions that do stuff based on that... the trigger will be run twice for each attack and the LV (not louis vuitton, LOCAL VARIABLE!) will be only referring to the current instance of the trigger. This is good news :D:D
@OneTwoSC: Go
Thanks for all of the replies!!
Last Created Unit (and Actor/etc) is not local as far as I'm aware (why would it be? It is not an event response)
Just to clarify; triggering unit was local in WC3, but damaging unit/entering unit/ leaving unit/attacking unit/etc. were not. These are all local in SC2, however, so go right on ahead and use them with waits in between.
Either way; now that local variables are easy to use in GUI (they were usable in GUI in WC3, but you'd have to use custom script to create them and store them in a temporary global variable) waits are pretty much always MUI. However, do note that waits are not precise as they will deactivate for the wait amount and then queue up behind other triggers to continue the progress. Don't rely on waits to wait exactly the time interval because it will fail you. Use timers if you need exact times (however, these are harder to make MUI)
All these things were local in Wc3 too - they just weren't consistent. I'm picky about that :)
And waits aren't unprecise because everything after them gets queued up. That doesn't even really happen. Functions can only run parallel when they're in different threads, and things in different threads don't get queued together.
And things in the same thread are always run one-by-one, no matter the amount of waits.
Of course, technically everything gets queued, as a computer cannot do two actions at once. But that amounts to microseconds, if not nanoseconds. And this delay is also always present, no matter if you have waits or not.
The reason why waits aren't precise are that they delay the function by a certain amount of game ticks, rather than a certain amount of time. One game tick is 1/32nd of a second. Because of some reason the Wait command usually waits in steps of 2 game ticks.
So basically you can only wait a multiple of 1/16th of a second, and it's always rounded up.
If you want to wait 0.2 seconds you'll actually wait 0.25 seconds (4/16th).