Player 1
Player 2
Player 3
Player 4
Player 5
Player 6
Player 7
Player 8
All Players
Force1
Force2
Force3
Force4

What this means is a trigger for player one will execute before a trigger for player two will execute. This also means that the lower numbered players will have a slight advantage if two or more players are racing to get to a trigger location since the lower numbered player will be the one that activates it first if two players set off a trigger at the same time.

Within a section that contains multiple players (like All Players or one of the Forces) the triggers will be checked in player order within that group. Suppose you have several triggers set to All Players in the Players tab. All of those triggers will be checked for Player 1, then they will all be checked again for Player 2 and so forth all the way to player 8. This also holds true for triggers that apply to Forces, with players going in order and only the players that are actually in that force being checked.

How long does it take for a trigger action to take place?
Many trigger actions take place instantly and can be checked by the conditions of the very next trigger that is firing (such as setting switches). Other actions take more time to complete and may require a wait or short delay before testing against or modifying the results of the action. A typical example of a "slow" action would be moving or creating units. If you create or move a unit, you may wish to put a short pause (100 milliseconds or so) before checking if that unit is there with another trigger's conditions or modifying that unit with the action of some other trigger. Fast actions are setting switches, resources or score while slow actions are moving or placing of units.

Can you apply properties (cloaked, irradiated, etc.) with a trigger?
In some cases, you must set properties on a unit (cloaked, burrowed, hallucinated, etc.) when you place it on the map or through the "Create Unit with Properties" action. There are several instances where you can set the properties in game with triggers. With the Set Invincibility trigger you can either set or disable invincibility for units. You can also use the Modify Hanger count to increase the number of interceptors in a Carrier or the number of Scarabs in a Reaver.

With the Modify Unit Hit Points, Modify Energy or Modify Unit Shield Points actions you can set the number of hits, energy points or shields a unit has. However, the values can only be set to percentage values of the maximum energy, hit points, or shield points that the unit possesses. You may not add or subtract points from their current values. For example, with these trigger actions you could set a nearly dead Marine's hit points to 50%, but the action will set the hit points to 20 (a Marine's maximum hit points are 40) and not 50% of the hit points he had in game at that instant. There is also no condition that can check for the values of hit points, energy, or shield points.

What are switches?
Switches are analogous to Boolean values in programmer parlance. Essentially, they are used to indicate either an "on" or "off" condition. You can use them however you like. They are most useful for preserving state across triggers. You might, for example, set a switch if a certain hero is killed if you want to defer taking action on it until a later time. Then, you could test the state of that switch to see if it was "set" or "reset", even though the event that caused to be set might no longer be detectable.

Is there any way to make triggers with programming language constructs like "if-then-else" or "do-while" loops?
The trigger system is designed primarily for accessibility and does not support higher-level programmer constructs directly. By using switches and keeping in mind that triggers are executed in order, it is possible to do an if-then-else. A do-while is more difficult, but can be done if time is not critical (a single trigger will not fire more than once every 2 game seconds) and the expected number of iterations is small.

What about variables and constants?
There is no support for the allocation of variables or constants in StarEdit. In selecting features to implement in the trigger system, we prioritized those features needed to complete StarCraft's retail campaigns and custom maps.

StarEdit does allow you to modify and reference a single "Custom Score" field for each player. In some cases, this can be used in the place of a variable. Custom Score related conditions Custom Score related actions Score Set Score Highest Score Leaderboard(points) Lowest Score Leader board goal (points) In addition you can use the minerals and gas as well as all of the score types as variables for each player that is not an active player in the game. This means if you have a six player game, then you can use the mineral, gas, kills, razings, custom, etc for those two players as variables. You can refer to the StarEdit help file for details on any of these conditions or actions.

Will future Blizzard Entertainment titles use the trigger system?
No. As with every feature in every game, we view the trigger system as a stepping-stone to bigger and better things. While the trigger system served its purpose, our plan is to provide better and more powerful ways for people to customize our games in the future.

Can I enter triggers in a text file and import them?
No. Using StarEdit's trigger dialog is the only way to create triggers.

How do I get doors to open?
You must use the SET DOODAD STATE action to open or close doors. A typical door opening trigger reads:

PLAYERS: All players
CONDITION: Current player brings 1 or more men to 'Door Location'
ACTION: Disable doodad state for Upper Left Upper Level Door for All players at 'Door Location'

Set: Select the action you want to do to the door.

Enable - Closes the door.
Disable - Opens the door.
Toggle - Changes the state of the door; closes it if it's open; opens it if it's closed.

Units: First, select "Neutral Units". Then select "Doodads". Among the list of doodads will be the following types of doors:

Left upper level door - A door in "Wall" tiles running from lower left to upper right.
Right upper level door - A door in "Wall" tiles running from lower right to upper left.
Left pit door - A door in "Substructure Wall" tiles running from lower left to upper right.
Right pit door - A door in "Substructure Wall" tiles running from lower right to upper left.

Player: This must be set to "All players". Unlike turret doodads, doors cannot be owned by a specific player. Unless this is set to "All players" the SET DOODAD STATE action will have no effect.

