Note: This topic contains mostly untested theories and conjectures.

Ok, so I'm finding out how triggers are stored and run in Starcraft, specifically so that I can address this issue in BWAPI.

See the TRIG format to get an idea about the format (may or may not be referenced).

Behaviour Guide
All player's triggers are updated when any these conditions are met:

• Immediately when the game is loaded. This includes saved games. The counters will be reset, not saved.
  
• After 30 frames have passed (1260ms on fastest).
  
• When the countdown timer reaches 1 (decrement from a higher value).
  
• When you press ESC in Single Player and the trigger has debugging enabled, and a wait is currently preventing trigger execution. (Single Player Only)
  
• When a wait is less or equal to the "milliseconds per frame" mark. (See below for info)
  
• When Center View has finished? (Single Player only)
  
• Something involving talking portrait? (Single Player only)
  

When a wait counts down, it subtracts the "milliseconds per frame" value.
See the divisors in this article for that time (in milliseconds).
The article also contains the exact game frame rate, and includes the values for every game speed setting.

Elapsed Time and countdown timer is updated every 15 frames. Leaderboard info is also updated every 15 frames.
Why 15? Because on NORMAL game speed, a frame occurs every 67 milliseconds, and 67ms*15 = 1005ms, which is roughly 1 second. On fastest this is 630ms.

Almost none of these values are saved when you save a game, and are reset upon loading.

As for countdown timer speeding up trigger execution, it can be shown using the following trigger:


Structure

The other "internals" mentioned specifically at the end of a condition and action are just padding the data to a 4-byte alignment and is unused. In a C++ project, it would be correct if you set your alignment to 4 bytes and leave it out completely.

Internals
The "internal usage" fields specified in the TRIG format can be used, since Starcraft copy pastas the entire trigger into memory. The only alterations it appears to make are clearing flags 0x08, 0x01, and setting the current action index to 0.

Primary execution flags

• 0x01 : All Conditions are met, executing actions, cleared on the next trigger loop
  
• 0x02 : Ignore the following actions: Defeat, Draw
  
• 0x04 : Preserve Trigger
  
• 0x08 : Ignore execution
  
• 0x10 : Ignore all of the following actions for this trigger until the next trigger loop: Wait, PauseGame, Transmission, PlayWAV, DisplayTextMessage, CenterView, MinimapPing, TalkingPortrait, and MuteUnitSpeech
  
• 0x20 : This trigger has paused the game, ignoring subsequent calls to Pause Game (Unpause Game clears this flag only in the same trigger), may automatically call unpause at the end of action execution?
  
• 0x40 : Wait skipping disabled for this trigger, cleared on next trigger loop
  

Condition flags

• 0x02 : Ignore execution
  

Action flags

• 0x01 : Executing Wait, ignore this Wait/Transmission and reset this flag on its next call (Ignore a wait/transmission once)
  
• 0x02 : Ignore execution
  
• 0x04 : Always Display
  

As a practical example, you can basically use "Preserve Trigger" without requiring an action (as if it were 65 actions).
See the attached map for proof: [attach=7780]

Attachments:

So what exactly happens when you needlessly spam "Preserve Trigger"? If it indeed takes no actions, you could in theory insert it into a trigger hundreds of times. If it's just a flag, I'd imagine it wouldn't do anything to have it more than once.

I sorta rushed through this since I'm in class, but it seems cool.

Roy, I guess Preserve Trigger simply sets that flag for the trigger upon execution.

This is an invaluable info! Now when you know all these flags, can you please tell how waits really work? What causes wait blocks and what glitch with waits makes triggers execute faster?

I suppose waits clear the ignore execution 0x08 flag upon completion, right?
Ah right, you've written this: "When a wait is less or equal to the "milliseconds per frame" mark. (See below for info)". I'm blind.

Post has been edited 1 time(s), last time on Apr 29 2011, 7:42 pm by Wormer.

Yes, Preserve Trigger is just a flag and additional actions don't change anything.

When wait is called, it sets 0x01 (on specific action) and copies the value given to a per-player variable, which is used to count down before resuming trigger execution. It also sets a per-player boolean value to 1 to identify that it must wait before continuing execution. When another "Wait" is called from another trigger, it reads that per-player boolean and returns because the wait is a global variable and shared across all triggers.

When the function returns from the first Wait call, the action counter doesn't increase, and the "Wait" opcode will be executed a second time. When the Wait is called a second time and the boolean for "is executing wait" is off, it will clear the flag 0x01 that it set earlier and continue execution.

