Staredit Network

Whenever a wait actions is executed all the other triggers will have a chance to fire, as a result of that wait, before that trigger finishes. Blizzard made it this way so all the triggers don’t stall whenever you execute a wait. So instead blizzard made the wait action cause all the other triggers to be checked.

A hyper trigger is composed of many waits one after another, each time a wait in them runs triggers are checked and executed. When you have multiple hyper triggers, the different triggers are able to fire off of each other making them last a extremely long time.

Whenever a wait is run by a player no other waits owned by that player can run. A trigger may start firing but stop half way though and wait for the other active wait. The second triggers wait cannot run until the first triggers has finished.

This is mistakenly referred to as “waits add together” This is because if you run two waits at the same time the second wait has to wait for the first + itself. The reason it is a wrong statement is because the first wait runs normally. Now days a wait block is most commonly noticed with the effect of hyper triggers. Triggers placed after a hyper trigger, with waits, must wait for all the hyper triggers waits to fire. Since hyper triggers are designed to wait practically for ever, it appears as if the triggers stop dead in there tracks.

Lastly it is important to know that wait blocks only effect the player who runs the wait. This means more than one player can have a wait running at the same time.

Hyper triggers of course increase the rate in witch your triggers fire. Every single wait action causes the rest of the triggers to fire again when it is run and this is how the effect works. The “problem” with hyper triggers is when you end up the waits in them, causing a wait block. A wait block is when one wait action is delayed because another one is currently being ran.

For example if you make the following two triggers:
Players:
-Player 1
Conditions:
-Switch 1 is Set
Actions:
-Create 1 Marine
-Wait 10000 (10 seconds)

Players:
-Player 1
Conditions:
-Switch 1 is Set
Actions:
-Wait 10 (any value works)
-Kill Marine

Now most people would look at these two triggers and assume that the marine would be killed 10 milli seconds after it is created. But what really happens is since the first trigger runs it’s wait first the second one can not execute any actions after the wait until there are no waits being ran by that player. Therefore the marine is killed after 10010 milli seconds (plus trigger refresh time).

Anyways This Block only occurs when the triggers are owned by the same player. Thus if the second trigger was given to player 2 then the Marine would be killed almost instantly (like most would think it does anyways). When we talk about hyper triggers, they can be thought of as just like an extremely long wait. (To give you an idea of how long 3 triggers with 62 waits each and preserves will last 5 hr 51min and 3 seconds before the triggers refresh and the whole thing starts again.) Therefore any triggers owned by the same player that owns the hyper triggers (with waits in them) Must wait for the hyper triggers to finish before it can run its wait and continue with its actions. (if there after the hyper trigger)

There are also a few misconceptions that make this worse. People believe that triggers owned by a Force or All players are actually different than ones owned by the respective players. The WORST thing you can do with your hyper triggers is make them owned by all players. This is the same as making that trigger for players 1-8 and is the same in every way (trigger order included).

Lastly the effects of a wait (hyper effect) effects all players but only blocks one of them. Therefore most maps should have there hyper triggers owned by a single computer player (without any triggers that include waits). If you do this then no problems will occur because of a wait block. The only problems that might occur are the effects a hyper has on triggers that rely on the delay of the trigger refresh rate (ie custom or death counters).

Hope this helps your understanding. (damn I can never make this brief )

Hyper triggers work by taking an advantage of the programming aspect of trigger order. As most of you should know triggers are fired one after the next in top to bottom order. When a wait is in a trigger action this delays the rest of the trigger until the wait is complete. Because Blizzard didn’t want to pause all the triggers every time a wait is ran (good choice), they did this instead. Every time a wait is activated, the current trigger is put on hold and the triggers following the trigger with the wait will fire. When the trigger firing sequence it gets to the end of the list the trigger list it will start at the top again. Thus a single wait will cause your triggers to fire one extra time.

Now lets say we take one trigger for an example and fill it up with waits. Once the trigger begins to fire every wait will cause the triggers to do a extra loop until it reaches the end of the trigger.

Although this is what were trying to get at a single trigger with 60 plus wait 0 actions will last for about a second if that. This is where multiple triggers is required. If you have just two triggers filled with wait 0 actions, then the following would happen. First the first trigger would fire. After the first wait is ran and the loop starts the second triggers conditions are also true so it will be activated to fire. Since only one wait can be ran at a time (per player) the second triggers wait 0 is ignored until there are no other waits being ran. Since the first trigger has the wait priority, when it returns to the second wait action in the first trigger it will activate again causing another loop leaving the second trigger still waiting for the first. This will continue until the first trigger has fired all its waits. After the first trigger is done the second trigger finally has its chance to shine. It runs its first wait and starts a loop but when it gets back to the first trigger it starts to fire again, and takes the wait priority from the second trigger yet again. This pattern will continue for every wait in the second trigger. So if the two triggers have 62 waits each the triggers fire a extra 3844 times before the actual trigger round ends. But if you simply add one more the amount of trigger loops grows exponentially. Thus a set of hyper triggers that feature 8 triggers with 62 waits each will cause the triggers to fire more than 218 trillion times before the round ends and you get your standard 2 second wait. Needless to say that is enough to last whole game, and you have your self one good hyper trigger.

Aww this is the thing that pisses me off most about triggers right now. Group owned triggers.

For your reference there absolutely useless. Although I do not discourage people from using them, they are the number 1 most misunderstood aspect of triggers. And as far as functional uses there are none. Any map will work the exact same way if you give all the group owned triggers to the players in those groups.

I’m sure you don’t want to hear me rant about how much I hate group triggers so I’ll tell you what they really are. Group owned triggers are exactly the same as that same trigger copied for every player in that group. (that should be the golden rule of Mapmaking, something lol)

What does this mean? Well there are a few things that just throw people off. First off group owned triggers are not one trigger (unless there is only one player in the force). A trigger owned by a force or all players will fire separately for each player in that group. This means that the conditions are checked at separately and just because one fires doesn’t mean another one has to.

The second thing about them is trigger order. This is the second reason I hate group triggers, they distort the true look of trigger order. When a trigger is owned by a group that trigger has several copies, each of those copies are fired in sequence with all the other players triggers. This means other triggers can and will go off before all the players fire there part of the group trigger.

As far as where specifically a trigger is placed in the list is kind of confusing. When you create a trigger for a group, that trigger acts like separate trigger added to the end of each individual players trigger list. Then if you create another trigger for a specific player that trigger will technically be after the group owned trigger (this is how people screw up there hyper triggers). Staredit will remember the order you created these triggers always because it is the true trigger order. If you are curious where a group trigger actually is in the trigger order then do this. Change the ownership of that trigger to the players that are in that group. The trigger will show up on the list where it truly is, likely in the middle of the list.

If you understand all this about the trigger order, you then have moving triggers to deal with (as in up or down on the list). The best way I can think to explain this is to give you an example. In the bound map I created recently I used this to my advantage, I call it the bookmark technique. I had a gigantic list of triggers owned by players 1-6 (like 300+). But I needed to create new triggers in the middle of the list. To do this I first created a useless trigger with the never condition under those players, moved it into place, then moved it to All Players group. Then when I wanted new triggers to go in the middle of my list I would create the trigger under all players, move it above the useless trigger, then change the trigger to players 1-6. What this did was insert the trigger in the middle of the list exactly the where I wanted it to be.

Anyways if your still reading this I apologize about making it so long for something seemingly simple, maybe I’ll edit it to be some kind of tutorial. Hope this helps more than one person and I don’t have to explain the whole damn thing again next week to the very same people.