By taking advantage of simple map making features, it is possible to consolidate hyper triggers into a single hyper trigger.





Any other unused unit may also be substituted for Cave.


Advantages
This trigger is compact and has several advantages over previous versions. For this reason it is the most robust version of hyper triggering, and should be used instead of other versions. It doesn't have a Next Ending Occurrence (NEO) and experiences wait throttling instead of wait blocking. It can also run with any number of players, without worrying about who "owns" the trigger: it is owned by everyone.

Wait Throttling
Traditionally, running a wait while using hyper triggers would stall the wait indefinitely until the NEO. This phenomenon is known as wait blocking, and means that waits cannot be used.

Triggers that come before the hyper trigger throttle the player's contributions to hyper cycles (e.g., if there are only two players contributing to the hyper cycles and one of them has a 500ms wait above the hyper trigger, there will be a burst of 3 hyper cycles every 500ms). This can be avoided by having at least two players who are not running a wait at any given time.

Triggers that come after the hyper trigger throttle the player's wait times by adding an extra cycle for every two normal cycles the wait would take to complete (e.g., if there are only two players contributing to the hyper cycles and one of them has a 500ms wait below the hyper trigger, that wait would take approximately 750ms). This can be avoided by placing the hyper trigger at the bottom of the trigger list.


For these reasons, it's best to avoid the use of waits and always place the hyper trigger at the bottom of the trigger list.

Further reading: http://www.staredit.net/starcraft/Hyper_Triggers

Post has been edited 11 time(s), last time on Sep 9 2016, 11:05 pm by Sacrieur.

cool!

Nice discovery, Sacrieur! I would assume this will work for anything with a setup such that:





Post has been edited 1 time(s), last time on Jun 18 2014, 2:35 pm by Roy.

^ It was a joint discovery by me and Roy.

I think the trigger breaks if someone leaves mid game, and the hyper triggers quit working.

If someone could verify, that'd be great, cuz it would mean that there's a glitch somewhere else in my game.

That seems to be a critical flaw with this system: if a player leaves in the middle of a trigger, the trigger stops. So if a player leaves after setting the switch, their trigger never clears the switch, and the hypers stop running because the condition requires the switch to be cleared. This has a 25% chance of occurring if either of the first two players of the game leave.

I had forgotten that triggers for a player stop mid-execution when the player leaves. This would make a single hyper trigger impossible for any condition that cannot be invalidated independently of the completion of its execution. Something like the following would be fail-proof:



Unfortunately, that makes it so you can't use the countdown timer (and it blinks 0:00 constantly). Not an ideal solution.

Alternatively, we can increase the number of cycles that the hyper trigger runs per player to avoid this catastrophe situation:



Problem solved! Except, of course, if both active hyper players leave at the same time after one of them sets the switch (not entirely out of the question if we consider, say, a set of players dropping from a game).

I'm afraid having a single hyper trigger is not going to be foolproof (unless someone can come up with some neat maths using DCs, but that wouldn't be easily memorable). I guess we'll have to revert to using two triggers. To which, the simplest solution is:







Edit: Okay, there actually is a way to keep it a single trigger:



The reason this works is because "All Players" doesn't count players that are not in the game / have left. Fight quirks with quirks!

Post has been edited 1 time(s), last time on Sep 30 2014, 2:12 am by Roy.

This might is confirmed working, eliminating one condition check:


Edit: Roy got it into one trigger

Post has been edited 3 time(s), last time on Sep 30 2014, 2:32 am by jjf28.

The OP has been edited to reflect the current standard of the HT proposed by our (lovable and brilliant) Roy. This update removes a bug that causes the HT to quit working when a player leaves the game.

What about the NEO? With 3 hyper triggers the NEO is something like 2 days if I recall, but if you compress everything into 1 trigger won't you have a NEO every few minutes?

I'm guessing someone would have noticed that with switch hypers (down with the word "complex"!) already; that being said I don't remember exactly how NEO worked.

Just as a note: the placement in the trigger list is not quite that important (just like with switch hypers). If you put these at the top of the trigger list, it won't block triggers like traditional hyper triggers would (it would merely slow them down by a cycle or two for the two players actively running them) because it's only consuming 2 trigger cycles at a time. That being said, it's still a good idea to have them at the bottom of the list if it's necessary for your wait times to be accurate.

Unlike traditional hyper triggers, these triggers are self-referencing, and are recursively running against each other. Therefore, there is no Next Ending Occurrence.

Though interestingly enough, you could get traditional hyper triggers down into a single trigger by exploiting a similar trick: make a preserved trigger filled with waits, and have it be owned by Players 1-8, Forces 1-4, and All Players. This would guarantee that there would be at least three copies of the trigger. Of course, you'd have to keep them at the bottom of the list (see the note above), but it's certainly another way to compress hyper triggers down. Traditional hyper triggers don't stack across different players, so there will also be no more than three instances of the trigger blocking itself. Therefore, the drawback is that we'd only have a maximum of ~6 hours until the NEO with a single trigger, but that's more than enough time for most maps.

You can find some information in the old wiki, but here's a quick refresher:

