Could someone, please, tell me how waits and hypers work? I know that when SC encounters a wait it will first check all other triggers and execute the wait only after that. Mabe I even know a bit more... but I can't sum up everything I know... There is still some uncertanity. I want to know exactly the whole picture in all details how they are working.
Is there someone who could describe me the behaviour of waits and hypers in all details? No incompleteness, please, only strict description.
Thanks.
BTW, in wiki I found only description of how to make hypper triggers, however there is nothing said how it works (at least Maplantis one, SEN wiki seem not to work at the moment).
Edit: (20.05.2008)Well, lets have a little competition!
I'll give 50 minerals to that person who first will intelligiblely explain me (which means povideing the percise algorithm at least) how the whole system with waits works before I figure it out myself.
A year passed and...
...it seems I finally understood how exactly waits system operates in StarCraft!
to the post with detailed explanations.
Edit: (01.05.2011)Several years passed... =)
Finally I got
the answer! Aaaaaand the winner iiiiss Heinermann!
We're glad to congratulate the winner!
Deserved reward is sent
Some.
This is what I posted before in another topic:
Before waits are tested, I think we should establish the current theory on how waits work. Moose recently straightened out a few things and explained certain fuzzy areas to me. Before I've heard that when SC hits a wait it goes and rechecks all the triggers, but I didn't know the specifics and the extent to which it did so and then what it did after.
I'm pretty sure it goes in the following way:
First I'm going to define the trigger order.
All of P1's triggers are run, then P2's and so on, P3 P4 P5 P6 P7 P8.
When a wait is hit, SC goes back and starts checking triggers again, starting with P1.
It goes through each trigger checking the conditions, and running the trigger if it's true, like normal.
It goes through P1's then P2's and so on until P8.
However, for the player that owns the wait, when SC is checking that player's triggers, once it reaches the trigger with the wait again, it will stop checking that player's triggers.
For example if the wait was located in P2's triggers, the following would happen:
It would check all of P1's triggers and then check P2's triggers up until the trigger with the wait. It will then skip the rest of P2's triggers and proceed to check all of P3's and all of the other player's triggers.
Once SC makes one pass through all of the player's triggers, it will then proceed to do the actually waiting of the wait. After the wait period is finished, it will resume from the point it originally left off by executing the actions immediately where the wait was. It will finish that trigger and then keep going normally.
If a wait is encountered when SC is going through its initial single wait-induced pass/check of the triggers, then that whole process will be put on hold, and another check from the beginning will be run.
Essentially the waits are like a "stack" structure, LIFO (last in, first out). If it hits the wait, it puts its current position in the stack and rechecks all the other triggers. Each wait encountered adds to the stack, and the original wait cannot be finished until the last wait put on top of the stack has been completed.
There might be holes in the explanation, but it seems to make sense.
None.
Ah, yes... I remember I had questions though... Well... sorry, all questions a bit later
Some.
Hyper Triggers are just a whole crapload of waits, as short as possible, which is 42 milliseconds, or usually put as 0. The waits all run, and they all get stacked up, and every time one ends, a new one starts 42 milliseconds later and updates the entire trigger list while it's at it. So you get updating every 84 milliseconds.
None.
We can't explain the universe, just describe it; and we don't know whether our theories are true, we just know they're not wrong. >Harald Lesch
I'm not sure if Falk means the right thing, so I'll clarify:
The smallest wait time is 84ms, which seems to be some built-in minimum wait time. From 84ms you can increment the wait times in 42ms steps. So the 2nd smallest wait time is 126, then 168, etc. That means waits can be used to time events with double the accuracy than you'd be able using death counters and hypers.
The Maplantis wiki article also contains an explanation about what waits do when you scroll down:
http://www.staredit.net/maplantis/index.php?sid=03b8dbddda;wiki=6#wiki_4Wait blocks occur when one player is executing 2 waits the same time.
So obviously you should avoid waits when you're using hyper triggers. However there's 3 strategies how you can use hypers and waits:
- Give the hypers to a single player which has no other waits (obvious)
- Give the hypers to all players
and place them at the bottom of the trigger list. The hypers of one player will be blocked when he runs a wait, but the wait will run correctly. The other players' hypers ensure that the hyper trigger effect is still working if not all players run a wait the same time. If they
do all run a wait, the wait itself will run correctly but the hyper trigger effect is offline until the wait ends.
- Use switched hypers (see ML wiki) to temporarily switch off hypers via an additional switch. (Unlike common hypers, switched hypers end as soon as the condition is no longer met)
In the old Tutorials of SEN v4 there was a very detailed explanation how hypers work and in which order the actions are executed. I reformatted my PC and thus lost my link to Doodle's Tutorials which, when I remember correctly, contained this explanation. I'll try to dig it out for ya, or maybe Falk can link you to it.
EDIT:There it is:
http://doodle77.dyndns.org/tutorials.php?id=128
Post has been edited 1 time(s), last time on May 13 2008, 2:54 am by NudeRaider.
The smallest wait time is 84ms, which seems to be some built-in minimum wait time. From 84ms you can increment the wait times in 42ms steps. So the 2nd smallest wait time is 126, then 168, etc. That means waits can be used to time events with double the accuracy than you'd be able using death counters and hypers.
Wrong, the shortest wait time is 42, not 84.
Proof:
1000 Seconds:
Milliseconds: 0 Number of runs: 8007
Milliseconds: 42 Number of runs: 8007
Milliseconds: 84 Number of runs: 5338
Milliseconds: 85 Number of runs: 4004
It's just that the trigger looping causes an extra 42 milliseconds to be added, giving you once every 84 milliseconds.
None.
What would be the particular order of executing wait actions I've labeled:
Example 1.
TRIGGER T1
Owners: Player 1.
Conditions:
Always.
Actions:
A11: Wait 0 milliseconds.
A12: Wait 0 milliseconds.
Preserve trigger.
END T1
TRIGGER T2
Owners: Player 1.
Conditions:
Always.
Actions:
A21: Wait 0 milliseconds.
Preserve trigger.
END T2
If we assume, when encountering a wait, all triggers (excluding those of them which execute at the moment) are previously checked and this is stacked for different waits the sequence must be like this:
( T1( /* before A11 get executed we check all other triggers first */ T2(A21), A11, T2(A21), A12), T2(T1(A11, A12), A21) ). I mean sequence of actions
(A21, A11, A21, A12, A11, A12, A21) with an additional information about what trigger SC remembers to be executing at the moment. But there are 7 waits executing instead of predicted 6 by
http://doodle77.dyndns.org/tutorials.php?id=128. Where am I wrong?
Post has been edited 7 time(s), last time on May 13 2008, 4:08 pm by Wormer.
Some.
We can't explain the universe, just describe it; and we don't know whether our theories are true, we just know they're not wrong. >Harald Lesch
Proof:
1000 Seconds:
Milliseconds: 0 Number of runs: 8007
Milliseconds: 42 Number of runs: 8007
Milliseconds: 84 Number of runs: 5338
Milliseconds: 85 Number of runs: 4004
Which triggers did you make that resulted in this?
Also which speed did you use and is it 1000 game seconds or real-time seconds?
In the old Tutorials of SEN v4 there was a very detailed explanation how hypers work and in which order the actions are executed. I reformatted my PC and thus lost my link to Doodle's Tutorials which, when I remember correctly, contained this explanation. I'll try to dig it out for ya, or maybe Falk can link you to it.
BTW, thanks for the link Nude! I also remember this description. I was reading it back in days... though, didn't understand it quite well.
Some.
If SC is rechecking triggers from the beginning when wait is met, how could you explain the next test is creating only one marine?
Test 1
//-----------------------------------------------------------------//
Trigger("Player 1"){
Conditions:
Switch("Switch1", not set);
Actions:
Preserve Trigger();
Create Unit("Current Player", "Terran Marine", 1, "Anywhere");
}
//-----------------------------------------------------------------//
Trigger("Player 1"){
Conditions:
Always();
Actions:
Preserve Trigger();
Wait(0);
}
//-----------------------------------------------------------------//
Trigger("Player 1"){
Conditions:
Always();
Actions:
Set Switch("Switch1", set);
}
//-----------------------------------------------------------------//
Some.
We can't explain the universe, just describe it; and we don't know whether our theories are true, we just know they're not wrong. >Harald Lesch
Afaik all other player's triggers are rechecked. Not the ones of the same player.
How then we get that exponential growth with classic hyper triggers? And further, reasoning that way we should conclude that the hyper triggers owners' triggers are still executeing one time in two game seconds, which, we know, is not like that.
Post has been edited 1 time(s), last time on May 13 2008, 6:27 pm by Wormer.
Some.
We can't explain the universe, just describe it; and we don't know whether our theories are true, we just know they're not wrong. >Harald Lesch
Now that you mention it, I remember that I was once told that the current player's trigger BELOW the wait are also checked.
Should explain everything...
It seems I began to subconsciously understand how it works... but if one asks me I still would not be able to describe the algorithm.
I wonder, could somebody there distinctly describe the percise algorithm of how SC behave when it hits the wait? The devilesk's
description is not right at least beacause of
this.
Well, lets have a little competition!
I'll give 50 minerals to that person who first will intelligiblely explain me (which means povideing the percise algorithm at least) how the whole system with waits works before I figure it out myself.
Head topic is edited.
Post has been edited 1 time(s), last time on May 20 2008, 11:53 am by Wormer.
Some.
Which triggers did you make that resulted in this?
Also which speed did you use and is it 1000 game seconds or real-time seconds?
It's game seconds, and I did it at fastest, to test I simply had a trigger:
If elapsed game time is at most x(in this case 1000 seconds)
Set Minerals for P1 +1
Preserve Trigger
I always imagined it that every single trigger runs when it hits a wait, since otherwise hypertriggers wouldn't work so well unless at the bottom of the list, I imagine that when a wait is hit, every trigger after the wait is run, then all triggers ahead of the wait are run. Other than that, the theory about wait stacking seems correct.
None.
We can't explain the universe, just describe it; and we don't know whether our theories are true, we just know they're not wrong. >Harald Lesch
Which triggers did you make that resulted in this?
Also which speed did you use and is it 1000 game seconds or real-time seconds?
It's game seconds, and I did it at fastest, to test I simply had a trigger:
If elapsed game time is at most x(in this case 1000 seconds)
Set Minerals for P1 +1
Preserve Trigger
Where's the wait? Did use hypers? Which value had the wait in the hypers?
The Wait was the wait time inside the hypertriggers.
None.
Yeah, gamespeed is sorta irrelevant, except that the actual trigger cycle runs according to it.
None.
Wormer
