Wait Command, Good or Bad?

[StormChaser]

I have heard that the Wait command is command which should be avoided when making triggers. Why should it be avoided? Is it a difference between a single and multi-player map when using it? Is there a better option to the Wait command?

• Wait 15.00 seconds

^^ I am talking about this Action just so that there's no confusion.

 

[Xonok]

I have heard that the Wait command is command which should be avoided when making triggers. Why should it be avoided? Is it a difference between a single and multi-player map when using it? Is there a better option to the Wait command?

• Wait 15.00 seconds

^^ I am talking about this Action just so that there's no confusion.

There's mainly 3 aspects about it that must be considered.

Firstly the minimum wait is 0.27 or 0.28(can't remember exact), that limits its usefulness.
Secondly it puts the next actions on hold, while timers do not. This can be good or bad, depending on what you want to do.
Thirdly, wait can not be used inside loops(simply doesn't work).

There might be something more that I don't know of.

 

[edo494]

wait works perfectly fine in loops, the thing that doesnt work is itterating
if you had 1 integer as ittirator for each trigger, that would cause no problems
the other points of Xonok are totally valid
to add little further, Wait kills native event responses like GetDyingUnut, GetKillingUnit etc, the one of only survivors after wait is GetTriggerUnit
also wait is innacurate and someone did testing and proved that they add a little bit delay to them

 

[StormChaser]

OK thanks. I often use Wait in order to make some pause between different actions, like different string commands like Quest - Show Hint or to keep a gate open and then close it. I also use it to delay a Resurrection in my own simple Resurrection Trigger. But that's all I use it for. Oh and I also use it to show a special effect before I remove the effect (via the GUI command Special Effect - Destroy Special Effect x.) or sometimes animations.

I haven't used together with GetKillingUnit. I did try to use it with a trap but it never worked out that well.

 

[Xonok]

OK thanks. I often use Wait in order to make some pause between different actions, like different string commands like Quest - Show Hint or to keep a gate open and then close it. I also use it to delay a Resurrection in my own simple Resurrection Trigger. But that's all I use it for. Oh and I also use it to show a special effect before I remove the effect (via the GUI command Special Effect - Destroy Special Effect x.) or sometimes animations.

I haven't used together with GetKillingUnit. I did try to use it with a trap but it never worked out that well.

It's also possible to make it so that the special effect only plays it's death animation. But you probably knew it already.

 

[StormChaser]

It's also possible to make it so that the special effect only plays it's death animation. But you probably knew it already.

No I didn't know that. I didn't know Special Effects had Death versions. I know Units has a Death and Stand animation and sometimes more.

 

[Xonok]

No I didn't know that. I didn't know Special Effects had Death versions. I know Units has a Death and Stand animation and sometimes more.

Well that is simply done by adding and removing the special effect without a delay. For some reason it is forced to play its death animation once, before disappearing. Whether this is possible depends on the model used. If you use something that doesn't have a death animation, then it will play stand, if not that either then birth. It is forced to play at least something and it prefers death.

 

[StormChaser]

Well that is simply done by adding and removing the special effect without a delay. For some reason it is forced to play its death animation once, before disappearing. Whether this is possible depends on the model used. If you use something that doesn't have a death animation, then it will play stand, if not that either then birth. It is forced to play at least something and it prefers death.

OK thanks I didn't know that. I suppose it make sense as the Create Action starts so it has to do something on that Action before getting Removed.

 

[ap0calypse]

Why should it be avoided?

It shouldn't be avoided: it should be treated with care.
There's nothing 'bad' about Waits, but they do have some side-effects (see above, other people have explained it quite nicely ).
The most common mistake is using a wait and then using "Attacking unit" or something.

Is it a difference between a single and multi-player map when using it?

There is an added delay in multiplayer, this is because all players need to synchronize with each other.
The statistics shown below are ancient (well, about 2 years old I guess). They've been tested with a good PC, without any other systems (in WC3) running.

Single-Player Statistics:

	Wait Time: 0.01 sec	Wait Time: 0.10 sec	Wait time: 0.50 sec	Wait time: 5.00 sec
Avarage Wait:	0.121 sec	0.208 sec	0.610 sec	5.158 sec
Minimum Wait:	0.075 sec	0.175 sec	0.575 sec	5.272 sec
Maximum Wait:	0.200 sec	0.275 sec	0.700 sec	5.075 sec

Multi-Player Statistics:

	Wait Time: 0.01 sec	Wait Time: 0.10 sec	Wait time: 0.50 sec
Avarage Wait:	0.250 sec	0.370 sec	0.751 sec
Minimum Wait:	0.225 sec	0.250 sec	0.725 sec
Maximum Wait:	0.275 sec	0.501 sec	0.775 sec

Note: multi-player statistics depend on the other players as well: if they're slower, then the waits may be longer.
Therefore, the shown table might vary (I don't know by how much though).

The multi-player table shows some clear evidence that there's a minimum wait time: the wait difference (fastest waits) between 0.01 and 0.10 seconds is 0.025 seconds: 3.6 times shorter than what you would expect (0.09 second difference).

As you can see: the shortest wait I've seen so far is 0.075 seconds in single and 0.225 in multi-player.
In general, the waits are about 0.12 seconds longer than what you've set it to in single-player, and 0.25 seconds longer in multi-player.
With long waits, this doesn't really matter that much. Just don't use waits for precisely timed stuff.

Is there a better option to the Wait command?

For a simple wait: no.
In case you want to time something more accurately, then you have 2 options:
1) The event "Time - every 0.0x seconds of game time" (0.03 is usually used for movement, 0.02 is acceptable for accurate timing and 0.05 or higher for certain timed effects, such as DOTs).
2) Timers.

 

[StormChaser]

Thank you ap0calypse for explaining it more in detail! It helps a lot.

 

[shadowvzs]

a note:
i found wait usefull for fast solution for preventing item pick up (item duplicateing) / leveling trigger problems (both of them sometimes could be buggy, run twice instead 1, etc)
so in that case if u dont make variables u can use a simple Wait 0 at end of the trigger.

another place where i used, loading the triggers after map init for preventing the lagg what could cause the alot heavy trigger at same time, in every else place timer/periodic trigger win

 

[StormChaser]

Thanks for your input, I appreciate it.

 

[SeriousEnemy]

And to come back to your question, for your use you can of course use the waits like you did:

I often use Wait in order to make some pause between different actions, like different string commands like Quest - Show Hint or to keep a gate open and then close it. I also use it to delay a Resurrection in my own simple Resurrection Trigger. But that's all I use it for. Oh and I also use it to show a special effect before I remove the effect (via the GUI command Special Effect - Destroy Special Effect x.) or sometimes animations.

There won't be any problem with it.
You will find out by yourself when the time has come to search another way (for example triggered spells).
If that happens, go to ap0calypse's post.

 

[StormChaser]

And to come back to your question, for your use you can of course use the waits like you did:



There won't be any problem with it.
You will find out by yourself when the time has come to search another way (for example triggered spells).
If that happens, go to ap0calypse's post.

OK, thanks.