• 🏆 Texturing Contest #33 is OPEN! Contestants must re-texture a SD unit model found in-game (Warcraft 3 Classic), recreating the unit into a peaceful NPC version. 🔗Click here to enter!
  • It's time for the first HD Modeling Contest of 2024. Join the theme discussion for Hive's HD Modeling Contest #6! Click here to post your idea!

[Misc] Types of Timers

Level 15
Joined
Oct 29, 2012
Messages
1,474
Wait-Action & Alternatives in GUI

Hello people!

Preview:

This is the first tutorial I submit. I might mess some things up, but I wish I can succeed letting you receive the important about the three types of Timers.

Introduction:

We all know there are efficient and inefficient ways of triggering. This tutorial includes the ways about timers/waits, some are efficient, some not.

Terms:

MUI = Multi-Units-Instance = Several Units can cast the spell at once
MPI = Multi-player-instance = Several players can cast spells through several units at once


1- Waits :

The least efficient way to create a wait/timer, is to use this action :
One-line Wait
  • Wait 0.1 Seconds
Actually the no-efficiency of this function isn't about its slowness, it's about how many waits of the same trigger can be ran at once ( Instance ).
Example : We have a spell of loading, we make the caster load, and to do that we pause him then after a while we unpause it.

Example
  • Events
    • Unit - A Unit starts the effect of an ability
  • Conditions
    • (Ability Being Cast) Equal to Loaded Bomb
  • Actions
    • Set Caster = (Triggering Unit)
    • Unit - Pause Caster
    • Wait 5.00 seconds
    • Unit - Unpause Caster
The messed thing about this trigger is that it can be ran only by one player and one unit. If two players cast the spell at once, one unit will be paused forever, the other one will work normally. Here it comes the sake of 'MUI' timers ( See terms )... Which we will include later on...
A- Pros of waits :
- Can be used very easily and they just take one line.
- Uses one line of one trigger.
B- Cons of waits:
- They make the spells non-MUI ...
- They suck way hard with For-Each-Integer/If-Then-Else/Picking actions... they will bug hard as tested.


2- Countdown timers :

