Difference between revisions of "Wait blocks"
m |
m (adding to the Reference category) |
||
Line 112: | Line 112: | ||
[[Category:StarCraft]] | [[Category:StarCraft]] | ||
+ | [[Category:Reference]] |
Latest revision as of 04:58, 23 November 2019
Wait blocks are trigger-related issues in StarCraft maps. They occur when the game tries to execute two Wait actions at the same time. Only one Wait action may be run at a time, so if a second is encountered, it is forcibly delayed until the first completes.
Wait blocks commonly occur when a map's triggers use both Waits and Wait-based hyper triggers.
Contents
Inner workings of the Wait action
Wait actions do more than just delaying other trigger actions by a given amount of milliseconds. When StarCraft runs a trigger for a player and encounters a Wait action, it takes the triggers that it has already processed for that player, and re-processes them all. Then, the game delays the actions following the Wait. Consider a map with the following two triggers:
- Player 1
- Always
- Create 1 Terran Marine at Anywhere for Player 1.
- Preserve trigger.
- Player 1
- Always
- Display for current player:Hello!
- Wait 1000 milliseconds.
- Display for current player:Goodbye!
- Preserve trigger.
When those triggers are processed, StarCraft will do the following:
- Create a Terran Marine for Player 1.
- Display "Hello!" on Player 1's screen.
- Process the Wait action, by re-executing all Player 1 triggers.
- Create a Terran Marine for Player 1.
- Wait for a full second.
- Display "Goodbye!" on Player 1's screen.
That would be one trigger cycle.
Wait blocks
The problems come when two Waits exist for the same player. Consider these triggers:
- Player 1
- Always
- Create 1 Terran Marine at Anywhere for Player 1.
- Wait 1000 milliseconds.
- Create 1 Terran SCV at Anywhere for Player 1.
- Preserve trigger.
- Player 1
- Always
- Display for current player:Hello!
- Wait 1000 milliseconds.
- Display for current player:Goodbye!
- Preserve trigger.
When StarCraft processes those triggers, it will do the following:
- First trigger round
- Create a Terran Marine for Player 1.
- Increase wait timer by 1000 (TRIGGER 1)
- Display "Hello!" on Player 1's screen.
- There is already a wait on the wait timer, so wait until it's over to continue
- Wait for a full second. (TRIGGER 1)
- Create a Terran SCV for Player 1.
- Increase wait timer by 1000 (TRIGGER 2)
- Next trigger round
- Create a Terran Marine for Player 1.
- There is already a wait on the wait timer, but it's from a previous round, so increase wait timer by 1000 (Trigger 1)
- Wait for 2 seconds. (TRIGGER 1+2)
- Next trigger round
- Create a Terran SCV for Player 1.
- Display for current player:Goodbye!
- The Wait action here cannot be processed, because the game is already processing a Wait action. This Wait and any remaining actions in this trigger (TRIGGER 1) will be delayed.
- Wait for a full second.
- Execute any delayed trigger actions.
- Process the delayed Wait from TRIGGER 1.
- There are no Player 1 triggers before TRIGGER 1.
- Wait for a full second.
- Create a Terran Marine for Player 1.
- Process the delayed Wait from TRIGGER 1.
- Display "Goodbye!" on Player 1's screen.
That is a full trigger cycle. In simpler terms, here is what happens:
- Create a Terran Marine for Player 1.
- Display "Hello!"
- Wait for a full second. (TRIGGER 1)
- Create a Terran SCV for Player 1.
- Create a Terran Marine for Player 1.
- Wait for a full second. (TRIGGER 2)
- Wait for a full second. (TRIGGER 1)
- Essentially, the two waits are combined.
- Create a Terran SCV for Player 1.
- Display "Goodbye!"
In simple systems, this is often only a minor annoyance... But when large amounts of waits are used (as is the case when using Wait-based hyper triggers), the combined Wait time can cause a massive (or even infinitely long) wait block, completely breaking the map's triggers.
Why do Waits behave this way?
The reason that previous triggers are re-processed when a Wait is run is to prevent problems in the trigger system. If triggers were not re-processed, then for the above example, there would be a full second where no triggers can run. (This would translate to a full second in which no Marines are created.) In maps that need to detect things like unit locations and deaths, this would be a catastrophic delay. Any kind of map that requires precision or timing would end up completely broken. By re-processing the trigger list, StarCraft is able to delay trigger actions without breaking the trigger system. Wait blocks are simply an unanticipated problem in this system.
Solutions
- When using Wait-based hyper triggers, set them up properly. Alternatively, switch to "complex" hyper triggers, which are (ironically) much easier to set up and maintain.
- Avoid situations where a player could end up running multiple Waits at once.
- Use different methods to keep track of time. Timers can use death counters, countdown timers, the movement of a unit from one location to another, or even the burning and destruction of a badly-damaged Terran building (using the death counters or Extended Unit Deaths to detect certain values.)
External links
- A YouTube video illustrating how waits are processed, using some of the example triggers in this article.