Staredit Network > Forums > SC1 UMS Theory and Ideas > Topic: The Hyper Trigger
The Hyper Trigger
May 21 2014, 10:19 am
By: Sacrieur  

May 21 2014, 10:19 am Sacrieur Post #1

Still Napping

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

Trigger
Players
  • All Players
  • Conditions
  • All Players has suffered exactly 0 deaths of Cave.
  • Actions
  • Modify death counts for Current Player: set to 1 for Cave.
  • Wait for 0 milliseconds.
  • Modify death counts for Current Player: set to 0 for Cave.
  • Wait for 0 milliseconds.
  • Preserve trigger.


  • Code
    Trigger("All players"){
    Conditions:
        Deaths("All players", "Cave", Exactly, 0);

    Actions:
        Set Deaths("Current Player", "Cave", Set To, 1);
        Wait(0);
        Set Deaths("Current Player", "Cave", Set To, 0);
        Wait(0);
        Preserve 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.



    None.

    May 21 2014, 10:34 am Oh_Man Post #2

    Find Me On Discord (Brood War UMS Community & Staredit Network)

    cool!




    May 21 2014, 12:14 pm Roy Post #3

    An artist's depiction of an Extended Unit Death

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

    Trigger
    Players
  • All Players
  • Conditions
  • (X is true).
  • Actions
  • (Make X false).
  • Wait for 0 milliseconds.
  • (Make X true).
  • Wait for 0 milliseconds.
  • Preserve Trigger.


  • Examples


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




    May 21 2014, 12:22 pm Sacrieur Post #4

    Still Napping

    Quote from Roy
    Nice discovery, Sacrieur!

    ^ It was a joint discovery by me and Roy.



    None.

    Sep 29 2014, 2:45 am Zoan Post #5

    Math + Physics + StarCraft = Zoan

    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.



    \:rip\:ooooo\:wob\:ooooo \:angel\: ooooo\:wob\:ooooo\:rip\:

    Sep 30 2014, 1:36 am Roy Post #6

    An artist's depiction of an Extended Unit Death

    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:

    Safe Hyper
    Players

  • All Players
  • Conditions

  • Countdown timer is exactly 0 game seconds.
  • Actions

  • Modify Countdown Timer: Set to 1 seconds.
  • Wait for 0 milliseconds.
  • Modify Countdown Timer: Set to 0 seconds.
  • Wait for 0 milliseconds.
  • Preserve Trigger.


  • 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:

    Redundant Hyper
    Players

  • All Players
  • Conditions

  • Switch 256 is cleared.
  • Actions

  • Set Switch 256.
  • Wait for 0 milliseconds.
  • Clear Switch 256.
  • Wait for 0 milliseconds.
  • Clear Switch 256.
  • Wait for 0 milliseconds.
  • Preserve Trigger.


  • 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:


    Hyper One
    Players

  • All Players
  • Conditions

  • Switch 256 is cleared.
  • Actions

  • Set Switch 256.
  • Wait for 0 milliseconds.
  • Preserve Trigger.


  • Hyper Two
    Players

  • All Players
  • Conditions

  • Switch 256 is set.
  • Actions

  • Clear Switch 256.
  • Wait for 0 milliseconds.
  • Preserve Trigger.



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

    Hyper Trigger X
    Players

  • All Players
  • Conditions

  • All Players suffered exactly 0 deaths of Cave.
  • Actions

  • Set Deaths of Cave for Current Player: Set to 1.
  • Wait for 0 milliseconds.
  • Set Deaths of Cave for Current Player: Set to 0.
  • Wait for 0 milliseconds.
  • Preserve 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.




    Sep 30 2014, 2:14 am jjf28 Post #7

    Cartography Artisan

    This might is confirmed working, eliminating one condition check:

    Quote from name:Small Code Boxes Suck
    Trigger("All players"){
    Conditions:
        Switch("Switch256", not set);

    Actions:
        Set Switch("Switch256", set);
        Wait(0);
        Preserve Trigger();
    }

    Trigger("All players"){
    Conditions:
        Always(); // Can be excluded so you have no conditions

    Actions:
        Set Switch("Switch256", clear);
        Wait(0); // Wait blocked if first wait has run this cycle
        Preserve Trigger();
    }

    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.



    TheNitesWhoSay - Clan Aura - github

    Reached the top of StarCraft theory crafting 2:12 AM CST, August 2nd, 2014.

    Sep 30 2014, 12:38 pm Sacrieur Post #8

    Still Napping

    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.



    None.

    Oct 2 2014, 9:38 pm Vrael Post #9



    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?



    None.

    Oct 2 2014, 10:04 pm jjf28 Post #10

    Cartography Artisan

    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.



    TheNitesWhoSay - Clan Aura - github

    Reached the top of StarCraft theory crafting 2:12 AM CST, August 2nd, 2014.

    Oct 3 2014, 1:20 am Roy Post #11

    An artist's depiction of an Extended Unit Death

    Quote from Sacrieur
    This trigger has the same limitations as the traditional hyper triggers, and still needs to be put on the bottom of the trigger list to avoid wait blocks when using waits.
    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.

    Quote from Vrael
    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?
    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.

    Quote from jjf28
    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.
    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.




    Mar 8 2015, 8:00 am ETEFT(U) Post #12



    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?



    None.

    Mar 8 2015, 2:21 pm Sacrieur Post #13

    Still Napping

    Quote from ETEFT(U)
    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.

    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:

    Hyper Trigger
    Players

  • All Players
  • Conditions

  • Always
  • Actions

  • Wait 0 milliseconds.
  • Wait 0 milliseconds.
  • Wait 0 milliseconds.
  • ...
  • Wait 0 milliseconds.
  • Preserve trigger.
  • Comment: "Hyper Trigger".


  • Quote
    BTW whats the NEO?

    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.



    None.

    Mar 12 2015, 2:21 pm Azrael Post #14



    Quote from ETEFT(U)
    I feel like the hyper trigger is only good on a map if you really want it to be fast paced.
    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.




    Mar 12 2015, 3:36 pm jjf28 Post #15

    Cartography Artisan

    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



    TheNitesWhoSay - Clan Aura - github

    Reached the top of StarCraft theory crafting 2:12 AM CST, August 2nd, 2014.

    Mar 13 2015, 2:39 pm Sacrieur Post #16

    Still Napping

    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:

    Quote
    The wait action was originally intended to be used just as its name suggests: as a buffer of time between actions. When Starcraft encounters a wait, it adds time to a player's wait timer and then finishes executing the trigger list, skipping over the actions listed after the wait.

    Instead of deferring the actions in the trigger after a wait is completed, Starcraft runs through the trigger list as normal. When the trigger with the wait has been reached, actions after the wait are executed. The triggers thereafter are executed normally. This is the only difference between a wait trigger execution and a normal trigger execution. Normal execution is resumed two game seconds after a wait trigger execution has completed.

    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.




    Sep 13 2020, 7:00 pm StRyKeR17 Post #17



    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.



    None.

    Oct 7 2020, 1:50 am sraw531 Post #18



    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.



    None.

    Oct 7 2020, 5:32 am Oh_Man Post #19

    Find Me On Discord (Brood War UMS Community & Staredit Network)

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




    Dec 30 2020, 1:27 pm Wormer Post #20



    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! :w00t: 2021 is around the corner! Wish everyone Happy New Year! Hooray! :lol:



    Some.

    Options
      Back to forum
    Please log in to reply to this topic or to report it.
    Members in this topic: None.
    [06:11 am]
    NudeRaider -- you could also make it several actions, each one for a specific player just to make sure sc doesn't do wonky stuff
    [06:30 pm]
    Ultraviolet -- boi that's what I just said
    [06:16 pm]
    Vrael -- bit verbose but if you're just doing it once not much of a problem
    [06:16 pm]
    Vrael -- you can also just one trigger action for each player in the force if you want to be sure they all get set
    [2024-10-14. : 2:22 pm]
    Ultraviolet -- I think it works fine in that scenario, but as a general rule, if you try specifying a force and it doesn't work then just redo the trigger(s) with a separate condition or action for each player you wanted to target. I'm not sure exactly when, but I think there are scenarios when using forces instead of targeting specific players doesn't work
    [2024-10-14. : 2:20 pm]
    Ultraviolet -- Should be all of them
    [2024-10-13. : 8:47 pm]
    ClansAreForGays -- If I set "Force 1" to enemy via set allaince trigger, will it set all players in that force to enemy? Or just one of them?
    [2024-10-12. : 5:06 pm]
    Ultraviolet -- Zoan
    Zoan shouted: I'm in Georgia; somehow it seems to have been a lot worse for you guys even though you're all more north
    Yeah it was completely unexpected up here, like we've seen a bit of storminess from hurricanes and tropical storms in the past, but nothing like this. Absolute devastation. The mountain I live on has like half the trees just flattened. Looks like a war zone
    [2024-10-10. : 7:46 pm]
    Vrael -- NudeRaider
    NudeRaider shouted: everyone gets their own message! How thoughtful! :wub:
    ill thinkful your message
    [2024-10-09. : 7:27 pm]
    NudeRaider -- everyone gets their own message! How thoughtful! :wub:
    Please log in to shout.


    Members Online: dumbducky, Varun