A well known way to count time. They allow the use of MUI spells and can be used greatly with MPI too... they are efficient but they take more space/lines, whereas you should create 2 triggers to make the timer work.
Countdown Timer Example

  • Run Timer
  • Events
    • Unit - A Unit starts the effect of an ability
  • Conditions
    • (Ability Being Cast) Equal to Loaded Bomb
  • Actions
    • Set Caster[Player Number of (Triggering Player)] = (Triggering Unit)
    • Unit - Pause Caster
    • Countdown Timer - Start Bomb_Timer[Player Number of (Triggering Player)] that expires in 2 seconds
  • Timer Ends
  • Events
    • Time - Bomb_Timer[1] expires
    • Time - Bomb_Timer[2] expires
    • Time - Bomb_Timer[3] expires
    • Time - Bomb_Timer[4] expires
    • Time - Bomb_Timer[5] expires
    • Time - Bomb_Timer[6] expires
    • Time - Bomb_Timer[7] expires
    • Time - Bomb_Timer[8] expires
    • Time - Bomb_Timer[9] expires
    • Time - Bomb_Timer[10] expires
    • Time - Bomb_Timer[11] expires
    • Time - Bomb_Timer[12] expires
  • Conditions
  • Actions
    • Player Group - Pick every player in (All Players) and do multiple actions:
      • Loop - Actions
        • If/Then/Else :
          • Conditions
            • ( (Remaining Time) of (Bomb_Timer) for (Picked Player) Lesser than 1 seconds
          • Actions
            • Unit - Unpause Caster[Player Number of (Picked Player)]
Above, it's an example of the using of timers in MUI spells, which responses to the expiration of any timer for any player.

A- Pros of Countdown Timers:
- Can make spells MUI
- Can be used many times and can be repeated whenever and however reconfigured.
- You can see the remaining time by creating a window or using Game - Show (Remaining Time of (Last Started Timer))...
B- Cons of Countdown Timers:
- Take two triggers to achieve the goal


3- Periodic Increasing Real (PIR) :

It's a very new way of an increasing time, it uses reals and a periodic event, and it's efficient and support MUI spells, and can't be bugged and is very different than how a normal timer works. The way to achieve this is simple, we use booleans, integers, reals and the periodic event.

For example, we have a loading bomb spell. Here is its configuration:

Configuration of PIR Loading Bomb

  • Events
    • Unit - A Unit starts the effect of an ability
  • Conditions
    • (Ability Being Cast) Equal to Loading Bomb
  • Actions
    • ------- Configuration -------
    • Set Bomb_PN = (Player Number of (Triggering Player))
    • Set Caster[Bomb_PN] = (Triggering Unit)
    • Set Damage[Bomb_PN] = ( Level of Loading Bomb of Caster[Bomb_PN] x 100 )
    • Set Duration_Of_Loading[Bomb_PN] = 5.00
    • ------- Run Spell ------
    • Unit - Pause Caster[Bomb_PN]
    • Player - Add (Triggering Player) to LoadingBomb_PIR_Group
  • PIR Loading Bomb
  • Events
    • Time - Every 0.05 seconds of game time
  • Conditions
  • Actions
    • Player Group - Pick Every Player in (LoadingBomb_PIR_Group)
      • Loop - Actions
        • Set PIR_PlayerNumber = (Player Number of (Picked Player))
        • Set PIR_Real = (PIR_Real + 0.05) == This is our PIR, it's increasing time according to the event, if it was 0.01, then we add 0.05, but it's suggested 0.05
        • If/Then/Else
          • Conditions
            • PIR_Real Greater or Equal to 'Duration_Of_Loading[PIR_PlayerNumber]'
          • Actions
            • Player Group - Remove (Picked Player) from (LoadingBomb_PIR_Group)
            • Unit - Unpause Caster[PIR_PlayerNumber]
Pros of PIR :
- It's very efficient and fast and doesn't get bugged like timers often do.
- It can be freely controlled and configured however.
- The most MUI-Supporting timers.
- They work best with For-Each-Integer/If-Then-Else/Picking Actions, it's also a method to count units in a unit group.
- You can know the remaining time whenever. (Game - Show (String(PIR_Real))
- You can reset it whenever by using (Set PIR_Real = 0)
Cons of PIR :
- Takes more space rather than other timers.



Conclusion :

If you are planning for a Single player map, you can freely use Waits because that doesn't matter, even blizzard used it in its maps.
If you are planning to make MUI spells/Systems, I'd suggest Countdown timers and PIRs... They are very efficient and easy...

Good luck felahs !



 
Last edited:
Some feedback:

1 - Waits: "They make the spells non-MUI".

This first point is very false. They have nothing to do with MUI. What can lead to non-mui in your example is the wrong usage of unit responses/variables, not the wait.
Waits are not accurate, and they don't stop counting in battle-net when game is waiting for a player, for example.
If you use wait 0.1 for example the percentage of inaccuracy may be very huge, I think it can be a max of something like 0.2 seconds.
There is somwhere a table of the possible inaccuracy, which you can add in your tutorial, or link to it. I will try to find it later.
MUI-example with waits: http://www.hiveworkshop.com/forums/trigger-gui-editor-tutorials-279/mui-triggers-waits-218354/

2- Countdown timers :

Your example is not MUI, it is MPI.
Also a hashtable should be used instead of your way to detect the expired timer, to avoid not needed checks.
You only talk about the GUI aspect of timers. In JASS things looks different, and timers are more powerful. You also don't need an other trigger for them in JASS. (you should note that your tutorial is only for GUI, or also explain the JASS aspect)
Also again. A timer per se has nothing to do with MUI/MPI or not MUI/MPI. It's they way of usage. In your example you create timer[array] and work with PlayerNumber as Index. This way you could make the usage timer MPI compatible.

3- Periodic Increasing Real

Your example is not MUI, it is MPI.
It's very efficient and fast and doesn't get bugged like timers often do.
^Explain when timers are buggy. And I think timers are more efficient.
Why do you use reals for counting? The usual usage for this is an integer.
You can link to this great tutorial: http://www.hiveworkshop.com/forums/...279/mui-spells-using-artificial-waits-223315/

Also don't pause the unit in each of your examples. As pausing units should be avoided there is no need to spread this method around. :p
 
Level 15
Joined
Oct 29, 2012
Messages
1,474
Some feedback:

1 - Waits: "They make the spells non-MUI".

This first point is very false. They have nothing to do with MUI. What can lead to non-mui in your example is the wrong usage of unit responses/variables, not the wait.
Waits are not accurate, and they don't stop counting in battle-net when game is waiting for a player, for example.
If you use wait 0.1 for example the percentage of inaccuracy may be very huge, I think it can be a max of something like 0.2 seconds.
There is somwhere a table of the possible inaccuracy, which you can add in your tutorial, or link to it. I will try to find it later.
MUI-example with waits: http://www.hiveworkshop.com/forums/trigger-gui-editor-tutorials-279/mui-triggers-waits-218354/

2- Countdown timers :

Your example is not MUI, it is MPI.
Also a hashtable should be used instead of your way to detect the expired timer, to avoid not needed checks.
You only talk about the GUI aspect of timers. In JASS things looks different, and timers are more powerful. You also don't need an other trigger for them in JASS. (you should note that your tutorial is only for GUI, or also explain the JASS aspect)
Also again. A timer per se has nothing to do with MUI/MPI or not MUI/MPI. It's they way of usage. In your example you create timer[array] and work with PlayerNumber as Index. This way you could make the usage timer MPI compatible.

3- Periodic Increasing Real

Your example is not MUI, it is MPI.
^Explain when timers are buggy. And I think timers are more efficient.
Why do you use reals for counting? The usual usage for this is an integer.
You can link to this great tutorial: http://www.hiveworkshop.com/forums/...279/mui-spells-using-artificial-waits-223315/

Also don't pause the unit in each of your examples. As pausing units should be avoided there is no need to spread this method around. :p

Hey! Thanks for the feedback as it didn't include so much about each.

However, I thought Waits shouldn't be included in MUI spells, you also said they are inaccurate which is the point I tried to send.

Also, I included MPI examples, because the example have nothing to do with multiple units since I didn't include any details of a spell. MPI owns MUI I guess, yes it's really MPI and could be MUI because of indexing the caster's array.

My tutorial is Only-GUI, since I know nothing about waits/timers in JASS, everything will be clear for a beginner GUIer.
For me, timers are buggy, sometimes, or we can say 'Hardly ever', they sometimes don't launch. I still don't know the reason.

For pause thingy, pause sometimes is important for example before a tournament or a duel , whilst a counting down 3.2.1... All units must be paused, I didn't suggest to use them in spells, it's true they suck in spells and systems. I forgot to mention that Pause is inefficient.

Thanks for the feedback felehs! It's awesome.
 
You can use TriggeringUnit for example, even after waits. The trigger will still be MUI.
Or look at the my first link (in my post above), it also shows method how to do triggers mui with waits. (tutorial by Magtheridon96)
This is also very helpful: http://www.hiveworkshop.com/forums/lab-715/event-response-myths-253665/

Edit:

Maybe you should think of an other tutorial name. "Type of timers" is maybe not very matching, as actually only one part is about timers. :p
Maybe something like "Wait-Action & Alternatives in GUI" or idk.^^
 
Level 15
Joined
Oct 29, 2012
Messages
1,474
You can use TriggeringUnit for example, even after waits. The trigger will still be MUI.
Or look at the my first link (in my post above), it also shows method how to do triggers mui with waits. (tutorial by Magtheridon96)
This is also very helpful: http://www.hiveworkshop.com/forums/lab-715/event-response-myths-253665/

Edit:

Maybe you should think of an other tutorial name. "Type of timers" is maybe not very matching, as actually only one part is about timers. :p
Maybe something like "Wait-Action & Alternatives in GUI" or idk.^^

Yeah I was aware for that, but everything that counts is considered as a timer. Thanks for links too.
 

Chaosy

Tutorial Reviewer
Level 40
Joined
Jun 9, 2011
Messages
13,182
You can use TriggeringUnit for example, even after waits. The trigger will still be MUI.

Yes, but not if you store it into a variable since that can be overwritten.

I did that by intention that's because Waits are not suggested in MUI triggers. I don't even realize how can I add MUIness in it :\ It's one trigger...
  • Events
    • Unit - A Unit starts the effect of an ability
  • Conditions
    • (Ability Being Cast) Equal to Loaded Bomb
  • Actions
    • Unit - Pause (Triggering Unit)
    • Wait 5.00 seconds
    • Unit - Unpause (Triggering Unit)
 
Level 15
Joined
Oct 29, 2012
Messages
1,474
I see. But I think his intention is to show alternatives for the Wait - Action.
And it's pupose is to pause an explicit amount of time, and then to do further operations.

Edit: That's why I suggested to change the name of the thread. Correct me if I'm wrong, jonhysone.


What was new in this tutorial was neither waits, nor timers. As you can see I haven't explained more further the use of timers and how they get bugged, I didn't also explain how they are created, and didn't explain their windows and their bugs too.

The purple of this thread is indeed to show an alternative for the wait action that stops the trigger completely and Waits are way way bad with For Each Integer/If Then Else and picking actions. That's why I suggested the PIR option that's probably used for these cases, thus your guess is correct. If I use a non-increasing integer/real, there will no point for this.

EDIT : Added some Cons/Pros points.
 
Level 29
Joined
Oct 24, 2012
Messages
6,543
B- Cons of waits:
- They make the spells non-MUI ...
- They suck way hard with For-Each-Integer/If-Then-Else/Picking actions... they will bug hard as tested.
Waits do not make spells non-MUI. (the 2 have nothing related)
They do not bug when using them with ITEs.

  • Events
    • Unit - A Unit starts the effect of an ability
  • Conditions
    • (Ability Being Cast) Equal to Loaded Bomb
  • Actions
    • Unit - Pause (Triggering Unit)
    • Wait 5.00 seconds
    • Unit - Unpause (Triggering Unit)
This tutorial needs to be reworked IMO.

You have a lot of faults and flaws about what you list for pros and cons.
A cast trigger and a trigger that runs at a time period is the fastest. Only because of the way GUI handles timers. Otherwise timers are faster.

Waits are inefficient. You can link to my guide for more examples on why they are.

Timers do not bug when done correctly. Neither do waits (except under one circumstance) or periodic triggers.

As for MUI. Waits are by far the easiest to do. They are by far the worst option though. They are incredibly inaccurate. And have known problems.
For GUI. You can use either timers or periodic triggers. They are close enough to each other. But for GUI the periodic triggers are easier and more efficient.

Note: I never heard them called PIRs before. They are not new.
Note: I did not look over everything.

This has 2 many faults though. If you want to make a tutorial for people then you should explain all facts correctly.
 
Level 15
Joined
Oct 29, 2012
Messages
1,474
Waits do not make spells non-MUI. (the 2 have nothing related)
They do not bug when using them with ITEs.

  • Events
    • Unit - A Unit starts the effect of an ability
  • Conditions
    • (Ability Being Cast) Equal to Loaded Bomb
  • Actions
    • Unit - Pause (Triggering Unit)
    • Wait 5.00 seconds
    • Unit - Unpause (Triggering Unit)
This tutorial needs to be reworked IMO.

You have a lot of faults and flaws about what you list for pros and cons.
A cast trigger and a trigger that runs at a time period is the fastest. Only because of the way GUI handles timers. Otherwise timers are faster.

Waits are inefficient. You can link to my guide for more examples on why they are.

Timers do not bug when done correctly. Neither do waits (except under one circumstance) or periodic triggers.

As for MUI. Waits are by far the easiest to do. They are by far the worst option though. They are incredibly inaccurate. And have known problems.
For GUI. You can use either timers or periodic triggers. They are close enough to each other. But for GUI the periodic triggers are easier and more efficient.

Note: I never heard them called PIRs before. They are not new.
Note: I did not look over everything.

This has 2 many faults though. If you want to make a tutorial for people then you should explain all facts correctly.



Epic feedback ! Absolutely I will take everything under consideration :vw_love:
 
I feel like this tutorial could better outline the differences between waits & timers. There is much more information to be known about waits, i.e. can't be used in "Pick every..." functions, they don't wait in game-time, and the inaccuracy error %.

They make the spells non-MUI ...
Also, they don't immediately make it so that the trigger is MUI. I imagine a new user reading that would think that you just have to avoid waits in order to achieve MUI. But that is untrue, and it doesn't really help them understand where the MUI problems arise from in the first place.

They suck way hard with For-Each-Integer/If-Then-Else/Picking actions... they will bug hard as tested.

Saying they suck isn't too informative. :p You should give an example of a wait in a loop and a wait in if/then/else. They don't bug out. They perform the behavior just fine, but it sometimes just isn't what the user wanted.

Above, it's an example of the using of timers in MUI spells, which responses to the expiration of any timer for any player.

The example you gave is MPI, not MUI.

The PIR example is also MPI, not MUI. And I don't think countdown timers get bugged.

Anyway, as deathismyfriend said, this tutorial could use a bit of work. But I think the idea is good! It would be nice to have a comprehensive comparison between timers and waits.

Some tips for formatting and phrasing:
  • Keep the text as one size (such as this post). Use larger sizes for emphasis or for headings. And try not to mix and match fonts too much. It is usually better design wise to use one font throughout, or one for the body text and one for the headings.
  • Avoid making blanket statements like "this is fast" or "this sucks" or "this bugs". Those statements need thorough explanations to back them up. Rather, you should just state the facts about each side and let the user make an informed decision on which he'd prefer to use. :)
 
Level 15
Joined
Oct 29, 2012
Messages
1,474
I feel like this tutorial could better outline the differences between waits & timers. There is much more information to be known about waits, i.e. can't be used in "Pick every..." functions, they don't wait in game-time, and the inaccuracy error %.


Also, they don't immediately make it so that the trigger is MUI. I imagine a new user reading that would think that you just have to avoid waits in order to achieve MUI. But that is untrue, and it doesn't really help them understand where the MUI problems arise from in the first place.



Saying they suck isn't too informative. :p You should give an example of a wait in a loop and a wait in if/then/else. They don't bug out. They perform the behavior just fine, but it sometimes just isn't what the user wanted.



The example you gave is MPI, not MUI.

The PIR example is also MPI, not MUI. And I don't think countdown timers get bugged.

Anyway, as deathismyfriend said, this tutorial could use a bit of work. But I think the idea is good! It would be nice to have a comprehensive comparison between timers and waits.

Some tips for formatting and phrasing:
  • Keep the text as one size (such as this post). Use larger sizes for emphasis or for headings. And try not to mix and match fonts too much. It is usually better design wise to use one font throughout, or one for the body text and one for the headings.
  • Avoid making blanket statements like "this is fast" or "this sucks" or "this bugs". Those statements need thorough explanations to back them up. Rather, you should just state the facts about each side and let the user make an informed decision on which he'd prefer to use. :)

Awesome feedback, you know, when I created this tutorial I was not able to distinguish between MUI and MPI, but it's all okay now.
 
Top