Location: StarCraft will arbitrarily select one door (of the type indicated in "units") in the location. Only that door will be affected by the action.

First, you should be aware that traps have two states: enabled and disabled. Disabled traps will not attack.

• You can double-click on the trap to toggle its state. In the Campaign Editor, enabled traps are readily visible but disabled traps look like normal wall or floor tiles. You can drag-select while in the doodad layer to find any disabled traps in an area.
• Like doors, traps can be enabled or disabled using the "SET DOODAD STATE" action. See the answer on opening doors above for details on using this action.

• Human-controlled traps will not attack allies of the human player.
• Rescue traps will not attack but can be rescued by human-controlled units (after which they act like human controlled traps).
• Neutral traps will not attack anyone.
• If a side defeats, its units and traps become neutral, i.e., they will not attack. Since traps do not count as units and the default triggers in an installation map include Condition: "If current player controls 0 or fewer men" Action: "End scenario in defeat for current player", traps placed for a side with a start location but no units will become neutral.
• Players without start locations act like computer-controlled players but (1) do not ally with other computer players and (2) do not run any triggers.

Why can't I create doodads from triggers?
Doodads are part of the actual map terrain, not real units or buildings and can't be changed during the game.

How exactly does the Give Units to player trigger work?
The trigger action changes the owner and color of the units affected from the one player to another. It also gives you control of any units inside a transport that changes players. The only special thing that happens when units are given is that the player who gains the units via trigger also receives any special upgrades that the units possessed. This does not include weapon or armor upgrades such as those purchased at a Protoss Forge, but pretty much any other Upgrades or Special Abilities such as a Templar's Psionic Storm ability or the Zergling's Adrenal Gland upgrade are received by the new owner.

Example: If player 1 is given an Overlord of player 2 and player 2 has researched the Ventral Sacs upgrade and Burrowing, then player 1 will receive the Ventral Sacs since it affects the given unit, but not burrowing since overlords cannot burrow. All of his Overlords will now be able to transport units across the battlefield.

Note: The Dark Archon Mind Control ability works in an analogous way to the Give Units action.

What good is the Set Deaths action?
You can set the deaths for a player to 0. This allows you to use the Deaths condition to have something happen each time a unit died. Before the Set Deaths action was available the Deaths trigger was not easily usable since the death count could never be reset. Now that the Deaths variable may be set you can build a trigger that creates a new zergling each time one dies, or something in a similar vein.

Example :

Condition:  -Current Player suffers 1 Zergling Death
Action:      -Create 1 Zergling at location foo for current player
                -Modify Death Counts for current player
                       Set to 0 for Zergling

Why do extra units appear when I try to make units appear for a player?
If you create a trigger that applies to multiple players, then that trigger will fire off once for each player as long as the condition is met for each player.

Example 1 (How not to do it)
                Players: 1,2,3,4
                Condition: Player 1 brings 1 civilian to location foo
                Action: Create 3 Zerglings for Player 1

This trigger will create 12 zerglings for player 1 since the trigger attempts to fire for each of the four listed players. Thus player one checks the trigger and indeed the condition is met and it creates 3 zerglings. Player two checks the trigger and the condition is met and it also create three zerglings....etc for players three and four. The way to make a trigger only fire once in a situation like this is to make the condition and action use the current player rather than a specific player.

Example 2 (Working example)
                Players: 1,2,3,4
                Condition: Current Player brings 1 civilian to location foo
                Action: Create 3 Zerglings for Current Player

This would allow players 1,2,3,4 to bring a civilian to the location to create three zerglings. It will only fire once for any given player since if one player brings a civilian to the location, the condition will still be false for the other three players. If the problem is just in creating units for several players at once, use the current player tag rather than a specific player tag. Try using create 3 zerglings for current player rather than create 3 zerglings for player 1.

How does the "Set Alliance Status" action work? Can I use it on a human player?
The Set Alliance Status action allows any player to become an ally or an enemy of any other player. Any time you use this trigger you need to remember to set the alliance status of both the players you want to ally (or become enemies). Also the trigger can only make changes to the alliance status of the current player. If you want players one and three to become allies then you should have player one run a trigger that allies him to player three and player three also set player one to an ally.

You can use this trigger to make any combination of humans or computers become allies or enemies with each other. You can make a map where humans and computers are allied, where computers battle each other, or where two humans switch alliance status with each other mid game.

You should use these new trigger actions instead of the "Set player to ally" and "Set player to enemy" AI scripts that were commonly used before and are now obsolete.

How does the "Preserve Trigger" action affect a trigger?
If a trigger does not have a "Preserve Trigger" action attached to it the trigger will fire only once when its conditions are met and then never fire again. A preserve trigger action will cause that trigger to execute every time the trigger's conditions are met regardless of whether the trigger has already fired off one time, or a hundred times. The preserve trigger action is what is used to create the popular "madness" maps. These maps have an action that creates a unit type at a specific location and then a preserve trigger action so that the unit gets created over and over every two seconds when a trigger pass is made.