When a Wait from another trigger is called, and the "is Executing Wait" is true, and since this value is global, causes the Wait opcode to return false, halting execution and causing a wait block.

I may not be good at explaining, so here is a code representation:


If a wait is currently being executed for a player, then all waits from all triggers owned by that player will return false. When this function returns false, the action counter is not incremented and attempts to "retry". This causes wait blocks.

In addition to that, the tick counter used to iterate all the triggers is a player-independant global variable. The function behind hyper triggers doesn't care which player owns them since the purpose is to reset a global variable and execute all triggers once more.

In theory you can use hypers with some computer player, then use waits as long as the hyper triggers aren't owned by the same player. Even though you're able to use waits, the hyper triggers will continue to function as expected. There are no wait blocks this way.

When I mention here ignoring Defeat and Draw, it includes all triggers, and not just the one with the flag being set. I actually have no idea what the behaviour is after being set, or the purpose it serves.

Heinermann, you're my hero! The waits problem worries me from the prehistoric era. I was really close! This completely enlightens me: one black triggers behavior spot less! Still got several questions:

1. Why triggers execute every second frame but not the very single frame? Does the triggers tick counter only being checked once in 2 frames?.. Or what?..

2. Still can't understand the following:
If the game second is 15 frames then it should add 7 minerals every game second. Why is there one additional triggers execution cycle each game second?

I've promised 50 minerals the guy who intelligently explains me how waits work! And I'm finally glad to fulfill my promise! The more, you've also answered this question of mine. (Just need to find a way to send mineralzorz now. )

About draw and defeat flag. Do you remember this discussion? You should sorry me for my boldness, but it still was a fruitful topic which leaded to the discovery of a small nuance between single player and multi player SC behavior with the victory action (my personal discovery at least).

Among the rest, there is the following behavior:
This is where 0x02 flag is getting used. This actually looks very like a "Victory Flag", but I can't understand why blizzards put it among trigger specific flags since it works globally, as you've stated. If you're asking about the purpose it serves, I can only make an assumption blizzards made a failsafe against a situation when both victory and defeat (or draw) conditions are met (which might not be *that* rare circumstance since blizzards haven't known about hyper triggers ). There may even be a campaign map which uses this glitch feature. Oh those blizzard programmers, those lazy blizzard programmers!

Post has been edited 5 time(s), last time on May 1 2011, 10:02 am by Wormer.

I am completely, and utterly, confused. I don't see what the relevance, or 'new information' in Heinermann's first post is. Has he uncovered a useful new mechanic behind trigger conditions that we can use to make our maps better? If so, what is it? Something to do with the preserve trigger action?

He said he discovered that we can have preserve triggers without having a single preserve action inside the trigger. That is a small piece but still.

Basically Heinermann just found proof (the actual code) for theories regarding hyper trigger / wait behavior which were already floating around for a long time. Since Wormer is a very technical guy that loves having everything in unmisunderstandable, code-like form he's very excited about this.

Personally I find the framerate explanations most useful.

From what I understand, it copies trigCounter to a temporary variable, decrements it, and compares the old temporary variable to 0.
See http://stackoverflow.com/questions/2783239/increment-and-decrement-operators

When it resets trigCounter, it sets it to 1. The statement compares it to 1, then decrements it and it becomes 0 on the next frame.

Not sure... but there must be some logic behind it since it's adding +1 for the number of triggers that exist. What happens when you just add another trigger but don't increment the count?

I had no idea.

AFAIK nothing actually sets this flag. Victory trigger just sets a player-specific byte to "victory", ignores the flag completely. Draw and defeat compare against both that byte(to create the behaviour you mentioned) and the flag(which is separate and "unused?"). The flag actually sets the endgame byte to something else which may have an unknown influence at the end of the match. I haven't actually tested it yet.

Haven't undnerstod what you ask, but if you look this simple test map, there is a question why you end up with 7 minerals but with 8 gas?

EDIT:
Maybe there is a different opcode for victory in single and multi player?

EDITEDIT:
How I wish it was !--trigCounter

Post has been edited 1 time(s), last time on May 1 2011, 6:11 pm by Wormer.

