The wait action should interface directly with the engine timing system (otherwise it is needlessly complicated). Also, if the precision of your waits is being disrupted by timer granularity, high-level speed settings are the last of your concerns

Okay, it seems I finally understood how exactly waits system operates in StarCraft!

There is a separate timer I(P) for each player P. The timer is a system object of some kind. The only thing that matters for the external observer is that the timer can be found in three different states: "raised", "activated" and "idle". When timer is raised it has it's internal counter decreasing from some value downto 0. Decrease speed does not affected by game speed and is done in realtime by system clock. When counter reaches 0 the timer automatically transfers into activated state. At start of the game all timers are idle.

I don't know how timer is implemented but imagine it as an integer variable which could take values from -2 to MAXINT. The value -2 represents the idle state, -1 represents the activated state and all other values represent the raised state. When timer is raised it's value constantly decreases downto -1 (included) and then stops.

1. When during execution of trigger T for player P StarCraft encounters a Wait(N) action W (T and W are not marked, see below) it looks at the state of the timer I(P) for that player.
1.1. If I(P) is idle or activated then SC assigns I(P)=N which transfers the timer into raised state. Then it marks trigger T as "incomplete" and wait action W in the trigger as "executed". After this it continues with triggers starting with the trigger following T.
1.2. If I(P) is raised then SC marks trigger T as incomplete and the wait action W as "delayed". After doing so it continues with triggers starting with the trigger following T.

2. When during execution of triggers for player P StarCraft encounters a trigger T which is marked as incomplete with the Wait(N) action W marked as incomplete or delayed the behavior depends on the state of the timer I(P).
2.1. If the timer I(P) is raised then SC simply ignores trigger T and continues with the execution of the next trigger for that player.
2.2. If the timer I(P) is idle or activated the behavior depends on the mark of the wait action W.
2.2.1. If action W is marked as executed SC transfers I(P) into idle state, clears marks on T and W and continues with the execution of actions with the action next to W.
2.2.2. If action W is marked as delayed SC assigns I(P)=N which transfers the timer into raised state. Then it retains trigger T mark incomplete and marks wait action W in the trigger as executed. After this it continues with triggers starting with the trigger following T.

And the last but not the least. Why the number of triggers executions per game second with hypers does not depend on the game speed?
We all know the game divides in frames. I believe frames rate is game speed dependent and there are always 16 frames in a game second (please, someone correct me if I am wrong here!). Every second frame starcraft checks timers for all players, if at least one timer is activated SC starts extra trigger loop. SC also starts the normal trigger loop every 16th frame regardless of whether timers are active or not.

This explains everything to me. If anyone find any errors or inconsistencies with the actual SC behavior please let me know, I am still not 100% sure. Feel free to ask questions.

Post has been edited 8 time(s), last time on May 17 2009, 7:28 pm by Wormer.

Hmm, it doesn't seem to correlate with the old idea that it rechecks all the triggers when it encounters a wait, did you explain that anywhere?

He mentioned that in the last paragraph.

I think a simple test can determine if SC runs at 16 frames per game second, and normal runs at 15 fps. It's well known that fastest is 24 fps, and it fits that each speed down is decreased by 3.
24 fastest
21 faster
18 fast
15 normal
12 slow
9 slower
6 slowest

If real time and game time are never equal, then we have a probable match. I think I may have an explanation for the 42-43 cutoff, and the 84-85 cutoff. 1/24=.041667, which is 41.667 ms. This number is rounded up to 42 automatically, since SC can't handle the decimals. Or, perhaps, it's not actually 24 fps, but 23.8 fps.

I've also noticed that wait blocks don't always work the way you think they should. Since I never use waits except for hypers, I haven't bothered.

Yes, it rechecks triggers as a side effect of checking timers for players. When the timer becomes activated it runs an extra trigger loop.

One thing I've noticed is when you have a trigger T(0) running with hyper triggers, where T(x) is {C:Elapsed time at most x; A:Add 1 mineral}, you end up with 7 minerals. When you have trigger T(1) you end up with 15 minerals, T(2) will leave you with 23 and +8 minerals each next second. But the first second is only 7 trigger loops.

If there were 15 frames per game second and triggers were running every second frame then we would have been observing it repeatedly runs 7 and 8 trigger loops per game second:

Frames: 1  2  3  4  5  6  7  8  9  10 11 12 13 14 15 || 1  2  3  4  5  6  7  8  9  10 11 12 13 14 15
TLoops: 1     2     3     4     5     6     7     8  ||    1     2     3     4     5     6     7

Or probably it runs trigger cycle each frame between 15 and 1:

Frames: 1  2  3  4  5  6  7  8  9  10 11 12 13 14 15 || 1  2  3  4  5  6  7  8  9  10 11 12 13 14 15
TLoops: 1     2     3     4     5     6     7     8  || 1     2     3     4     5     6     7     8

If we have 16 frames everything is even:

Frames: 1  2  3  4  5  6  7  8  9  10 11 12 13 14 15 16 || 1  2  3  4  5  6  7  8  9  10 11 12 13 14 15 16
TLoops: 1     2     3     4     5     6     7     8     || 1     2     3     4     5     6     7     8

Or probably this way?

Frames: 1  2  3  4  5  6  7  8  9  10 11 12 13 14 15 16 || 1  2  3  4  5  6  7  8  9  10 11 12 13 14 15 16
TLoops:    1     2     3     4     5     6     7     8  ||    1     2     3     4     5     6     7     8

I stated that
This first loop is marked as red on diagrams.

I was trying to make hyper triggers using one player which run infinitely. This was based on the idea to have 8 waits in a trigger to time the NEO exactly when the first frame in the second executes so it fills the gap. I've tried next triggers:

T1{C:Switch s is Set; A:Preserve Trigger; 8 "Wait 0" actions;}
T2{C:Always; A:7 "Wait 0" actions; Set switch s;} // remember the first second runs only 7 trigger loops

but it didn't work for some reason. So probably the statement
is wrong.

Post has been edited 4 time(s), last time on May 24 2009, 8:03 am by Wormer.

Well, I think at the start of the game a frame is skipped or something, because all my tests have shown the same thing.


I think that it may not be the 16th frame, however, I'm betting it starts it somewhere.. Perhaps the first frame? That seems like it would make a bit more sense since from my experience it looks like at the start of the game SC runs all the triggers immediately, this also might coincide with the skipped frame theory.

Who would've thought waits would be so much more complicated than death counters?

Where are waits stored in memory, I wonder?
http://www.staredit.net/topic/6771/

What is complicated about death counters?

rockz, these are very interesting things!.. But now I become misled.

There are more questions than answers in my head.

Finally I got the answer! Aaaaaand the winner iiiiss Heinermann! We're glad to congratulate the winner!
Deserved reward is sent

P.S. Can close the topic now.