We know that there are approximately 12 trigger cycles in a second when using hyper triggers (closer to 11.9, but let's use 12 for simplicity). That is, we are hitting a "Wait(0)" in a hyper trigger 12 times every second. But because of the way SC restarts a preserved trigger for the player, this exponentially increases when we have copies of a hyper trigger. If you have two triggers filled with Wait(0) actions, SC will hit the first trigger's first Wait(0), and then it will block the second trigger on the first Wait(0) as it waits for the previous trigger to complete. When the first trigger burns through all its Wait(0) actions, the second trigger is free to move on to its second Wait(0), but as the first trigger is preserved, SC starts it up again on the next cycle, and the second trigger's second Wait(0) is again blocked by all of the first trigger's Wait(0) actions. You can clearly see the exponential relationship here (all of the first trigger's waits running for every wait found in the second trigger).

We can calculate the number of cycles by knowing the number of waits per trigger (w) and the number of triggers we have (n) to figure out the total number of cycles we go through before reaching the Next Ending Occurrence:

NEO = (w + 1)^n

In the case of three triggers filled with 62 waits each, we burn through 63^3 = 250047 cycles. With roughly 12 cycles per second, this is about 5 hours and 47 minutes. If your game is gonna take longer than that to play, you'd be wise to have an additional trigger.

With switch hypers and the above single hyper trigger, it would be quite apparent if there existed a Next Ending Occurrence because there's only a trivial number of waits that exist. The trick is that an instance of the trigger will always start before the previous instance finishes (by invalidating and re-validating the condition, SC runs the trigger earlier than it would under the "Always" condition), thus never having a point where the game runs through all Wait(0) actions.

The good old hyper trigger, I always wanted to know how this worked but it was such an easy copy n paste type of thing. I feel like the hyper trigger is only good on a map if you really want it to be fast paced. I don't know what exactly it does in the game to make it work as it does but it's always been controlled and pasted at will. It makes any type of map a lot more enjoyable and easier to play and that's why I feel like the hyper trigger will live up to its name. BTW whats the NEO?

It causes triggers to cycle every other frame (or whatever frame multiple you choose). This hyper trigger is a rather recent development due to work spent on it by Roy and I; it is not common or prevalent.

There are a variety of ways of making HTs. The most common ones you will see are several triggers that look like this:




NEO is the Next Ending Occurrence. This is the point at which HTs run out of Waits to "bounce" off of and the entire cycle must be refreshed from the beginning. This increases exponentially the more of these hyper triggers there are. In simple terms, the NEO is the length of time the triggers can run before they run once at the normal rate (about 2 game seconds if I remember right).

The trigger posted in the OP of this thread does not have an NEO due to the structure of its design. The point of it was that we got rid of the NEO and also compressed the method into a single trigger.

That's a common misconception. The fact is that hyper triggers are necessary in any map where you want any triggers to be responsive. Otherwise, you're going to have an inconsistent delay before triggers fire (up to 2 game seconds).

For example, let's say you have a trigger where any air units are killed when they cross some boundary location. Even if this is the only trigger in the entire map, you would want to use hyper triggers, because otherwise the air units will survive for up to 2 game seconds before the trigger kicks in. In the worst case scenario, the player may even get units safely past the location before the trigger can kill them.

The same idea if the trigger is activated by someone stepping on a beacon, or doing anything else; the trigger will not be responsive without the use of hyper triggers.

It should also be pointed out that some conditions may simply not function without hyper triggers; as an example, "Countdown Timer is Exactly ...". Because the triggers are only checked every 2 game seconds, this makes it pretty easy for any specific time to be skipped over.

You could use "Countdown Timer is Exactly 10 seconds", and without hyper triggers it may check the countdown timer at 11, and then check it again at 9. This would result in the trigger never firing (and has caused more than a few broken maps in the assistance forum).

The moral of the story is that you should always use hyper triggers, unless your map doesn't have any triggers to begin with.

Some examples of systems that don't work without hyper triggers:

- Preventing players from attacking allies
- Keeping cannons/forges working without pylons
- De-synchronizing drop hackers using key-presses
- Several kills-to-cash methods

I apologize, I got caught up in the technical details and failed to appropriately address your question. I have an unpublished half-written in-depth guide on HTs and here is an excerpt that you may find enlightening:


I should also add that normal trigger execution occurs two game seconds after the last normal trigger execution, as well. I hope that makes things a bit clearer on how HTs work on a very basic level. I'm afraid a full explanation requires the finishing of my guide, since many concepts that may seem unrelated, such as the game's frame rate, must be understood first.

I don't know why, but this method often breaks replays a lot more than the spamming wait version.

More details: For any given replay, sometimes it will play fine. But if I rewind and click a bunch of stuff, it breaks about 50% of the time with this cave method, whereas it's never broken with the spam wait method.

for a necro on a wonderful post... I don't know how to feel.
But for me, most trigger maps seem to break replays in general - and I have been working on making a map lately that is definitely using this hyper trigger (with 3 computers) and so far I haven't seen it break any replay. But I haven't tried many times.

Randomising a Switch can break replays because it's still random in the replay and can create a divergent outcome.

Since this has already been necroed and for the sake of getting information together.

The following posts from Heinermann are about super hyper triggers that work twice faster and don't require invocation of wait at all (but require an EUD action to set up memory value):
http://www.staredit.net/368631/
http://www.staredit.net/368649/

Whoa! 2021 is around the corner! Wish everyone Happy New Year! Hooray!