The other counters, including the one for elaped time also run the same way (!variable--) (which means it increases every 16 frames and not 15 (?).
Let's try playing this out:

FRAME 0

• Set trigCounter to 1
  
• Set elapsedTimeCounter to 15
  
• elapsedTimeCounter is subtracted (14)
  
• trigCounter is subtracted
  

FRAME 1

• elapsedTimeCounter is subtracted (13)
  
• trigger execution, add 1 mineral (1)
  
• Hyper trigger sets trigCounter to 1
  

FRAME 2

• elapsedTimeCounter is subtracted (12)
  
• trigCounter is subtracted
  

FRAME 3

• elapsedTimeCounter is subtracted (11)
  
• trigger execution, add 1 mineral (2)
  
• Hyper trigger sets trigCounter to 1
  

FRAME 4

• elapsedTimeCounter is subtracted (10)
  
• trigCounter is subtracted
  

FRAME 5

• elapsedTimeCounter is subtracted (9)
  
• trigger execution, add 1 mineral (3)
  
• Hyper trigger sets trigCounter to 1
  

FRAME 6

• elapsedTimeCounter is subtracted (8)
  
• trigCounter is subtracted
  

FRAME 7

• elapsedTimeCounter is subtracted (7)
  
• trigger execution, add 1 mineral (4)
  
• Hyper trigger sets trigCounter to 1
  

FRAME 8

• elapsedTimeCounter is subtracted (6)
  
• trigCounter is subtracted
  

FRAME 9

• elapsedTimeCounter is subtracted (5)
  
• trigger execution, add 1 mineral (5)
  
• Hyper trigger sets trigCounter to 1
  

FRAME 10

• elapsedTimeCounter is subtracted (4)
  
• trigCounter is subtracted
  

FRAME 11

• elapsedTimeCounter is subtracted (3)
  
• trigger execution, add 1 mineral (6)
  
• Hyper trigger sets trigCounter to 1
  

FRAME 12

• elapsedTimeCounter is subtracted (2)
  
• trigCounter is subtracted
  

FRAME 13

• elapsedTimeCounter is subtracted (1)
  
• trigger execution, add 1 mineral (7)
  
• Hyper trigger sets trigCounter to 1
  

FRAME 14

• elapsedTimeCounter is subtracted (0)
  
• trigCounter is subtracted
  

FRAME 15

• elapsed time increases, elapsedTimeCounter is reset to 15
  
• trigger execution, add 1 gas (1)
  
• Hyper trigger sets trigCounter to 1
  

FRAME 16

• elapsedTimeCounter is subtracted (14)
  
• trigCounter is subtracted
  

FRAME 17

• elapsedTimeCounter is subtracted (13)
  
• trigger execution, add 1 gas (2)
  
• Hyper trigger sets trigCounter to 1
  

FRAME 18

• elapsedTimeCounter is subtracted (12)
  
• trigCounter is subtracted
  

FRAME 19

• elapsedTimeCounter is subtracted (11)
  
• trigger execution, add 1 gas (3)
  
• Hyper trigger sets trigCounter to 1
  

FRAME 20

• elapsedTimeCounter is subtracted (10)
  
• trigCounter is subtracted
  

FRAME 21

• elapsedTimeCounter is subtracted (9)
  
• trigger execution, add 1 gas (4)
  
• Hyper trigger sets trigCounter to 1
  

FRAME 22

• elapsedTimeCounter is subtracted (8)
  
• trigCounter is subtracted
  

FRAME 23

• elapsedTimeCounter is subtracted (7)
  
• trigger execution, add 1 gas (5)
  
• Hyper trigger sets trigCounter to 1
  

FRAME 24

• elapsedTimeCounter is subtracted (6)
  
• trigCounter is subtracted
  

FRAME 25

• elapsedTimeCounter is subtracted (5)
  
• trigger execution, add 1 gas (6)
  
• Hyper trigger sets trigCounter to 1
  

FRAME 26

• elapsedTimeCounter is subtracted (4)
  
• trigCounter is subtracted
  

FRAME 27

• elapsedTimeCounter is subtracted (3)
  
• trigger execution, add 1 gas (7)
  
• Hyper trigger sets trigCounter to 1
  

FRAME 28

• elapsedTimeCounter is subtracted (2)
  
• trigCounter is subtracted
  

FRAME 29

• elapsedTimeCounter is subtracted (1)
  
• trigger execution, add 1 gas (8)
  
• Hyper trigger sets trigCounter to 1
  

FRAME 30

• elapsedTimeCounter is subtracted (0)
  
• trigCounter is subtracted
  

FRAME 31

• elapsed time increases, elapsedTimeCounter is reset to 15
  

...

And that roughly shows why it produces 7 minerals and 8 gas.

I thought it runs the first trigger loop at frame 0 due to this ("immediately when the game is loaded"). But yeah 16 frames for a game second is more sensible (due to !variable--)... Still in the process of understanding where one trigger execution is missed during the first second.

EDIT:
Also, isn't trigCounter initially set to 30? And then it is set to 1 only when the wait timer for a player is less or equal to 42?..

Post has been edited 5 time(s), last time on May 1 2011, 8:30 pm by Wormer.

By "All player's triggers are updated when any these conditions are met" I meant that the trigCounter is set to 1 in this case.
The counter is reset to 30 only after each execution.

Also this doesn't explain the following: if you put the condition "Elapsed time is exactly 2 game seconds" instead of "Elapsed time is exactly 1 game seconds" you will also end up with 8 gas. Generally if you put "Elapsed time is exactly X game seconds", where X > 0 you will end up with 8 trigger executions (manually tested for several first numbers X). If you write frames 30-44 you will end up only with 7 trigger executions, as during the first second. It's due to the fact that the trigger execution will start with shift of 1 frame to the frame where it resets the countdown counter (as during the first second). This only explains that triggers should run 7 times at even game seconds and 8 times at odd. But instead we have 1 execution missed only during the first game second.

EDIT:
Is there another counter to count down 30 frames? Does it reset when triggers execute due to wait side effect?

EDITEDIT:
Wait, I must be wrong somewhere...

Post has been edited 1 time(s), last time on May 1 2011, 8:36 pm by Wormer.

That's because when the game starts, it initially sets the counter to 15. The game is completely initialized and then immediately calls these functions on frame 0. So frame 0 it becomes 14. But when it reaches 0, it resets to 15, and subtracts it in the NEXT frame.

Yeah, you're right. The frame 0 doublejobs as set to 15 and "subtract one" at the same time, further these actions occur in different frames. Thank you for explanation!

EDIT:
Still want to know this, because there was an attempt to make infinite triggers with one player using 15 waits, so that it exits from the trigger exactly when NEO occurs.

Now I see. And it is set to 1 every time the the wait timer for a player finishes (<= 42 on fastest).

EDITEDIT:
And the other instances you've listed of course... (Forward quote FTW!)

Post has been edited 3 time(s), last time on May 1 2011, 8:58 pm by Wormer.

I'm not sure what you mean by that, but I listed all instances where the trigger frame counter was set to 1.

EDIT:
OK. When a player is given a victory, all other players are given a Defeat automatically.
However, when the flag 0x02 is set on at least one of the triggers owned by that player, then the player is given a Draw if another player has received a Victory.

Note: There are some other restrictions on this as well.

EDIT2:
I JUST found this out, but for some reason, the computer AI (expansion custom level, all races) will expand to a rescuable's Start Location regardless if there are resources nearby or not. Both players are set up as follows:

• Player 7, Rescuable, User Select
  
• Player 8, Computer, User Select

Why is this significant? Because there doesn't need to be any resources at all near the expansion location. Why does this happen? No clue.
In fact, it will ignore the best placement for resource gathering and focus on the non-existent Start Location.

Post has been edited 3 time(s), last time on May 2 2011, 3:16 pm by Heinermann.

Just found out some mildly useless effect.
If you pause for 2147483647 (0x7FFFFFFF) ms in a briefing, the animations for the buttons and smk will freeze.
If you apply this to the TalkingPortrait (in-game) action, it will show static (forever). The static won't be animated unless you Preserve Trigger.

EDIT: When this is done, your resource count, supply, and minimap position (white rectangle) don't update either. So you could have 1000 minerals and it would still say 0.

Post has been edited 1 time(s), last time on May 9 2011, 3:54 am by Heinermann.

Yay! It's pretty interesting, because there were cases when I wanted to do victory for one player and draw for the others but was limited with the defeat. Still I'm too lazy to use it until it got implemented into some tool

Heinermann found the infinity!

BTW, there is a modifier (Set, Add, Subtract) in transmission action. Due to transmission acting as a wait, always wondered if it's really possible to add or subtract to the wait timer of a player?

Now as I'm thoroughly thinking about it once again, the game second (except of the first exclusive one) appears to happen every 16 frames (1072 milliseconds on Normal speed) instead of stated 15, doesn't it?

EDIT:
Oh right... Slap. 16. Right???

EDIT2:
I wonder if there is the same bug feature when they count down milliseconds? Or is it a system call?

EDIT3:
By the way I wonder if wait period and execution of frame commands are parallel. Because if they don't, there is no much reason to use prolongated hyper triggers to reduce trigger lag.

Post has been edited 6 time(s), last time on May 24 2011, 9:46 am by Wormer.