Difference between revisions of "Wait blocks"

Revision as of 21:56, 2 August 2015

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.

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:

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:

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