Staredit Network Wiki - User contributions [en]

Regeneration

2025-01-23T02:04:46Z

Zurg: Rewrote the terrain repair section to be a lot clearer. Minor changes elsewhere in light of that.

In [[StarCraft]], regeneration is the slow increase of a unit's health, shields, or energy.

===How It Works===
To understand regeneration, you have to understand that Starcraft hides data from you. Health and Shields each are stored in memory in 4 bytes, however Starcraft only tells you the last 3 bytes. The first byte is actually a hidden value which acts as a timer for regeneration. 1 byte = 8 bits, or 2<sup>8</sup> = 256.

Each frame, a certain regeneration amount is added (or subtracted) to the first byte, according to values in the mpqs:

*Protoss Shields: 7
*Zerg Health: 4
*Energy: 8
*Shield Battery: 1280
*Recharge Shields: -640 (-632 net)
*Burning Terran Building: -20
*Medic: 200
*Personnel Cloaking(Ghost): -18 (-10 net)
*Cloaking Field(Wraith): -21 (-13 net)
*Heal: -100 (-92 net)
<br />
<u>For repair:</u><br />
SCVs repair units and buildings in a similar way, based on build time and total HP. Multiple SCVs increase the repair rate by adding them together.<br />
<br />
'''R''' = roundup(0.9 * <u>H</u>/<u>B</u>)<br />
where '''R''' = repair rate in <u>hp</u> per <u>frame</u> (of animation), with:<br />
<u>H</u> = health of the unit<br />
<u>B</u> = build time of the unit in SCMDraft (which is counted as ''frames of animation'')<br />
<br />
<br />
''Further'', '''R2''' = 256*'''R''', and '''R2''' is the value that gets added or subtracted each frame to the first byte of a unit's HP. <br />
One important note is that '''R2''' is a 2 byte value, which means that when '''R2''' > 65535, it loops back over to 0. Here is an example:<br />
<br />
A Terran Barracks with a <u>build time of 1 frame</u>, <u>HP of 9999</u>.<br />
'''R2''' = 256 * roundup(0.9 * <u>9999</u>/<u>1</u>) = 2303770. R2 > 65535, so it rolls over in multiples of 65535.<br />
'''R2''' = 2303770 - k65535, '''R2''' = 10010. Note that this is still fairly large, and means that each SCV will repair approximately <u>39 HP every frame</u>.<br />
<br />
A slightly more realistic value is that of the default battlecruiser with <u>500 HP</u>, <u>2000 frames build time</u>:<br />
'''R2''' = 256 * roundup(0.9 * <u>500</u>/<u>2000</u>) = 58.<br />
'''R''' = '''R2'''/256 = <u>0.2266 hp per frame of animation</u><br />
0.2266 hp per frame * 24 frames of animation per real-time second = <u>5.44 hp per real-time second</u>.<br />
<br />
<u>Building units, following from repair:</u><br />
Building units follows the same formula, and this explains why some buildings/units come out injured, except they start out with 10% of the base HP, plus 1 frame of "repairing", plus the time it takes to build. In the case of the terran barracks, it will build in 1 frame and come out with .1 * 9999 + 10010/256 + 10010/256 = 1078.1 HP.<br />

===Calculation of healing rates===
''The time used here is realtime.''
Since Starcraft is normally played on fastest, or 42ms/frame, we can calculate the approximate rates of healing:
*Let sp = shield points, hp = hit points, f = frames, ms = milliseconds, s = seconds, p = fraction of points
*Protoss shields use 7, (256p/sp / 7p/f) / (1000ms/s / 42ms/f) = 1.536 seconds per shield point.
*Zerg Health use 4, so (256/4)/(1000/42) = 2.688 seconds per health point.
*Medics' Healing uses 200, so (256/200)/(1000/42) = 0.05376 seconds per health point or ~18.6 health per second.
*Shield batteries use 1280, so 256/1280/24 = 0.0084 seconds per shield point or ~119 shields per second.

Other rates can be similarly calculated.
[[Category:StarCraft]]
[[Category:Reference]]

Command Condition Bug

2024-10-27T21:42:35Z

Zurg: I am not sure. Someone should verify.

''' I am not 100% certain WHEN this bug occurs, and this page should be verified at some point in the future (eg me when I have time) '''

There is a bug that appears under certain circumstances, when the '''Give Unit''' action and the '''Command''' condition are used together. This ''only'' occurs when Give Unit and Command are used in the same trigger cycle; specifically, if Command is checking a value that was altered by Give Unit earlier on. So, if Give Unit was used AND THEN Command was used later on in the same trigger cycle.

The issue is that the value that Command is checking is the number of units owned at the BEGINNING of the trigger cycle. It is at the beginning of the trigger cycle because this number does not change or get updated when using the Give Unit action until the trigger cycle has finished. This is a bug in StarCraft's coding. You can use Bring condition (with "Anywhere" being the location) to get around this issue. You can also trigger in a 1 cycle delay before checking with Command.

==See also==
*[[Bring Condition Bug]]

[[Category:StarCraft]]
[[Category:Reference]]

Command Condition Bug

2024-08-26T02:15:36Z

Zurg: Created page with "There is a bug that appears under certain circumstances, when the '''Give Unit''' action and the '''Command''' condition are used together. This ''only'' occurs when Give Unit..."

There is a bug that appears under certain circumstances, when the '''Give Unit''' action and the '''Command''' condition are used together. This ''only'' occurs when Give Unit and Command are used in the same trigger cycle; specifically, if Command is checking a value that was altered by Give Unit earlier on. So, if Give Unit was used AND THEN Command was used later on in the same trigger cycle.

The issue is that the value that Command is checking is the number of units owned at the BEGINNING of the trigger cycle. It is at the beginning of the trigger cycle because this number does not change or get updated when using the Give Unit action until the trigger cycle has finished. This is a bug in StarCraft's coding. You can use Bring condition (with "Anywhere" being the location) to get around this issue. You can also trigger in a 1 cycle delay before checking with Command.

==See also==
*[[Bring Condition Bug]]

[[Category:StarCraft]]
[[Category:Reference]]

Quirks and nuances

2019-11-24T23:27:01Z

Zurg: /* Trigger Quirks */ added bullet about waits being measured independently of game speed setting

When making maps for StarCraft, map makers often encounter a number of oddities and esoteric details that can lead to confusion. This document exists in an attempt to list these quirks and nuances.

== Unit Quirks ==
These quirks affect types of [[units]], and specific units.
*[[Hallucinations]] cannot be detected in [[trigger]] conditions. However, the Move Location trigger can still always move a location onto the leftmost specific unit even though the leftmost one is a hallucination.
*The Give Unit and Modify Unit Energy trigger actions do not affect Hallucinations.
*If the owner of a Hallucination shares [[vision]] with another player, that other player will still not see any (visual) indication that the units are Hallucinations. (They won't be tinted blue.)
*[[Map Revealers]] cannot exist in a [[location]]. Though they can be created at a location, location-based trigger conditions (like [[Bring]]) and actions (like Remove Unit At Location) do not detect or affect Map Revealers.
*[[Zerg Broodling]]s created using Create Unit do not expire, unless they are later affected by a Modify Unit Hit Points action. Broodlings spawned using Create Unit With Properties ''do'' expire.
*Several [[Hero]] units have unusual properties. All hero [[Terran Ghost|Ghosts]] have attack ranges of 6 instead of 7. [[Unclean One]] has a larger hitbox than normal [[Zerg Defilers|Defilers]]. [[Aldaris]] and [[Tassadar]] share attacks, so changing the values for one will affect the other. [[Jim Raynor (Vulture)]] has a 50% faster attack rate.
*[[Players#Computer players|Computer]]-controlled heroes will never stop following an enemy unit until they acquire another target or are forced to stop (using triggers). Computer-controlled heroes never cast [[spells]]. Computers never cast single-target offensive spells on hero units, but they do use defensive spells, like [[Defensive Matrix]], on their own heroes.
*[[Cocoon]]s, [[Nuclear Missile]]s, [[Zerg Egg]]s, and [[Zerg Lurker Egg]]s will not register as "[men]" or "[any unit]" in the Bring condition. The Nuclear Missile will register as a Nuclear Missile in conditions, the Zerg Egg will register as a Zerg Egg, and Cocoons will register as Cocoons, but the Lurker Egg will not register as a Lurker Egg.
*Pre-placed Zerg Eggs, Zerg Lurker Eggs, and Cocoons will never finish morphing and cannot be canceled.
*Extra units available in [[SCMDraft 2]] (any units not available in the original [[StarEdit]] Campaign Editor) cannot be created by triggers. This includes everything from extended heroes (like [[Raszagal]] and [[Arcturus Mengsk]]) to [[doodad]] units to extra [[powerups]], like [[Mineral Chunk]]s.
*Units owned by [[Players#Extended players|extended players]] cannot attack, because those players do not have vision of their own units. [[Vulture Spider Mine]]s are exceptions, however, since they attack based on proximity rather than vision.
*A [[Terran Vulture]]'s Spider Mine count cannot be altered using the Modify Unit Hangar Count trigger action.
*Some units, such as the [[Protoss Zealot]] and [[Protoss Dark Templar]], have off-center collision boxes. Because of this, one must use smaller [[Locations#Inverted locations|inverted locations]] when working with these units.
*[[Dark Swarm]]s and [[Disruption Web]]s are owned by [[Players#Neutral|Neutral]], not by the player that cast them.
*When moving a powerup using triggers, ''StarCraft'' will not check for other ground units at the target location. This means that the powerup may be moved directly over a unit, causing [[stacking]]. Stacked units, however, will continually move in an attempt to find a clear spot.
*Units affected by spells that reveal them (such as [[Plague]] and [[Ensnare]]) will remain revealed even after [[burrow]]ing until the effects wear out. Ensnare and Plague will not reach burrowed units when cast, however.
*Pre-placed [[Set Doodad State|disabled]] [[Units#Unit sprites|unit sprites]] have no collision box. Other units can walk over them, but they cannot walk over other units. Disabled powerup unit sprites therefore do not displace units they are moved onto.
*[[Zerg Lurker]]s only attack while burrowed, and computer players will only burrow a Lurker when it is idle or automatically responding to the presence of enemy units. If the Order trigger action is used on a Lurker (regardless of whether the order is a Move, Attack, or Patrol order), the Lurker will un-burrow and move to the destination, ignoring any enemies it encounters on the way. It will not burrow again until it reaches its destination or has its orders removed by some other means. (This differs from other units' behaviors; other units will attack while moving or upon reaching their destination if Attack or Patrol orders are given.)
*[[Protoss Scarab|Scarabs]] can be detected with the Bring condition while they are inside of a [[Protoss Reaver|Reaver]], as can the [[Protoss Interceptor|Interceptors]] inside of [[Protoss Carrier|Carriers]]. Because of this, a location smaller than a Reaver that is centered on a Reaver can detect when the Reaver fires a Scarab. This knowledge is implemented in [[Direct Damage System]]s.
**Similarly, the units in a [[Terran Bunker]] can be detected by checking a location centered on the Bunker, a stored Nuclear Missile can be detected by checking a location on its [[Terran Nuclear Silo|Nuclear Silo]], and the units in a transport ([[Terran Dropship|Dropship]]/[[Protoss Shuttle|Shuttle]]/[[Zerg Overlord|Overlord]]) can be detected by checking an air-only location centered on the transport.
*Scarabs cannot be given to players using triggers. Giving a Reaver will give all of its active Scarabs, however.
*Terran Add-ons cannot be given normally. You must instead give the building they are attached to; the Add-on will also be given.
*Give units to other player who had those upgrades or abilities then re-give units to the original player, to make units gain those upgrades or abilities, such as, using it on Hydralisks then all your Hydralisks suddenly gain Lurker Aspect; Using it on Dark Archons then all your Dark Archons suddenly gain Maelstrom or Mind Control. Using it on a Hero Vulture Jim Raynor to let him gain Ion Thrusters. Other Heroes however had already had their own upgrades and special abilities.
*Powerups will not be detected as "[any unit]" in conditions; instead, you must check for the powerup directly. Powerups do count as "[any unit]" in actions, however.
*Incomplete buildings cannot be detected in any conditions that use the "at least" or "exactly" modifiers, but they can be counted using the "at most" modifier; unfortunately this is generally not very useful. Incomplete buildings will be considered for actions. Incomplete [[Zerg]] buildings morphing to higher forms, such as a [[Zerg Spire]] morphing into a [[Zerg Greater Spire|Greater Spire]], will be treated as the pre-morph building for all trigger conditions and actions.
*Unit doodads, such as wall and floor traps, cannot be moved using the Move Unit action. They can only be moved by an [[Protoss Arbiter|Arbiter]]'s [[Recall]] spell. Presumably, this is to prevent the "Move [any unit] at location" action from giving undesirable results in Installation maps created using StarEdit.
*Flag Beacons have a single-use "[[Place COP]]" action that will teleport the beacon to any buildable location on the map. Five minutes after the game starts, a [[flag]] will be created on top of the beacon and the "Place COP" action will be removed. If the flag is moved off the beacon by a worker and then dropped, it will return to its Flag Beacon (after 5 minutes?). This is an important consideration if you have a narrow area/maze in your map; if players have access to flag beacons they can grief other players by moving flags around the map and potentially creating immovable obstacles. Disabling doodad state on the flag beacon will cause the beacon to play the Terran power-down noise when selected by the user and remove the "Place COP" action, although the button for it will be briefly visible.
*Terran buildings that are created or pre-placed as "[[Lift Off|lifted]]" will move about a third faster than those than began their life on the ground. Once any building has been landed and lifted, it will have the regular building movement speed.
*CPU players have an additional aggression response to attacks from Protoss Interceptors; they will send all idle units in the general area (and it really is quite general) to counter-attack.

==Powerup Quirks==
*In conditions, you must detect powerups using the specific unit, [Any Unit] and [Men] do not work.
*In actions, [Any Unit] does work, as well as the specific unit.
*For the Commands condition, powerups are registered as belonging to the naturally owning player, as expected.
*For the Bring condition, powerups are registered as belonging to the naturally owning player when they are on the ground.
*When a powerup is picked up by the worker of a player, Bring conditions will register the powerup as being owned by the worker's player, and not the natural powerup owner.
*The exception to this is the Flag powerup, which is always registered as being owned by the natural powerup owner.
*The "At most" modifier will not detect powerups being held by workers, registering them as 0 powerups.
*The "Exactly" and "At least" modifiers work as expected.
*Even when picked up by a worker, powerups continue to be registered as belonging to the naturally owning player in all actions.
*You cannot Give or Move powerups when they are held by a worker. Giving the holding worker does not transfer ownership of the held powerup (eg, it does not work the same as building add-ons).
*The only way to Give powerups is when they are lying on the ground.
*Powerups can be Removed or Killed while being held by worker but will not show any death explosion.
*When a worker holding a powerup dies, the powerup will be dropped at the place where the worker was, unless the area is unplaceable (eg on top of a beacon), in which case the powerup will be teleported back to the location it was originally created on the map (as distinct from where the worker picked it up from).
*Powerups can be Moved on top of any other regular ground unit (not other powerups), which will cause that unit to momentarily become stacked and attempt to find a new clear space of ground to occupy.

== Trigger Quirks ==
These quirks affect triggers and general game mechanics.
*''StarCraft'' trigger actions affect units in order from left to right across a specified location. "Ties" are broken by whichever unit most recently occupied the tied x-coordinate. If none of the tied units have ever moved (such as ties between two pre-placed buildings), the unit with the greater index number (viewable in SCMDraft 2 unit properties window) is affected first.
*In conditions and actions, "Allies" applies only to players that the trigger owner has [[Allied Victory]] with. A player can only have Allied Victory with all or none of his allies. Setting a player to "Ally" will ally that player and turn Allied Victory off; setting a player to "Allied Victory" will ally that player and turn Allied Victory on for the trigger owner.
*Triggers run top to bottom from Player 1 to Player 8. Setting a trigger to run for a [[Force]] or All Players is the same as selecting all players in that force.
*When a player leaves the game, their units are given to Player 12 (Neutral). Any alliances that remaining players had with the departed player will remain intact toward those Player 12 units. Changing a player's alliance status with the departed player will likewise affect that player's alliance with those units.
*Center View acts as a [[Wait]] in single-player mode until the screen has fully centered on the target location. It also centers the mouse cursor, disbanding any selection rectangles in the process.
*When units die, there is one frame of animation where they are at 0 health and are designated to die. For that frame, they are technically still alive, they still have a collision box, they can still be detected with Bring (though not with Command), and they can even be given (but cannot be moved). They will have already added a death to their [[death counter]]. When you kill a unit with triggers, they are set to that zero-health "dead-but-not-dead" state. Since [[hyper triggers]] (on [[Game speed|Fastest]]) run every other frame, there is essentially a 50% chance that a unit killed by something other than a trigger will be in that state when the triggers run. The Kill Unit action isn't so much a Kill Unit action as it is a "sentence to death" action.
*You cannot give units to a "group", such as Force 1, All Players, or Foes. However, units can be given from or created for groups.
*Deaths for extended players' units (and for Neutral units) can be read in conditions but cannot be altered with the Set Deaths action. They will accurately represent the deaths their units have amassed.
*Units cannot be created for Players 9-12. You must instead create the units for a normal player, and give the units to P9-12 as a separate action.
*Units given to Players 9-12 will retain the color of their previous owner, though they will use the P9-12 colors on the mini-map.
*If the player the units given to P9-12 belonged to is set as enemy, human-controlled units will automatically attack it.
*When a player who belongs to a group, like Force 1, is not present in the game, any units created via triggers for Force 1 or given to that player will still be owned by that phantom player. Unusually however, the "remove unit" action when applied to the player's group will *not* remove the phantom player's units; instead you must use specifically remove units for that individual player.
*When a Move Location action runs, if there are no applicable units for the moving location to center on, then the location will center in the center of the location that was supposed to contain these units. Because Map Revealers cannot be detected inside of locations, they are good units to use for centering one location on another.
*"Highest Score" applies to all players that have tied for the highest score (same for lowest).
*Using Move Unit to move a unit to an ''implacable'' location will cause the unit to halt its current action. Implacable locations for ground units include impassable [[terrain]] and areas crowded with other ground units. Air units can be halted by moving them to a crowded location, such as a patch of lifted Terran buildings. The most fool-proof way is to create a location in the map editor, modify its coordinates so that it is positioned outside of the map, and then move units to it in-game. Units that are constantly moved to an implacable area (when hyper triggers are active) cannot be targeted (an attacker's hits won't land, except for splash damage, and the unit cannot be repaired) but will be able to shoot others. Scarabs moved to implacable locations will immediately detonate at their present location, a trick used in Direct Damage Systems.
*Giving a unit to another player and back to the original player will cancel any orders that that unit was carrying out. Players will also lose selection on the unit. Buildings under construction will be canceled and refunded, as will upgrades in progress.
*Ordering units to Move to a location through the Order action will result in them only attacking units that prohibit them from reaching their destination. Ordering them to Patrol will cause the applicable units to attack all enemy units along the way and carry out the patrolling back and forth as expected. Attack orders will retaliate to units that engage them but won't "start a fight" unless directly blocked, as in the case of the Move order.
*Moving a unit with the Move Unit action will cause it to enact its next waypoint order (orders given with the Shift key to be carried out sequentially) if it has one. Ordering a unit with the Order action will cancel all current and waypoint orders.
*Banning a player in the game lobby while their download is at the 99th percentile (and sometimes less) will still give them the map.
*Waits appear to be measured in real-time seconds, or a close approximant thereof. Changing game speed does not alter the amount of real-life time waited. (So, setting a 2000ms wait will always result in approximately 2 seconds worth of real-life time being waited, regardless of if you have game speed set to slowest or fastest. If on fastest, this would be about 3 seconds' worth of game time).

==Map Editor Quirks (SCMDraft 2 unless otherwise noted)==
*Locations appear to be one pixel shorter on the bottom and right sides. This applies to inverted locations as well. For clarification, I do not mean the edges labeled "Bottom" and "Right", but rather whichever bar is on the bottom and right; It could be "Top" and "Left" (if it were inverted).
*The AI script "Turn OFF/ON shared vision" is a little counter-intuitive as well. If, for example, Player 1 turns ON shared vision for Player 2, then they will gain vision of Player 2's units. Turning off shared vision of Player 2 will cause them to lose that vision. (In recent versions of SCMDraft 2, the AI script has been renamed "Turn ON/OFF Shared Vision of Player X for Current Player" to more accurately reflect this.)
*Neutral is Player 12. All Players refers to Players 1 through 12 (though Players 9 through 12 cannot run triggers). Neutral Players includes Players 9 through 11.
*In some versions, inverted locations shown on the map cannot be clicked on. To edit an inverted location once it is created, you must select it from the location list on the left and press enter.

[[Category:StarCraft]]
[[Category:Reference]]

List of Trigger Actions

2019-11-24T23:08:55Z

Zurg: appended info about the delay between individual actions + linked to article/section on trigger cycles

Actions are (obviously) what a trigger does once the conditions are met.

Once again, I’ll be going through all of them, so if you’re looking for a specific action, use Ctrl + F.
*'''CENTER VIEW:''' Centers the selected player’s on a specified location.

*'''COMMENT:''' Gives the trigger a label so, when viewing the trigger in the main trigger window, it doesn’t display the actual trigger information, but instead the comment. Useful for quick reference when searching through a massive list of triggers for a certain one.

*'''CREATE UNITS:''' Creates an exact number of units at a location for the specified player.

*'''CREATE UNITS WITH PROPERTIES:''' The same as CREATE UNITS, but you can change the units that come out a little. You can make them cloaked (if they can have the Cloak ability), invincible, burrowed (if they can have the Burrow ability), hallucinated (as in the High Templar ability), or In-Transit (if they are buildings with the Lift-Off ability, i.e. Barracks, Factory). You can also change the percentage of remaining hit points, shields and energy. If you create a mineral field or vespene geyser, you can change the amount of minerals or gas in it by changing the number in the ‘Resources’ field. If you create a carrier or reaver, you can change the number of interceptors or scarabs (respectively) it spawns with by changing the number in the ‘In Hangar’ field. In Hanger doesn't work on Vulture spider mines.

*'''DEFEAT:''' Exactly what it sounds like, it makes the current player lose.

*'''DISPLAY TEXT MESSAGE:''' Causes the player to see a message on the left side of the screen, as they would in chat. NOTE: Remember to have the ‘Always display’ box checked.

*'''DRAW:''' The game ends in a tie for everyone.

*'''GIVE UNITS TO PLAYER:''' Gives an exact number of units owned by a specified player at a location to another specified player. (Ex.: Give 2 Terran Marine owned by player 1 at 'location 0' to player 2. This takes player 1’s two marines and makes them belong to player 2.) NOTE: The ‘All units’ checkbox starts out checked. Uncheck it to change the number of units that are given.

*'''KILL UNIT:''' Kills every unit of a certain type owned by the specified player, no matter where they are, or their properties. Yes, this even kills invincible units.

*'''KILL UNITS AT LOCATION:''' Kills an exact number of units owned by a player at a specified location. Like KILL UNIT, but with a sniper rifle.

*'''LEADER BOARD:''' There’s a lot of different types of leader board, but they all do the same thing, they show little colored boxes in the top left corner and a number, and that number is whatever it’s tracking. With a leader board, you can track:
**Units of a type owned at a location (CONTROL AT LOCATION)
**Units of a type owned (CONTROL)
**Minerals and gas (GREED)
**Kills of a unit type (KILLS)
**Points (POINTS)
**Minerals OR gas (RESOURCES)
Also, a leader board with a set goal can be made using LEADER BOARD GOAL. This is especially useful when you want the leader to be the one with the lowest number. To do that, set the goal as something low, like zero.

*'''LEADERBOARD COMPUTER PLAYERS:''' Changes whether or not computer players are shown on the leader board.

*'''MINIMAP PING:''' Makes a ping on the minimap (those little lines that form a square around something) at a location for the selected player.

*'''MODIFY UNIT:''' This action modifies the same numbers you can change if you use CREATE UNITS WITH PROPERTIES. These are hit points, energy, shields, hangar count, and resources. NOTE: CREATE UNIT WITH PROPERTIES is for making modified units, while MODIFY UNIT is for changing existing ones.

*'''CENTER LOCATION:''' This moves a location to a specific unit owned by the selected player. (Ex. Center location labeled 'location 0' on Jim Raynor (Marine) owned by player 1 at 'Anywhere'. This will move center Location 0 on player 1’s Jim Raynor.) NOTE: This doesn’t work very well if a player owns more than one of the type of unit you’re trying to center the location on. It can work, but you have to make sure that another unit of the same type of the one that you want to track NEVER enters the tracking location, or it might get mixed up and start tracking the wrong unit.

*'''MOVE UNITS:''' This teleports units owned by the selected player from one location to another.

*'''MUTE UNIT SPEECH:''' This silences all the sound except for .wavs you might be playing using PLAY WAV.

*'''ORDER:''' Tells all units of a type at a location belonging to the specified player to do something (move, patrol, or attack) to another location. (Ex. Issue order to all Terran Marine owned by player 1 at 'Location 0': Attack to 'Location 1'. All of player 1’s marines at location 0 will attack to location 1.)

*'''PAUSE GAME:''' Pauses the game for everyone.

*'''PAUSE TIMER:''' Pauses the countdown timer for everyone.

*'''PLAY WAV:''' Plays a selected .wav file for the selected player. A .wav file is a low-quality, old sound file that was popular when Starcraft came out. Before you can play a .wav in a map, you have to import it using Scenario > Sounds, or Ctrl + Shift + S. NOTE: Having just a few .wav files can really jack up your file size, therefore making the download longer. People don’t typically like long downloads, so be careful what you use!

*'''PRESERVE TRIGGER:''' Makes the trigger fire whenever the conditions are fulfilled. Be careful with these and always put a WAIT before them unless you want a constantly running trigger (which will really lag things down).

*'''REMOVE UNIT:''' Removes all of a player’s units of a certain type without killing them; more or less makes them disappear forever. Good if you need to get rid of a unit, but you have a trigger that will go off if you kill it.

*'''REMOVE UNITS AT LOCATION:''' Just like KILL UNITS AT LOCATION, but removing instead of killing.

*'''RUN AI SCRIPT:''' This is basically useless with just StarEdit. Ignore it.

*'''RUN AI SCRIPT AT LOCATION:''' This, however, is very useful. Enter Bunker and Enter Transport are fairly self-explanatory. Using the scripts labeled with a race and difficulty level at a location over a computer player’s base will make them use their units and buildings as if they were playing a melee. Using ‘Value this area higher’ will give a location priority to attack and keep. NOTE: If you're running an AI script at a CPU base to make it play like it's in a melee, make sure you match up the race with the race of the CPU (i.e. Zerg scripts won't work with a Terran player).

*'''SET:''' There are a lot of things that can be set using triggers. They are:
**Allying and Allied Victory (ALLIANCE STATUS)
**The amount of time on the countdown timer (COUNTDOWN TIMER)
**The death count of a unit for a player (DEATHS)
**Doodad state (DOODAD STATE)
**Invincibility of units at a location (INVINCIBILITY)
**Mission objectives, accessed through the main menu (MISSION OBJECTIVES)
**A map to start after the current one is completed, for if you’re making a custom campaign (NEXT SCENARIO)
**Amount of minerals or gas (RESOURCES)
**Amount of points of a type (POINTS)
**Switch status, set or cleared (SWITCH)

*'''TALKING PORTRAIT:''' This shows a portrait of a unit of your choice doing it’s talking animation for the amount of time you set. This is what was used in the campaigns’ in-game cutscenes.

*'''TRANSMISSION:''' This simply combines TALKING PORTRAIT, PLAY WAV, and DISPLAY TEXT MESSAGE into one.

*'''UNMUTE UNIT SPEECH:''' Undoes the MUTE UNIT SPEECH action

*'''UNPAUSE GAME:''' Undoes the PAUSE GAME action.

*'''UNPAUSE TIMER:''' Undoes the PAUSE TIMER action.

*'''VICTORY:''' The opposite of DEFEAT, makes the current player win.

*'''WAIT:''' Stops the trigger from carrying on to the next action for the amount of time set. <br/>''Note regarding:'' The time for this action seems to be measured in a close approximant to real-life time. Altering the game speed does not alter the actual real-life time waited by the trigger. Note also that there are caveats with [[wait blocks|wait blocking]], which is when a player has two or more triggers that both use waits, and they are both run at the same time.

====A NOTE ON ACTIONS:====
Actions always fire in the order that you put them into a trigger, they don't all go off at once, so don't put a "Kill Units at Location" before a "Create Units" and expect the units you made to die. Also, the delay between the actions will be minimal unless you put in a Wait (the delay is always less than 1 frame of animation; see [[triggers#trigger cycles|trigger cycles]] ).

==See also==
*[[Triggers]]
**[[Triggers#Actions|Actions]]
*[[List of Trigger Conditions]]

[[Category:StarCraft]]
[[Category:Reference]]

List of Trigger Actions

2019-11-24T21:33:03Z

Zurg: updating the Wait action; the action uses real-time seconds, and is independent of game speed setting

Actions are (obviously) what a trigger does once the conditions are met.

Once again, I’ll be going through all of them, so if you’re looking for a specific action, use Ctrl + F.
*'''CENTER VIEW:''' Centers the selected player’s on a specified location.

*'''COMMENT:''' Gives the trigger a label so, when viewing the trigger in the main trigger window, it doesn’t display the actual trigger information, but instead the comment. Useful for quick reference when searching through a massive list of triggers for a certain one.

*'''CREATE UNITS:''' Creates an exact number of units at a location for the specified player.

*'''CREATE UNITS WITH PROPERTIES:''' The same as CREATE UNITS, but you can change the units that come out a little. You can make them cloaked (if they can have the Cloak ability), invincible, burrowed (if they can have the Burrow ability), hallucinated (as in the High Templar ability), or In-Transit (if they are buildings with the Lift-Off ability, i.e. Barracks, Factory). You can also change the percentage of remaining hit points, shields and energy. If you create a mineral field or vespene geyser, you can change the amount of minerals or gas in it by changing the number in the ‘Resources’ field. If you create a carrier or reaver, you can change the number of interceptors or scarabs (respectively) it spawns with by changing the number in the ‘In Hangar’ field. In Hanger doesn't work on Vulture spider mines.

*'''DEFEAT:''' Exactly what it sounds like, it makes the current player lose.

*'''DISPLAY TEXT MESSAGE:''' Causes the player to see a message on the left side of the screen, as they would in chat. NOTE: Remember to have the ‘Always display’ box checked.

*'''DRAW:''' The game ends in a tie for everyone.

*'''GIVE UNITS TO PLAYER:''' Gives an exact number of units owned by a specified player at a location to another specified player. (Ex.: Give 2 Terran Marine owned by player 1 at 'location 0' to player 2. This takes player 1’s two marines and makes them belong to player 2.) NOTE: The ‘All units’ checkbox starts out checked. Uncheck it to change the number of units that are given.

*'''KILL UNIT:''' Kills every unit of a certain type owned by the specified player, no matter where they are, or their properties. Yes, this even kills invincible units.

*'''KILL UNITS AT LOCATION:''' Kills an exact number of units owned by a player at a specified location. Like KILL UNIT, but with a sniper rifle.

*'''LEADER BOARD:''' There’s a lot of different types of leader board, but they all do the same thing, they show little colored boxes in the top left corner and a number, and that number is whatever it’s tracking. With a leader board, you can track:
**Units of a type owned at a location (CONTROL AT LOCATION)
**Units of a type owned (CONTROL)
**Minerals and gas (GREED)
**Kills of a unit type (KILLS)
**Points (POINTS)
**Minerals OR gas (RESOURCES)
Also, a leader board with a set goal can be made using LEADER BOARD GOAL. This is especially useful when you want the leader to be the one with the lowest number. To do that, set the goal as something low, like zero.

*'''LEADERBOARD COMPUTER PLAYERS:''' Changes whether or not computer players are shown on the leader board.

*'''MINIMAP PING:''' Makes a ping on the minimap (those little lines that form a square around something) at a location for the selected player.

*'''MODIFY UNIT:''' This action modifies the same numbers you can change if you use CREATE UNITS WITH PROPERTIES. These are hit points, energy, shields, hangar count, and resources. NOTE: CREATE UNIT WITH PROPERTIES is for making modified units, while MODIFY UNIT is for changing existing ones.

*'''CENTER LOCATION:''' This moves a location to a specific unit owned by the selected player. (Ex. Center location labeled 'location 0' on Jim Raynor (Marine) owned by player 1 at 'Anywhere'. This will move center Location 0 on player 1’s Jim Raynor.) NOTE: This doesn’t work very well if a player owns more than one of the type of unit you’re trying to center the location on. It can work, but you have to make sure that another unit of the same type of the one that you want to track NEVER enters the tracking location, or it might get mixed up and start tracking the wrong unit.

*'''MOVE UNITS:''' This teleports units owned by the selected player from one location to another.

*'''MUTE UNIT SPEECH:''' This silences all the sound except for .wavs you might be playing using PLAY WAV.

*'''ORDER:''' Tells all units of a type at a location belonging to the specified player to do something (move, patrol, or attack) to another location. (Ex. Issue order to all Terran Marine owned by player 1 at 'Location 0': Attack to 'Location 1'. All of player 1’s marines at location 0 will attack to location 1.)

*'''PAUSE GAME:''' Pauses the game for everyone.

*'''PAUSE TIMER:''' Pauses the countdown timer for everyone.

*'''PLAY WAV:''' Plays a selected .wav file for the selected player. A .wav file is a low-quality, old sound file that was popular when Starcraft came out. Before you can play a .wav in a map, you have to import it using Scenario > Sounds, or Ctrl + Shift + S. NOTE: Having just a few .wav files can really jack up your file size, therefore making the download longer. People don’t typically like long downloads, so be careful what you use!

*'''PRESERVE TRIGGER:''' Makes the trigger fire whenever the conditions are fulfilled. Be careful with these and always put a WAIT before them unless you want a constantly running trigger (which will really lag things down).

*'''REMOVE UNIT:''' Removes all of a player’s units of a certain type without killing them; more or less makes them disappear forever. Good if you need to get rid of a unit, but you have a trigger that will go off if you kill it.

*'''REMOVE UNITS AT LOCATION:''' Just like KILL UNITS AT LOCATION, but removing instead of killing.

*'''RUN AI SCRIPT:''' This is basically useless with just StarEdit. Ignore it.

*'''RUN AI SCRIPT AT LOCATION:''' This, however, is very useful. Enter Bunker and Enter Transport are fairly self-explanatory. Using the scripts labeled with a race and difficulty level at a location over a computer player’s base will make them use their units and buildings as if they were playing a melee. Using ‘Value this area higher’ will give a location priority to attack and keep. NOTE: If you're running an AI script at a CPU base to make it play like it's in a melee, make sure you match up the race with the race of the CPU (i.e. Zerg scripts won't work with a Terran player).

*'''SET:''' There are a lot of things that can be set using triggers. They are:
**Allying and Allied Victory (ALLIANCE STATUS)
**The amount of time on the countdown timer (COUNTDOWN TIMER)
**The death count of a unit for a player (DEATHS)
**Doodad state (DOODAD STATE)
**Invincibility of units at a location (INVINCIBILITY)
**Mission objectives, accessed through the main menu (MISSION OBJECTIVES)
**A map to start after the current one is completed, for if you’re making a custom campaign (NEXT SCENARIO)
**Amount of minerals or gas (RESOURCES)
**Amount of points of a type (POINTS)
**Switch status, set or cleared (SWITCH)

*'''TALKING PORTRAIT:''' This shows a portrait of a unit of your choice doing it’s talking animation for the amount of time you set. This is what was used in the campaigns’ in-game cutscenes.

*'''TRANSMISSION:''' This simply combines TALKING PORTRAIT, PLAY WAV, and DISPLAY TEXT MESSAGE into one.

*'''UNMUTE UNIT SPEECH:''' Undoes the MUTE UNIT SPEECH action

*'''UNPAUSE GAME:''' Undoes the PAUSE GAME action.

*'''UNPAUSE TIMER:''' Undoes the PAUSE TIMER action.

*'''VICTORY:''' The opposite of DEFEAT, makes the current player win.

*'''WAIT:''' Stops the trigger from carrying on to the next action for the amount of time set. <br/>''Note regarding:'' The time for this action seems to be measured in a close approximant to real-life time. Altering the game speed does not alter the actual real-life time waited by the trigger. Note also that there are caveats with [[wait blocks|wait blocking]], which is when a player has two or more triggers that both use waits, and they are both run at the same time.

====A NOTE ON ACTIONS:====
Actions always fire in the order that you put them into a trigger, they don't all go off at once, so don't put a "Kill Units at Location" before a "Create Units" and expect the units you made to die. Also, the delay between the actions will be minimal unless you put in a Wait.

==See also==
*[[Triggers]]
**[[Triggers#Actions|Actions]]
*[[List of Trigger Conditions]]

[[Category:StarCraft]]
[[Category:Reference]]

Wait blocks

2019-11-23T09:58:22Z

Zurg: adding to the Reference category

'''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:

{{StarCraft Trigger
|description=Create a Marine every trigger cycle.
|players=*Player 1
|conditions=*Always
|actions=
*Create 1 [[Terran Marine (StarCraft)|Terran Marine]] at Anywhere for Player 1.
*Preserve trigger.
}}

{{StarCraft Trigger
|description=Display a message, wait a full second, and display another message.
|players=*Player 1
|conditions=*Always
|actions=
*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:

{{StarCraft Trigger
|description=TRIGGER 1. Create a Marine, wait a full second, and create another Marine.
|players=*Player 1
|conditions=*Always
|actions=
*Create 1 Terran Marine at Anywhere for Player 1.
*Wait 1000 milliseconds.
*Create 1 [[Terran SCV (StarCraft)|Terran SCV]] at Anywhere for Player 1.
*Preserve trigger.
}}

{{StarCraft Trigger
|description=TRIGGER 2. Display a message, wait a full second, and display another message.
|players=*Player 1
|conditions=*Always
|actions=
*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.
*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 ==
*[http://www.youtube.com/watch?v=olYjMbmqj5g A YouTube video] illustrating how waits are processed, using some of the example triggers [[#Inner workings of the wait action|in this article]].

[[Category:StarCraft]]
[[Category:Reference]]

Game speed

2019-03-17T04:11:39Z

Zurg: I'm actually pretty sure I wrote in the wrong number when writing this up intially and non-hypered trigger check interval is per 31 frames, and not 30

{{stub}}
I'm recreating a page here that seems, from all I can tell, to have previously existed prior to the recreation of the Wiki in March 2015 to flush out the spammers that had formed a hostile takeover. I've never seen the page before and the following are just my empirical observations from a test map in SC.

Frame time is in direct sync with game time; game speed alters game time. Game time on Fastest is roughly 1.50x realtime, but it seems to vary slightly as in SC2. Gamespeed normal varies a bit from 1.00x realtime as well. Using Wait(0) Hypers, ie every other frame of animation, Starcraft runs a trigger cycle 8 times every game second. From this we can extrapolate that there are 16 frames of animation per game second. Regular non-hypered trigger check interval is at 31 out of 32 frames. Therefore, there are 31 frames per trigger check on normal trigger cycle speed.

==See also==
*[[Regeneration]]
*[[Hyper Triggers]]

[[Category:Reference]]
[[Category:StarCraft]]

Binary Countoffs

2019-02-13T00:27:44Z

Zurg: updating hyperlink

A '''binary countoff''' is used to move the value of one counter to another counter with as few triggers as possible. It is important to know how the binary, or base 2, number system works. The reason for knowing how binary works is to help you understand how this trigger system works.

==Triggers==
<div class="trigger-sc1" style="width:625px;margin-bottom:1em;border:1px solid #000;background:#CCC">
<div class="trigger-sc1-header" style="padding:4px;border-bottom:1px solid #777;background:#AAA;font-weight:bold;vertical-align:middle">''StarCraft'' Trigger <span style="float:right;font-size:.8em">[<nowiki/>[[Template:StarCraft Trigger|template]]<nowiki/>]</span></div>
{{#if:{{{description|}}}|<div class="trigger-sc1-field trigger-sc1-description" style="float:left;width:75px;padding:4px;background:#CCC;font-weight:bold;vertical-align:middle">Description:</div>
<div class="trigger-sc1-value trigger-sc1-description" style="padding:4px 4px 4px 22px;margin-left:83px;background:#FFF">{{{description}}}</div>|}}
<div class="trigger-sc1-field trigger-sc1-players" style="float:left;clear:left;width:75px;padding:6px 4px 5px 4px;{{#if:{{{description|}}}|border-top:1px solid #888;|}}background:#CCC;font-weight:bold;vertical-align:middle">Players:</div>
<div class="trigger-sc1-value trigger-sc1-players" style="padding:1px 4px 5px 3px;margin-left:83px;{{#if:{{{description|}}}|border-top:1px solid #AAA;|}}background:#FFF">
{{{players|{{{1|*Neutral}}}}}}
</div>
<div class="trigger-sc1-field trigger-sc1-conditions" style="float:left;clear:left;width:75px;padding:6px 4px 5px 4px;border-top:1px solid #888;background:#CCC;font-weight:bold;vertical-align:middle">Conditions:</div>
<div class="trigger-sc1-value trigger-sc1-conditions" style="padding:1px 4px 5px 3px;margin-left:83px;border-top:1px solid #AAA;background:#FFF">
{{{conditions|{{{2|*Current player accumulates at least 16 gas.}}}}}}
</div>
<div class="trigger-sc1-field trigger-sc1-actions" style="float:left;clear:left;width:75px;padding:6px 4px 5px 4px;border-top:1px solid #888;background:#CCC;font-weight:bold;vertical-align:middle">Actions:</div>
<div class="trigger-sc1-value trigger-sc1-actions" style="padding:1px 4px 5px 3px;margin-left:83px;border-top:1px solid #AAA;background:#FFF;max-height:203px;overflow-y:auto">
{{{actions|{{{3|*Preserve trigger.
*Set Resources for current player: Add 16 minerals.
*Set Resources for current player: Subtract 16 gas.}}}}}}
</div><br style="clear:both;font-size:0;line-height:0"/></div>

<div class="trigger-sc1" style="width:625px;margin-bottom:1em;border:1px solid #000;background:#CCC">
<div class="trigger-sc1-header" style="padding:4px;border-bottom:1px solid #777;background:#AAA;font-weight:bold;vertical-align:middle">''StarCraft'' Trigger <span style="float:right;font-size:.8em">[<nowiki/>[[Template:StarCraft Trigger|template]]<nowiki/>]</span></div>
{{#if:{{{description|}}}|<div class="trigger-sc1-field trigger-sc1-description" style="float:left;width:75px;padding:4px;background:#CCC;font-weight:bold;vertical-align:middle">Description:</div>
<div class="trigger-sc1-value trigger-sc1-description" style="padding:4px 4px 4px 22px;margin-left:83px;background:#FFF">{{{description}}}</div>|}}
<div class="trigger-sc1-field trigger-sc1-players" style="float:left;clear:left;width:75px;padding:6px 4px 5px 4px;{{#if:{{{description|}}}|border-top:1px solid #888;|}}background:#CCC;font-weight:bold;vertical-align:middle">Players:</div>
<div class="trigger-sc1-value trigger-sc1-players" style="padding:1px 4px 5px 3px;margin-left:83px;{{#if:{{{description|}}}|border-top:1px solid #AAA;|}}background:#FFF">
{{{players|{{{1|*Neutral}}}}}}
</div>
<div class="trigger-sc1-field trigger-sc1-conditions" style="float:left;clear:left;width:75px;padding:6px 4px 5px 4px;border-top:1px solid #888;background:#CCC;font-weight:bold;vertical-align:middle">Conditions:</div>
<div class="trigger-sc1-value trigger-sc1-conditions" style="padding:1px 4px 5px 3px;margin-left:83px;border-top:1px solid #AAA;background:#FFF">
{{{conditions|{{{2|*Current player accumulates at least 8 gas.}}}}}}
</div>
<div class="trigger-sc1-field trigger-sc1-actions" style="float:left;clear:left;width:75px;padding:6px 4px 5px 4px;border-top:1px solid #888;background:#CCC;font-weight:bold;vertical-align:middle">Actions:</div>
<div class="trigger-sc1-value trigger-sc1-actions" style="padding:1px 4px 5px 3px;margin-left:83px;border-top:1px solid #AAA;background:#FFF;max-height:203px;overflow-y:auto">
{{{actions|{{{3|*Preserve trigger.
*Set Resources for current player: Add 8 minerals.
*Set Resources for current player: Subtract 8 gas.}}}}}}
</div><br style="clear:both;font-size:0;line-height:0"/></div>

<div class="trigger-sc1" style="width:625px;margin-bottom:1em;border:1px solid #000;background:#CCC">
<div class="trigger-sc1-header" style="padding:4px;border-bottom:1px solid #777;background:#AAA;font-weight:bold;vertical-align:middle">''StarCraft'' Trigger <span style="float:right;font-size:.8em">[<nowiki/>[[Template:StarCraft Trigger|template]]<nowiki/>]</span></div>
{{#if:{{{description|}}}|<div class="trigger-sc1-field trigger-sc1-description" style="float:left;width:75px;padding:4px;background:#CCC;font-weight:bold;vertical-align:middle">Description:</div>
<div class="trigger-sc1-value trigger-sc1-description" style="padding:4px 4px 4px 22px;margin-left:83px;background:#FFF">{{{description}}}</div>|}}
<div class="trigger-sc1-field trigger-sc1-players" style="float:left;clear:left;width:75px;padding:6px 4px 5px 4px;{{#if:{{{description|}}}|border-top:1px solid #888;|}}background:#CCC;font-weight:bold;vertical-align:middle">Players:</div>
<div class="trigger-sc1-value trigger-sc1-players" style="padding:1px 4px 5px 3px;margin-left:83px;{{#if:{{{description|}}}|border-top:1px solid #AAA;|}}background:#FFF">
{{{players|{{{1|*Neutral}}}}}}
</div>
<div class="trigger-sc1-field trigger-sc1-conditions" style="float:left;clear:left;width:75px;padding:6px 4px 5px 4px;border-top:1px solid #888;background:#CCC;font-weight:bold;vertical-align:middle">Conditions:</div>
<div class="trigger-sc1-value trigger-sc1-conditions" style="padding:1px 4px 5px 3px;margin-left:83px;border-top:1px solid #AAA;background:#FFF">
{{{conditions|{{{2|*Current player accumulates at least 4 gas.}}}}}}
</div>
<div class="trigger-sc1-field trigger-sc1-actions" style="float:left;clear:left;width:75px;padding:6px 4px 5px 4px;border-top:1px solid #888;background:#CCC;font-weight:bold;vertical-align:middle">Actions:</div>
<div class="trigger-sc1-value trigger-sc1-actions" style="padding:1px 4px 5px 3px;margin-left:83px;border-top:1px solid #AAA;background:#FFF;max-height:203px;overflow-y:auto">
{{{actions|{{{3|*Preserve trigger.
*Set Resources for current player: Add 4 minerals.
*Set Resources for current player: Subtract 4 gas.}}}}}}
</div><br style="clear:both;font-size:0;line-height:0"/></div>

<div class="trigger-sc1" style="width:625px;margin-bottom:1em;border:1px solid #000;background:#CCC">
<div class="trigger-sc1-header" style="padding:4px;border-bottom:1px solid #777;background:#AAA;font-weight:bold;vertical-align:middle">''StarCraft'' Trigger <span style="float:right;font-size:.8em">[<nowiki/>[[Template:StarCraft Trigger|template]]<nowiki/>]</span></div>
{{#if:{{{description|}}}|<div class="trigger-sc1-field trigger-sc1-description" style="float:left;width:75px;padding:4px;background:#CCC;font-weight:bold;vertical-align:middle">Description:</div>
<div class="trigger-sc1-value trigger-sc1-description" style="padding:4px 4px 4px 22px;margin-left:83px;background:#FFF">{{{description}}}</div>|}}
<div class="trigger-sc1-field trigger-sc1-players" style="float:left;clear:left;width:75px;padding:6px 4px 5px 4px;{{#if:{{{description|}}}|border-top:1px solid #888;|}}background:#CCC;font-weight:bold;vertical-align:middle">Players:</div>
<div class="trigger-sc1-value trigger-sc1-players" style="padding:1px 4px 5px 3px;margin-left:83px;{{#if:{{{description|}}}|border-top:1px solid #AAA;|}}background:#FFF">
{{{players|{{{1|*Neutral}}}}}}
</div>
<div class="trigger-sc1-field trigger-sc1-conditions" style="float:left;clear:left;width:75px;padding:6px 4px 5px 4px;border-top:1px solid #888;background:#CCC;font-weight:bold;vertical-align:middle">Conditions:</div>
<div class="trigger-sc1-value trigger-sc1-conditions" style="padding:1px 4px 5px 3px;margin-left:83px;border-top:1px solid #AAA;background:#FFF">
{{{conditions|{{{2|*Current player accumulates at least 2 gas.}}}}}}
</div>
<div class="trigger-sc1-field trigger-sc1-actions" style="float:left;clear:left;width:75px;padding:6px 4px 5px 4px;border-top:1px solid #888;background:#CCC;font-weight:bold;vertical-align:middle">Actions:</div>
<div class="trigger-sc1-value trigger-sc1-actions" style="padding:1px 4px 5px 3px;margin-left:83px;border-top:1px solid #AAA;background:#FFF;max-height:203px;overflow-y:auto">
{{{actions|{{{3|*Preserve trigger.
*Set Resources for current player: Add 2 minerals.
*Set Resources for current player: Subtract 2 gas.}}}}}}
</div><br style="clear:both;font-size:0;line-height:0"/></div>

<div class="trigger-sc1" style="width:625px;margin-bottom:1em;border:1px solid #000;background:#CCC">
<div class="trigger-sc1-header" style="padding:4px;border-bottom:1px solid #777;background:#AAA;font-weight:bold;vertical-align:middle">''StarCraft'' Trigger <span style="float:right;font-size:.8em">[<nowiki/>[[Template:StarCraft Trigger|template]]<nowiki/>]</span></div>
{{#if:{{{description|}}}|<div class="trigger-sc1-field trigger-sc1-description" style="float:left;width:75px;padding:4px;background:#CCC;font-weight:bold;vertical-align:middle">Description:</div>
<div class="trigger-sc1-value trigger-sc1-description" style="padding:4px 4px 4px 22px;margin-left:83px;background:#FFF">{{{description}}}</div>|}}
<div class="trigger-sc1-field trigger-sc1-players" style="float:left;clear:left;width:75px;padding:6px 4px 5px 4px;{{#if:{{{description|}}}|border-top:1px solid #888;|}}background:#CCC;font-weight:bold;vertical-align:middle">Players:</div>
<div class="trigger-sc1-value trigger-sc1-players" style="padding:1px 4px 5px 3px;margin-left:83px;{{#if:{{{description|}}}|border-top:1px solid #AAA;|}}background:#FFF">
{{{players|{{{1|*Neutral}}}}}}
</div>
<div class="trigger-sc1-field trigger-sc1-conditions" style="float:left;clear:left;width:75px;padding:6px 4px 5px 4px;border-top:1px solid #888;background:#CCC;font-weight:bold;vertical-align:middle">Conditions:</div>
<div class="trigger-sc1-value trigger-sc1-conditions" style="padding:1px 4px 5px 3px;margin-left:83px;border-top:1px solid #AAA;background:#FFF">
{{{conditions|{{{2|*Current player accumulates at least 1 gas.}}}}}}
</div>
<div class="trigger-sc1-field trigger-sc1-actions" style="float:left;clear:left;width:75px;padding:6px 4px 5px 4px;border-top:1px solid #888;background:#CCC;font-weight:bold;vertical-align:middle">Actions:</div>
<div class="trigger-sc1-value trigger-sc1-actions" style="padding:1px 4px 5px 3px;margin-left:83px;border-top:1px solid #AAA;background:#FFF;max-height:203px;overflow-y:auto">
{{{actions|{{{3|*Preserve trigger.
*Set Resources for current player: Add 1 minerals.
*Set Resources for current player: Subtract 1 gas.}}}}}}
</div><br style="clear:both;font-size:0;line-height:0"/></div>

As you can see the triggers take this form:

<div class="trigger-sc1" style="width:625px;margin-bottom:1em;border:1px solid #000;background:#CCC">
<div class="trigger-sc1-header" style="padding:4px;border-bottom:1px solid #777;background:#AAA;font-weight:bold;vertical-align:middle">''StarCraft'' Trigger <span style="float:right;font-size:.8em">[<nowiki/>[[Template:StarCraft Trigger|template]]<nowiki/>]</span></div>
{{#if:{{{description|}}}|<div class="trigger-sc1-field trigger-sc1-description" style="float:left;width:75px;padding:4px;background:#CCC;font-weight:bold;vertical-align:middle">Description:</div>
<div class="trigger-sc1-value trigger-sc1-description" style="padding:4px 4px 4px 22px;margin-left:83px;background:#FFF">{{{description}}}</div>|}}
<div class="trigger-sc1-field trigger-sc1-players" style="float:left;clear:left;width:75px;padding:6px 4px 5px 4px;{{#if:{{{description|}}}|border-top:1px solid #888;|}}background:#CCC;font-weight:bold;vertical-align:middle">Players:</div>
<div class="trigger-sc1-value trigger-sc1-players" style="padding:1px 4px 5px 3px;margin-left:83px;{{#if:{{{description|}}}|border-top:1px solid #AAA;|}}background:#FFF">
{{{players|{{{1|*Neutral}}}}}}
</div>
<div class="trigger-sc1-field trigger-sc1-conditions" style="float:left;clear:left;width:75px;padding:6px 4px 5px 4px;border-top:1px solid #888;background:#CCC;font-weight:bold;vertical-align:middle">Conditions:</div>
<div class="trigger-sc1-value trigger-sc1-conditions" style="padding:1px 4px 5px 3px;margin-left:83px;border-top:1px solid #AAA;background:#FFF">
{{{conditions|{{{2|*Current player accumulates at least 2^x gas.}}}}}}
</div>
<div class="trigger-sc1-field trigger-sc1-actions" style="float:left;clear:left;width:75px;padding:6px 4px 5px 4px;border-top:1px solid #888;background:#CCC;font-weight:bold;vertical-align:middle">Actions:</div>
<div class="trigger-sc1-value trigger-sc1-actions" style="padding:1px 4px 5px 3px;margin-left:83px;border-top:1px solid #AAA;background:#FFF;max-height:203px;overflow-y:auto">
{{{actions|{{{3|*Preserve trigger.
*Set Resources for current player: Add 2^x minerals.
*Set Resources for current player: Subtract 2^x gas.}}}}}}
</div><br style="clear:both;font-size:0;line-height:0"/></div>

Where x keeps going down until it reaches 0. In the previous example x goes from 4 to 0.

Notice that the numbers are powers of 2 (1, 2, 4, 8, 16, etc) in reverse order. In order to calculate the maximum number transferable per trigger run, take the sum of the same value from each trigger. A simpler way to calculate it would be to take the next power of 2 higher than the highest power of 2 in the countoff (2^5 in the example) and subtract 1. In the above case, 31 gas will be converted into minerals per trigger run.
Because of the use of powers of two in the order shown, any number between 0 and 31 can be transferred in one trigger cycle with just these 5 triggers.

Adding more triggers increases the number range exponentially.

A binary countoff like this can be useful for various things, such as [[Counter Arithmetic|counter arithmetic]], or almost anything else.

[[Category:StarCraft]]
[[Category:Reference]]

Game speed

2018-05-29T22:48:39Z

Zurg: This way is easier to express without errors

{{stub}}
I'm recreating a page here that seems, from all I can tell, to have previously existed prior to the recreation of the Wiki in March 2015 to flush out the spammers that had formed a hostile takeover. I've never seen the page before and the following are just my empirical observations from a test map in SC.

Frame time is in direct sync with game time; game speed alters game time. Game time on Fastest is roughly 1.5x realtime, but it seems to vary slightly as in SC2. Gamespeed normal varies a bit from 1.0x realtime as well. Using Wait(0) Hypers, ie every other frame of animation, Starcraft runs a trigger cycle 8 times every game second. From this we can extrapolate that there are 16 frames of animation per game second. Regular non-hypered trigger check interval is at 30 out of 32 frames. Therefore, there are 30 frames per trigger check on normal trigger cycle speed.

==See also==
*[[Regeneration]]
*[[Hyper Triggers]]

[[Category:Reference]]
[[Category:StarCraft]]

Game speed

2018-05-29T22:44:30Z

Zurg: Fixed another error

{{stub}}
I'm recreating a page here that seems, from all I can tell, to have previously existed prior to the recreation of the Wiki in March 2015 to flush out the spammers that had formed a hostile takeover. I've never seen the page before and the following are just my empirical observations from a test map in SC.

Frame time is in direct sync with game time; game speed alters game time. Game time on Fastest is roughly 1.5x realtime, but it seems to vary slightly as in SC2. Gamespeed normal varies a bit from 1.0x realtime as well. Using Wait(0) Hypers, ie every other frame of animation, Starcraft runs a trigger cycle 8 times every game second. From this we can extrapolate that there are 16 frames of animation per game second. Regular non-hypered trigger check interval is at 15 out of 16 frames. Therefore, there are 15 frames per trigger check on normal trigger cycle speed.

==See also==
*[[Regeneration]]
*[[Hyper Triggers]]

[[Category:Reference]]
[[Category:StarCraft]]

Game speed

2017-09-29T06:10:18Z

Zurg: Might as well fix this too

{{stub}}
I'm recreating a page here that seems, from all I can tell, to have previously existed prior to the recreation of the Wiki in March 2015 to flush out the spammers that had formed a hostile takeover. I've never seen the page before and the following are just my empirical observations from a test map in SC.

Frame time is in direct sync with game time; game speed alters game time. Game time on Fastest is roughly 1.5x realtime, but it seems to vary slightly as in SC2. Gamespeed normal varies a bit from 1.0x realtime as well. Using Wait(0) Hypers, ie every other frame of animation, Starcraft runs a trigger cycle 8 times every game second. From this we can extrapolate that there are 16 frames of animation per game second. Regular non-hypered trigger check interval is 16 per 15 game seconds. Therefore, there are 15 frames per trigger check on normal trigger cycle speed.

==See also==
*[[Regeneration]]
*[[Hyper Triggers]]

[[Category:Reference]]
[[Category:StarCraft]]

Game speed

2017-09-29T04:53:36Z

Zurg: might as well fix it

{{stub}}
I'm recreating a page here that seems, from all I can tell, to have previously existed prior to the recreation of the Wiki in March 2015 to flush out the spammers that had formed a hostile takeover. I've never seen the page before and the following are just my empirical observations from a test map in SC.

Frame time is in direct sync with game time; game speed alters game time. Game time on Fastest is roughly 1.5x realtime, but it seems to vary slightly as in SC2. Gamespeed normal varies a bit from 1.0x realtime as well. Using Wait(0) Hypers, ie every other frame of animation, Starcraft runs a trigger cycle 8 times every game second. From this we can extrapolate that there are 16 frames of animation per game second. Regular non-hypered trigger check interval is 16 per 15 game seconds. This doesn't line up correctly with an even frame interval; it may either be that default trigger cycles indeed are not synchronous with the basic frames of animation, and thus are odd and rounded, or that there is a slight error in my observations.

==See also==
*[[Regeneration]]
*[[Hyper Triggers]]

[[Category:Reference]]
[[Category:StarCraft]]

Regeneration

2015-08-06T23:10:16Z

Zurg: /* Healing Rates */

In [[StarCraft]], regeneration is the slow increase of a unit's health, shields, or energy.

===How It Works===
To understand regeneration, you have to understand that Starcraft hides data from you. Health and Shields each are stored in memory in 4 bytes, however Starcraft only tells you the last 3 bytes. The first byte is actually a hidden value which acts as a timer for regeneration. 1 byte = 8 bits, or 2<sup>8</sup> = 256.

Each frame, a certain regeneration amount is added (or subtracted) to the first byte, according to values in the mpqs:

*Protoss Shields: 7
*Zerg Health: 4
*Energy: 8
*Shield Battery: 1280
*Recharge Shields: -640 (-632 net)
*Burning Terran Building: -20
*Medic: 200
*Personnel Cloaking(Ghost): -18 (-10 net)
*Cloaking Field(Wraith): -21 (-13 net)
*Heal: -100 (-92 net)

SCVs repair units and buildings in a similar way, based on build time and total HP. Multiple SCVs increase the repair rate by adding them together.<br />
R = roundup(.9 * H/B)<br />
where R = repair rate in 1/256 of hp per frame, H = HP, B = build rate in SCMDraft.<br />
One important note is that R is a 2 byte value, which means that when R > 65535, it loops back over to 0. Here is an example:<br />
A Terran Barracks with a build time of 1, HP of 9999.<br />
R = roundup(.9 * 256*9999/1) = 2303770. R>65535, so it rolls over in multiples of 65535.<br />
R = 2303770- k65535, R = 10010. Note that this is still fairly large, and means that each SCV will repair approximately 39 HP every frame.<br />
A slightly more realistic value is that of the default battlecruiser with 500 HP, 2000 Build time:<br />
R= roundup(.9 * 500*256/2000) = 58.<br />

Building units follows the same formula, and this explains why some buildings/units come out injured, except they start out with 10% of the base HP, plus 1 frame of "repairing", plus the time it takes to build. In the case of the terran barracks, it will build in 1 frame and come out with .1 * 9999 + 10010/256 + 10010/256 = 1078.1 HP.

===Healing Rates===
''The time used here is realtime.''
Since Starcraft is normally played on fastest, or 24 fps, we can calculate the approximate rates of healing:
*Protoss shields use 7, so 256/7/24=~1.5 seconds per shield point.
*Zerg Health use 4, so 256/4/24=~2.67 seconds per health point.
*Medics' Healing uses 200, so 256/200/24=0.053 seconds per health point or 18.75 health per second.
*Shield batteries use 1280, so 256/1280/24=0.0083 seconds per shield point or 120 shields per second.

Other rates can be similarly calculated.
[[Category:StarCraft]]
[[Category:Reference]]

StarEdit

2015-08-06T07:13:08Z

Zurg: copyedit

{{Stub|section}}
'''StarCraft Campaign Editor (StarEdit)''' is the stock map editor provided by Blizzard to create custom StarCraft [[maps]]. Compared to third-party editors such as [[SCMDraft 2]], StarEdit is simple to use but lacking in support of various (unintended) features and capabilities of the game. StarEdit also comes with an interesting helpfile that explains some of the workings of maps and triggers from Blizzard's perspective.

[[Category:StarCraft]]
[[Category:Tools and Programs]]

Set Doodad State

2015-08-06T07:12:06Z

Zurg: removing categ trigger actions

'''Set Doodad State''' is a [[Triggers|trigger]] action in ''[[StarCraft]]''. It was originally intended for use with [[doodad]] [[units]]. When used on other units (via the use of a third-party [[map editor]]), it can cause a number of strange effects, though the two most common are the [[cloaking]] of non-cloakable units and game crashes.

== Background ==
Some doodads on the Installation tileset have [[Sprites#Unit sprites|unit sprites]] attached to them; these unit sprites function quite similarly to ordinary units. The units include doors and "trap" units that attack when hostiles approach. Set Doodad State was designed to allow mappers to manipulate and script the behaviors of these units.

Set Doodad State lets a mapper ''enable'' or ''disable'' a unit. When door units are enabled, they close; disabling them causes them to open, and let other units pass. Trap units engage and enter their attack states when enabled; disabling them causes them to withdraw.

When used on non-doodad units, however, the trigger action essentially causes the execution of non-existent game scripts.  Essentially, this is an example of [[Wikipedia:undefined behavior|undefined behavior]].

== Effects by unit ==
The following units labeled "cloaks" will almost always cloak when disabled, though some may experience other quirks.

Note that buildings must be [[Vision#Detection|detected]] or otherwise seen by a player before cloaking (and then they only appear cloaked to that player and anyone that shares [[vision]] of them). [[Protoss]] buildings must also either be powered by a [[Protoss Pylon]] or enabled (before being disabled). [[Terran]] add-ons must be attached to their host building to cloak. All cloaked buildings will be visible in the light [[fog of war]] that covers areas that a player has explored but doesn't have vision of.

Certain overlays (such as on beacons, powered shield batteries, or building fire) will still be visible when the unit is cloaked. This is useful for creating certain effects like burning trees or lights.

Some units cannot be placed on a map for various reasons (or do not appear during gameplay), and hence cannot be tested. These units are marked as "Unknown/unused".

Disabled powerups can not be picked up.
{| class="wikitable sortable" width="100%" style = "text-align:left;"
|-
!Name
!UnitID
!Type
!Effect
!Notes
|-
||[[Terran Marine]]||0||Unit||Cloaks ||Cloaks with animation
|-
||[[Terran Ghost]]||1||Unit||Cloaks ||Cloaks with animation
|-
||[[Terran Vulture]]||2||Unit||Crashes
|-
||[[Terran Goliath]]||3||Unit||Crashes
|-
||[[Goliath Turret]]||4||Crash||Unknown/unused
|-
||[[Terran Siege Tank (Tank Mode)]]||5||Unit||Cloaks ||Cloaks with animation
|-
||[[Tank Turret (Tank Mode)]]||6||Crash||Unknown/unused
|-
||[[Terran SCV]]||7||Unit||Crashes
|-
||[[Terran Wraith]]||8||Unit||Crashes
|-
||[[Terran Science Vessel]]||9||Unit||Crashes
|-
||[[Gui Montang (Firebat)]]||10||Unit||Cloaks
|-
||[[Terran Dropship]]||11||Unit||Crashes
|-
||[[Terran Battlecruiser]]||12||Unit||Crashes
|-
||[[Vulture Spider Mine]]||13||Unit||No effect
|-
||[[Nuclear Missile]]||14||Unit||Cloaks
|-
||[[Terran Civilian]]||15||Unit||Crashes
|-
||[[Sarah Kerrigan (Ghost)]]||16||Unit||Cloaks ||Cloaks with animation
|-
||[[Alan Schezar (Goliath)]]||17||Unit||Crashes
|-
||[[Alan Turret]]||18||Crash||Unknown/unused
|-
||[[Jim Raynor (Vulture)]]||19||Unit||Crashes
|-
||[[Jim Raynor (Marine)]]||20||Unit||Cloaks ||Cloaks with animation
|-
||[[Tom Kazansky (Wraith)]]||21||Unit||Crashes
|-
||[[Magellan (Science Vessel)]]||22||Unit||Crashes
|-
||[[Edmund Duke (Siege Tank)]]||23||Unit||Cloaks ||Cloaks with animation
|-
||[[Duke Turret]]||24||Crash||Unknown/unused
|-
||[[Edmund Duke (Siege Mode)]]||25||Unit||Crashes
|-
||[[Duke Turret]]||26||Crash||Unknown/unused
|-
||[[Arcturus Mengsk (Battlecruiser)]]||27||Unit||Crashes
|-
||[[Hyperion (Battlecruiser)]]||28||Unit||Crashes
|-
||[[Norad II (Battlecruiser)]]||29||Unit||Crashes
|-
||[[Terran Siege Tank (Siege Mode)]]||30||Unit||Crashes
|-
||[[Tank Turret (Siege Mode)]]||31||Crash||Unknown/unused
|-
||[[Terran Firebat]]||32||Unit||Cloaks
|-
||[[Scanner Sweep]]||33||Spell||No effect
|-
||[[Terran Medic]]||34||Unit||Crashes
|-
||[[Zerg Larva]]||35||Unit||Crashes
|-
||[[Zerg Egg]]||36||Unit||Disappears||Unstable
|-
||[[Zerg Zergling]]||37||Unit||Crashes
|-
||[[Zerg Hydralisk]]||38||Unit||Crashes
|-
||[[Zerg Ultralisk]]||39||Unit||Crashes
|-
||[[Zerg Broodling]]||40||Unit||Disappears with animation||Unstable
|-
||[[Zerg Drone]]||41||Unit||Crashes
|-
||[[Zerg Overlord]]||42||Unit||Crashes
|-
||[[Zerg Mutalisk]]||43||Unit||Crashes
|-
||[[Zerg Guardian]]||44||Unit||Crashes
|-
||[[Zerg Queen]]||45||Unit||Crashes
|-
||[[Zerg Defiler]]||46||Unit||Crashes
|-
||[[Zerg Scourge]]||47||Unit||Crashes
|-
||[[Torrarsque (Ultralisk)]]||48||Unit||Crashes
|-
||[[Matriarch (Queen)]]||49||Unit||Crashes
|-
||[[Infested Terran]]||50||Unit||Crashes
|-
||[[Infested Kerrigan]]||51||Unit||Crashes
|-
||[[Unclean One (Defiler)]]||52||Unit||Crashes
|-
||[[Hunter Killer (Hydralisk)]]||53||Unit||Crashes
|-
||[[Devouring One (Zergling)]]||54||Unit||Crashes
|-
||[[Kukulza (Mutalisk)]]||55||Unit||Crashes
|-
||[[Kukulza (Guardian)]]||56||Unit||Crashes
|-
||[[Yggdrasill (Overlord)]]||57||Unit||Crashes
|-
||[[Terran Valkyrie]]||58||Unit||Crashes
|-
||[[Cocoon]]||59||Unit||Crashes
|-
||[[Protoss Corsair]]||60||Unit||Crashes
|-
||[[Protoss Dark Templar]]||61||Unit||Crashes
|-
||[[Zerg Devourer]]||62||Unit||Crashes
|-
||[[Protoss Dark Archon]]||63||Unit||Crashes
|-
||[[Protoss Probe]]||64||Unit||Crashes
|-
||[[Protoss Zealot]]||65||Unit||Crashes
|-
||[[Protoss Dragoon]]||66||Unit||Crashes
|-
||[[Protoss High Templar]]||67||Unit||Crashes
|-
||[[Protoss Archon]]||68||Unit||Crashes
|-
||[[Protoss Shuttle]]||69||Unit||Crashes
|-
||[[Protoss Scout]]||70||Unit||Crashes
|-
||[[Protoss Arbiter]]||71||Unit||Crashes
|-
||[[Protoss Carrier]]||72||Unit||Crashes
|-
||[[Protoss Interceptor]]||73||Unit||Cloaks
|-
||[[Dark Templar (Hero)]]||74||Unit||Crashes
|-
||[[Zeratul (Dark Templar)]]||75||Unit||Crashes
|-
||[[Tassadar/Zeratul (Archon)]]||76||Unit||Crashes
|-
||[[Fenix (Zealot)]]||77||Unit||Crashes
|-
||[[Fenix (Dragoon)]]||78||Unit||Crashes
|-
||[[Tassadar (Templar)]]||79||Unit||Crashes
|-
||[[Mojo (Scout)]]||80||Unit||Crashes
|-
||[[Warbringer (Reaver)]]||81||Unit||Crashes
|-
||[[Gantrithor (Carrier)]]||82||Unit||Crashes
|-
||[[Protoss Reaver]]||83||Unit||Crashes
|-
||[[Protoss Observer]]||84||Unit||Crashes
|-
||[[Protoss Scarab]]||85||Unit||Cloaks ||Cloaks with animation
|-
||[[Danimoth (Arbiter)]]||86||Unit||Crashes
|-
||[[Aldaris (Templar)]]||87||Unit||Crashes
|-
||[[Artanis (Scout)]]||88||Unit||Crashes
|-
||[[Rhynadon (Badlands Critter)]]||89||Unit||Crashes
|-
||[[Bengalaas (Jungle Critter)]]||90||Unit||Crashes
|-
||[[Unused - Was Cargo Ship]]||91||Special||Crashes
|-
||[[Unused - Was Mercenary Gunship]]||92||Special||Crashes
|-
||[[Scantid (Desert Critter)]]||93||Unit||Crashes
|-
||[[Kakaru (Twilight Critter)]]||94||Unit||Crashes
|-
||[[Ragnasaur (Ashworld Critter)]]||95||Unit||Crashes
|-
||[[Ursadon (Ice World Critter)]]||96||Unit||Crashes
|-
||[[Lurker Egg]]||97||Unit||Crashes
|-
||[[Raszagal (Corsair)]]||98||Unit||Crashes
|-
||[[Samir Duran (Ghost)]]||99||Unit||Cloaks ||Cloaks with animation
|-
||[[Alexei Stukov (Ghost)]]||100||Unit||Cloaks ||Cloaks with animation
|-
||[[Map Revealer]]||101||Special||Unknown/unused
|-
||[[Gerard DuGalle (Battlecruiser)]]||102||Unit||Crashes
|-
||[[Zerg Lurker]]||103||Unit||Crashes
|-
||[[Infested Duran]]||104||Unit||Cloaks ||Cloaks with animation
|-
||[[Disruption Web]]||105||Spell||No effect
|-
||[[Terran Command Center]]||106||Building||Crashes
|-
||[[Terran Comsat Station]]||107||Building||Crashes
|-
||[[Terran Nuclear Silo]]||108||Building||Cloaks
|-
||[[Terran Supply Depot]]||109||Building||Cloaks
|-
||[[Terran Refinery]]||110||Building||Crashes
|-
||[[Terran Barracks]]||111||Building||Cloaks
|-
||[[Terran Academy]]||112||Building||Crashes
|-
||[[Terran Factory]]||113||Building||Cloaks
|-
||[[Terran Starport]]||114||Building||Crashes
|-
||[[Terran Control Tower]]||115||Building||Cloaks
|-
||[[Terran Science Facility]]||116||Building||Crashes||Disappears
|-
||[[Terran Covert Ops]]||117||Building||Crashes
|-
||[[Terran Physics Lab]]||118||Building||Crashes
|-
||[[Unused - Was Starbase?]]||119||Crash||Unknown/unused
|-
||[[Terran Machine Shop]]||120||Building||Crashes
|-
||[[Unused - Was Repair Bay?]]||121||Crash||Unknown/unused
|-
||[[Terran Engineering Bay]]||122||Building||Cloaks
|-
||[[Terran Armory]]||123||Building||Crashes
|-
||[[Terran Missile Turret]]||124||Building||Crashes
|-
||[[Terran Bunker]]||125||Building||Cloaks
|-
||[[Norad II (Crashed Battlecruiser)]]||126||Building||Crashes
|-
||[[Ion Cannon]]||127||Building||Cloaks||Base unit has no shadow
|-
||[[Uraj Crystal]]||128||Powerup||Cloaks
|-
||[[Khalis Crystal]]||129||Powerup||Cloaks
|-
||[[Infested Command Center]]||130||Building||Crashes
|-
||[[Zerg Hatchery]]||131||Building||Crashes
|-
||[[Zerg Lair]]||132||Building||Crashes
|-
||[[Zerg Hive]]||133||Building||Crashes
|-
||[[Zerg Nydus Canal]]||134||Building||Crashes
|-
||[[Zerg Hydralisk Den]]||135||Building||Crashes
|-
||[[Zerg Defiler Mound]]||136||Building||Crashes
|-
||[[Zerg Greater Spire]]||137||Building||Crashes
|-
||[[Zerg Queen's Nest]]||138||Building||Crashes
|-
||[[Zerg Evolution Chamber]]||139||Building||Crashes
|-
||[[Zerg Ultralisk Cavern]]||140||Building||Crashes
|-
||[[Zerg Spire]]||141||Building||Crashes
|-
||[[Zerg Spawning Pool]]||142||Building||Crashes
|-
||[[Zerg Creep Colony]]||143||Building||Crashes
|-
||[[Zerg Spore Colony]]||144||Building||Crashes
|-
||[[Unused Zerg Building]]||145||Crash||Unknown/unused
|-
||[[Zerg Sunken Colony]]||146||Building||Crashes
|-
||[[Zerg Overmind (With Shell)]]||147||Building||Cloaks||Base unit has no shadow
|-
||[[Zerg Overmind]]||148||Building||Crashes
|-
||[[Zerg Extractor]]||149||Building||Crashes
|-
||[[Mature Chrysalis]]||150||Building||Crashes
|-
||[[Zerg Cerebrate]]||151||Building||Crashes
|-
||[[Zerg Cerebrate Daggoth]]||152||Building||Crashes
|-
||[[Unused Zerg Building 5]]||153||Crash||Unknown/unused
|-
||[[Protoss Nexus]]||154||Building||Crashes
|-
||[[Protoss Robotics Facility]]||155||Building||Cloaks
|-
||[[Protoss Pylon]]||156||Building||Crashes
|-
||[[Protoss Assimilator]]||157||Building||Cloaks
|-
||[[Unused Protoss Building]]||158||Crash||Unknown/unused
|-
||[[Protoss Observatory]]||159||Building||Cloaks
|-
||[[Protoss Gateway]]||160||Building||Cloaks
|-
||[[Unused Protoss Building]]||161||Crash||Unknown/unused
|-
||[[Protoss Photon Cannon]]||162||Building||Cloaks
|-
||[[Protoss Citadel of Adun]]||163||Building||Cloaks
|-
||[[Protoss Cybernetics Core]]||164||Building||Cloaks
|-
||[[Protoss Templar Archives]]||165||Building||Cloaks
|-
||[[Protoss Forge]]||166||Building||Cloaks
|-
||[[Protoss Stargate]]||167||Building||Cloaks||Overlay visible (when powered)
|-
||[[Stasis Cell/Prison]]||168||Building||Cloaks
|-
||[[Protoss Fleet Beacon]]||169||Building||Cloaks
|-
||[[Protoss Arbiter Tribunal]]||170||Building||Cloaks
|-
||[[Protoss Robotics Support Bay]]||171||Building||Cloaks
|-
||[[Protoss Shield Battery]]||172||Building||Cloaks||Overlay visible (when powered)
|-
||[[Khaydarin Crystal Formation]]||173||Building||Cloaks
|-
||[[Protoss Temple]]||174||Building||Cloaks
|-
||[[Xel'Naga Temple]]||175||Building||Crashes
|-
||[[Mineral Field (Type 1)]]||176||Building||Crashes||Crashes with animation
|-
||[[Mineral Field (Type 2)]]||177||Building||Crashes||Crashes with animation
|-
||[[Mineral Field (Type 3)]]||178||Building||Crashes||Crashes with animation
|-
||[[Cave]]||179||Crash||Unknown/unused
|-
||[[Cave-in]]||180||Crash||Unknown/unused
|-
||[[Cantina]]||181||Crash||Unknown/unused
|-
||[[Mining Platform]]||182||Crash||Unknown/unused
|-
||[[Independant Command Center]]||183||Crash||Unknown/unused
|-
||[[Independant Starport]]||184||Special||Unknown/unused
|-
||[[Jump Gate]]||185||Crash||Unknown/unused
|-
||[[Ruins]]||186||Crash||Unknown/unused
|-
||[[Kyadarin Crystal Formation]]||187||Crash||Unknown/unused
|-
||[[Vespene Geyser]]||188||Building||Crashes
|-
||[[Warp Gate]]||189||Building||Crashes
|-
||[[PSI Disruptor]]||190||Building||Crashes
|-
||[[Zerg Marker]]||191||Crash||Unknown/unused
|-
||[[Terran Marker]]||192||Crash||Unknown/unused
|-
||[[Protoss Marker]]||193||Crash||Unknown/unused
|-
||[[Zerg Beacon]]||194||Building||Cloaks||Overlay visible
|-
||[[Terran Beacon]]||195||Building||Cloaks||Overlay visible
|-
||[[Protoss Beacon]]||196||Building||Cloaks||Overlay visible
|-
||[[Zerg Flag Beacon]]||197||Building||Cloaks||Overlay visible
|-
||[[Terran Flag Beacon]]||198||Building||Cloaks||Overlay visible
|-
||[[Protoss Flag Beacon]]||199||Building||Cloaks||Overlay visible
|-
||[[Power Generator]]||200||Building||Crashes
|-
||[[Overmind Cocoon]]||201||Building||Crashes
|-
||[[Dark Swarm]]||202||Spell||No effect
|-
||[[Floor Missile Trap]]||203||Doodad||Doodad unit; disengages
|-
||[[Floor Hatch]]||204||Doodad||Doodad unit; disengages and cloaks
|-
||[[Left Upper Level Door]]||205||Doodad||Doodad unit; disengages
|-
||[[Right Upper Level Door]]||206||Doodad||Doodad unit; disengages
|-
||[[Left Pit Door]]||207||Doodad||Doodad unit; disengages
|-
||[[Right Pit Door]]||208||Doodad||Doodad unit; disengages
|-
||[[Floor Gun Trap]]||209||Doodad||Doodad unit; disengages
|-
||[[Left Wall Missile Trap]]||210||Doodad||Doodad unit; disengages
|-
||[[Left Wall Flame Trap]]||211||Doodad||Doodad unit; disengages
|-
||[[Right Wall Missile Trap]]||212||Doodad||Doodad unit; disengages
|-
||[[Right Wall Flame Trap]]||213||Doodad||Doodad unit; disengages
|-
||[[Start Location]]||214||Special||Unknown/unused
|-
||[[Flag]]||215||Powerup||No effect
|-
||[[Young Chrysalis]]||216||Powerup||Cloaks
|-
||[[Psi Emitter]]||217||Powerup||Cloaks
|-
||[[Data Disc]]||218||Powerup||Cloaks
|-
||[[Khaydarin Crystal]]||219||Powerup||Cloaks
|-
||[[Mineral Cluster Type 1]]||220||Powerup||Cloaks
|-
||[[Mineral Cluster Type 2]]||221||Powerup||Cloaks
|-
||[[Protoss Vespene Gas Orb Type 1]]||222||Powerup||Cloaks
|-
||[[Protoss Vespene Gas Orb Type 2]]||223||Powerup||Cloaks
|-
||[[Zerg Vespene Gas Sac Type 1]]||224||Powerup||Cloaks
|-
||[[Zerg Vespene Gas Sac Type 2]]||225||Powerup||Cloaks
|-
||[[Terran Vespene Gas Tank Type 1]]||226||Powerup||Cloaks
|-
||[[Terran Vespene Gas Tank Type 2]]||227||Powerup||Cloaks
|}

[[Category:StarCraft]]
[[Category:Reference]]

Category:Tools and Programs

2015-08-06T07:10:41Z

Zurg: Created page with "A category for some tools and programs for SC, mapping and modding, that have a page here on the Wiki."

A category for some tools and programs for SC, mapping and modding, that have a page here on the Wiki.

Regeneration

2015-08-06T07:09:04Z

Zurg: /* Healing Rates */ hatnote; realtime

In [[StarCraft]], regeneration is the slow increase of a unit's health, shields, or energy.

===How It Works===
To understand regeneration, you have to understand that Starcraft hides data from you. Health and Shields each are stored in memory in 4 bytes, however Starcraft only tells you the last 3 bytes. The first byte is actually a hidden value which acts as a timer for regeneration. 1 byte = 8 bits, or 2<sup>8</sup> = 256.

Each frame, a certain regeneration amount is added (or subtracted) to the first byte, according to values in the mpqs:

*Protoss Shields: 7
*Zerg Health: 4
*Energy: 8
*Shield Battery: 1280
*Recharge Shields: -640 (-632 net)
*Burning Terran Building: -20
*Medic: 200
*Personnel Cloaking(Ghost): -18 (-10 net)
*Cloaking Field(Wraith): -21 (-13 net)
*Heal: -100 (-92 net)

SCVs repair units and buildings in a similar way, based on build time and total HP. Multiple SCVs increase the repair rate by adding them together.<br />
R = roundup(.9 * H/B)<br />
where R = repair rate in 1/256 of hp per frame, H = HP, B = build rate in SCMDraft.<br />
One important note is that R is a 2 byte value, which means that when R > 65535, it loops back over to 0. Here is an example:<br />
A Terran Barracks with a build time of 1, HP of 9999.<br />
R = roundup(.9 * 256*9999/1) = 2303770. R>65535, so it rolls over in multiples of 65535.<br />
R = 2303770- k65535, R = 10010. Note that this is still fairly large, and means that each SCV will repair approximately 39 HP every frame.<br />
A slightly more realistic value is that of the default battlecruiser with 500 HP, 2000 Build time:<br />
R= roundup(.9 * 500*256/2000) = 58.<br />

Building units follows the same formula, and this explains why some buildings/units come out injured, except they start out with 10% of the base HP, plus 1 frame of "repairing", plus the time it takes to build. In the case of the terran barracks, it will build in 1 frame and come out with .1 * 9999 + 10010/256 + 10010/256 = 1078.1 HP.

===Healing Rates===
:''The time used here is realtime.''
Since Starcraft is normally played on fastest, or 24 fps, we can calculate the approximate rates of healing:
*Protoss shields use 7, so 256/7/24=~1.5 seconds per shield point.
*Zerg Health use 4, so 256/4/24=~2.67 seconds per health point.
*Medics' Healing uses 200, so 256/200/24=0.053 seconds per health point or 18.75 health per second.
*Shield batteries use 1280, so 256/1280/24=0.0083 seconds per shield point or 120 shields per second.

Other rates can be similarly calculated.
[[Category:StarCraft]]
[[Category:Reference]]

Game speed

2015-08-06T07:07:26Z

Zurg: Adding categs

{{stub}}
I'm recreating a page here that seems, from all I can tell, to have previously existed prior to the recreation of the Wiki in March 2015 to flush out the spammers that had formed a hostile takeover. I've never seen the page before and the following are just my empirical observations from a test map in SC.

Frame time is in direct sync with game time; game speed alters game time. Game time on Fastest is roughly 1.5x realtime, but it seems to vary slightly as in SC2. Gamespeed normal varies a bit from 1.0x realtime as well. Using Wait(0) Hypers, ie every other frame of animation, Starcraft runs a trigger cycle 8 times every game second. From this we can extrapolate that there are 4 frames of animation per game second. Regular non-hypered trigger check interval is 16 per 15 game seconds. This doesn't line up correctly with an even frame interval; it may either be that default trigger cycles indeed are not synchronous with the basic frames of animation, and thus are odd and rounded, or that there is a slight error in my observations.

==See also==
*[[Regeneration]]
*[[Hyper Triggers]]

[[Category:Reference]]
[[Category:StarCraft]]

Game speed

2015-08-06T07:06:38Z

Zurg: Created page with "{{stub}} I'm recreating a page here that seems, from all I can tell, to have previously existed prior to the recreation of the Wiki in March 2015 to flush out the spammers tha..."

{{stub}}
I'm recreating a page here that seems, from all I can tell, to have previously existed prior to the recreation of the Wiki in March 2015 to flush out the spammers that had formed a hostile takeover. I've never seen the page before and the following are just my empirical observations from a test map in SC.

Frame time is in direct sync with game time; game speed alters game time. Game time on Fastest is roughly 1.5x realtime, but it seems to vary slightly as in SC2. Gamespeed normal varies a bit from 1.0x realtime as well. Using Wait(0) Hypers, ie every other frame of animation, Starcraft runs a trigger cycle 8 times every game second. From this we can extrapolate that there are 4 frames of animation per game second. Regular non-hypered trigger check interval is 16 per 15 game seconds. This doesn't line up correctly with an even frame interval; it may either be that default trigger cycles indeed are not synchronous with the basic frames of animation, and thus are odd and rounded, or that there is a slight error in my observations.

==See also==
*[[Regeneration]]
*[[Hyper Triggers]]

Game Speed

2015-08-06T06:18:05Z

Zurg: Redirected page to Game speed

#REDIRECT [[Game speed]]

Hyper triggers

2015-08-03T03:08:25Z

Zurg: Redirected page to Hyper Triggers

#REDIRECT [[Hyper Triggers]]

Players

2015-08-03T03:07:22Z

Zurg: Redirected page to Player

#REDIRECT [[Player]]

Units

2015-08-03T03:05:32Z

Zurg: Redirected page to Unit

#REDIRECT [[Unit]]

Death counter

2015-08-03T03:00:14Z

Zurg: Redirected page to Death Counters

#REDIRECT [[Death Counters]]

Hyper trigger

2015-08-03T02:59:14Z

Zurg: Redirected page to Hyper Triggers

#REDIRECT [[Hyper Triggers]]

List of Trigger Actions

2015-08-03T02:59:06Z

Zurg:

Actions are (obviously) what a trigger does once the conditions are met.

Once again, I’ll be going through all of them, so if you’re looking for a specific action, use Ctrl + F.
*'''CENTER VIEW:''' Centers the selected player’s on a specified location.

*'''COMMENT:''' Gives the trigger a label so, when viewing the trigger in the main trigger window, it doesn’t display the actual trigger information, but instead the comment. Useful for quick reference when searching through a massive list of triggers for a certain one.

*'''CREATE UNITS:''' Creates an exact number of units at a location for the specified player.

*'''CREATE UNITS WITH PROPERTIES:''' The same as CREATE UNITS, but you can change the units that come out a little. You can make them cloaked (if they can have the Cloak ability), invincible, burrowed (if they can have the Burrow ability), hallucinated (as in the High Templar ability), or In-Transit (if they are buildings with the Lift-Off ability, i.e. Barracks, Factory). You can also change the percentage of remaining hit points, shields and energy. If you create a mineral field or vespene geyser, you can change the amount of minerals or gas in it by changing the number in the ‘Resources’ field. If you create a carrier or reaver, you can change the number of interceptors or scarabs (respectively) it spawns with by changing the number in the ‘In Hangar’ field. In Hanger doesn't work on Vulture spider mines.

*'''DEFEAT:''' Exactly what it sounds like, it makes the current player lose.

*'''DISPLAY TEXT MESSAGE:''' Causes the player to see a message on the left side of the screen, as they would in chat. NOTE: Remember to have the ‘Always display’ box checked.

*'''DRAW:''' The game ends in a tie for everyone.

*'''GIVE UNITS TO PLAYER:''' Gives an exact number of units owned by a specified player at a location to another specified player. (Ex.: Give 2 Terran Marine owned by player 1 at 'location 0' to player 2. This takes player 1’s two marines and makes them belong to player 2.) NOTE: The ‘All units’ checkbox starts out checked. Uncheck it to change the number of units that are given.

*'''KILL UNIT:''' Kills every unit of a certain type owned by the specified player, no matter where they are, or their properties. Yes, this even kills invincible units.

*'''KILL UNITS AT LOCATION:''' Kills an exact number of units owned by a player at a specified location. Like KILL UNIT, but with a sniper rifle.

*'''LEADER BOARD:''' There’s a lot of different types of leader board, but they all do the same thing, they show little colored boxes in the top left corner and a number, and that number is whatever it’s tracking. With a leader board, you can track:
**Units of a type owned at a location (CONTROL AT LOCATION)
**Units of a type owned (CONTROL)
**Minerals and gas (GREED)
**Kills of a unit type (KILLS)
**Points (POINTS)
**Minerals OR gas (RESOURCES)
Also, a leader board with a set goal can be made using LEADER BOARD GOAL. This is especially useful when you want the leader to be the one with the lowest number. To do that, set the goal as something low, like zero.

*'''LEADERBOARD COMPUTER PLAYERS:''' Changes whether or not computer players are shown on the leader board.

*'''MINIMAP PING:''' Makes a ping on the minimap (those little lines that form a square around something) at a location for the selected player.

*'''MODIFY UNIT:''' This action modifies the same numbers you can change if you use CREATE UNITS WITH PROPERTIES. These are hit points, energy, shields, hangar count, and resources. NOTE: CREATE UNIT WITH PROPERTIES is for making modified units, while MODIFY UNIT is for changing existing ones.

*'''CENTER LOCATION:''' This moves a location to a specific unit owned by the selected player. (Ex. Center location labeled 'location 0' on Jim Raynor (Marine) owned by player 1 at 'Anywhere'. This will move center Location 0 on player 1’s Jim Raynor.) NOTE: This doesn’t work very well if a player owns more than one of the type of unit you’re trying to center the location on. It can work, but you have to make sure that another unit of the same type of the one that you want to track NEVER enters the tracking location, or it might get mixed up and start tracking the wrong unit.

*'''MOVE UNITS:''' This teleports units owned by the selected player from one location to another.

*'''MUTE UNIT SPEECH:''' This silences all the sound except for .wavs you might be playing using PLAY WAV.

*'''ORDER:''' Tells all units of a type at a location belonging to the specified player to do something (move, patrol, or attack) to another location. (Ex. Issue order to all Terran Marine owned by player 1 at 'Location 0': Attack to 'Location 1'. All of player 1’s marines at location 0 will attack to location 1.)

*'''PAUSE GAME:''' Pauses the game for everyone.

*'''PAUSE TIMER:''' Pauses the countdown timer for everyone.

*'''PLAY WAV:''' Plays a selected .wav file for the selected player. A .wav file is a low-quality, old sound file that was popular when Starcraft came out. Before you can play a .wav in a map, you have to import it using Scenario > Sounds, or Ctrl + Shift + S. NOTE: Having just a few .wav files can really jack up your file size, therefore making the download longer. People don’t typically like long downloads, so be careful what you use!

*'''PRESERVE TRIGGER:''' Makes the trigger fire whenever the conditions are fulfilled. Be careful with these and always put a WAIT before them unless you want a constantly running trigger (which will really lag things down).

*'''REMOVE UNIT:''' Removes all of a player’s units of a certain type without killing them; more or less makes them disappear forever. Good if you need to get rid of a unit, but you have a trigger that will go off if you kill it.

*'''REMOVE UNITS AT LOCATION:''' Just like KILL UNITS AT LOCATION, but removing instead of killing.

*'''RUN AI SCRIPT:''' This is basically useless with just StarEdit. Ignore it.

*'''RUN AI SCRIPT AT LOCATION:''' This, however, is very useful. Enter Bunker and Enter Transport are fairly self-explanatory. Using the scripts labeled with a race and difficulty level at a location over a computer player’s base will make them use their units and buildings as if they were playing a melee. Using ‘Value this area higher’ will give a location priority to attack and keep. NOTE: If you're running an AI script at a CPU base to make it play like it's in a melee, make sure you match up the race with the race of the CPU (i.e. Zerg scripts won't work with a Terran player).

*'''SET:''' There are a lot of things that can be set using triggers. They are:
**Allying and Allied Victory (ALLIANCE STATUS)
**The amount of time on the countdown timer (COUNTDOWN TIMER)
**The death count of a unit for a player (DEATHS)
**Doodad state (DOODAD STATE)
**Invincibility of units at a location (INVINCIBILITY)
**Mission objectives, accessed through the main menu (MISSION OBJECTIVES)
**A map to start after the current one is completed, for if you’re making a custom campaign (NEXT SCENARIO)
**Amount of minerals or gas (RESOURCES)
**Amount of points of a type (POINTS)
**Switch status, set or cleared (SWITCH)

*'''TALKING PORTRAIT:''' This shows a portrait of a unit of your choice doing it’s talking animation for the amount of time you set. This is what was used in the campaigns’ in-game cutscenes.

*'''TRANSMISSION:''' This simply combines TALKING PORTRAIT, PLAY WAV, and DISPLAY TEXT MESSAGE into one.

*'''UNMUTE UNIT SPEECH:''' Undoes the MUTE UNIT SPEECH action

*'''UNPAUSE GAME:''' Undoes the PAUSE GAME action.

*'''UNPAUSE TIMER:''' Undoes the PAUSE TIMER action.

*'''VICTORY:''' The opposite of DEFEAT, makes the current player win.

*'''WAIT:''' Stops the trigger from carrying on to the next action for the amount of time set. NOTE: If making a map that uses a lot of waits that run around the same time, use [[Hyper Triggers]].

====A NOTE ON ACTIONS:====
Actions always fire in the order that you put them into a trigger, they don't all go off at once, so don't put a "Kill Units at Location" before a "Create Units" and expect the units you made to die. Also, the delay between the actions will be minimal unless you put in a Wait.

==See also==
*[[Triggers]]
**[[Triggers#Actions|Actions]]
*[[List of Trigger Conditions]]

[[Category:StarCraft]]
[[Category:Reference]]

Trigger

2015-08-03T02:57:54Z

Zurg: Redirected page to Triggers

#REDIRECT [[Triggers]]

Wait blocks

2015-08-03T02:56:24Z

Zurg:

Triggers

2015-08-03T02:54:17Z

Zurg: refresh links

A StarCraft '''trigger''' is a set of commands that are executed by the game when a [[Use Map Settings|UMS]] map is played. They consist of three main sections: The ''[[player]]s'' that own the trigger, the ''conditions'' under which the players run, and the ''actions'' the trigger will execute. A trigger will run for the specified players when ''all'' of its conditions are met. Its actions will be executed in order from top to bottom.

== Owners ==
Triggers can be set to run for specific players. These players "own" the triggers. Only Players 1 through 8 can own triggers, and the only valid player groups that can own triggers are [[Forces]] and All Players. Triggers for [[Player#Extended players|Players 9 through 11]], [[Player#Neutral|Neutral]], Allies, Foes, Current Player, etc., are ignored by ''StarCraft''.

When creating a ''StarCraft'' trigger, your map editor will present you with a list of all players and player groups (including, depending on the editor, those that cannot execute triggers). Each player and group will have a checkbox; the checked players own the trigger. If a Force owns a trigger, then the trigger is treated as though it were owned by the players in that Force. If All Players owns a trigger, then the trigger is treated as though it were owned by Players 1 through 8.

[[File:TriggerOwners.jpg]]

In the picture above, Force 1, Player 5 and Player 6 own this trigger. If Players 1, 2, and 3 are in Force 1, then it is equivalent to having a check mark for Players 1, 2, 3, 5, and 6 in this window.

== Conditions ==
Conditions are the criteria required for the trigger to run. A trigger will only execute if '''all''' conditions have been satisfied. ''StarCraft'' will read the conditions one at a time from top to bottom until it finds a false one. If the game finds a false condition, it will not execute that trigger (or even check the other conditions).

When creating maps with large amounts of triggers (>500), ordering the conditions correctly may help to reduce lag. Some conditions, like Bring, require much more processing power to check since ''StarCraft'' must read a lot of data to determine where [[unit]] are. Other conditions, like Deaths, are simply numerical comparisons and happen much quicker. When ordering a trigger, it is better to have Deaths conditions get checked first; if they return false and are positioned before more memory-intensive conditions, then ''StarCraft'' won't even bother checking the more "expensive" conditions. This, as you might expect, saves time and memory.

If all of the conditions of a trigger return true, then ''StarCraft'' will begin to execute the actions of that trigger.

*[[List of Trigger Conditions]]

== Actions ==
Once all the conditions for a trigger have been filled, the actions of a trigger will execute. These actions execute in order from top to bottom within the trigger, so be careful when the order of execution matters. If the trigger does not use the Preserve Trigger action, then it will only fire once for each viable player that owns it, as after firing in its respective [[Triggers#trigger cycles|trigger cycle]], it will be deleted from memory.

The Preserve Trigger action will work correctly no matter where its position is within the trigger actions.

*[[List of Trigger Actions]]

== Trigger lists ==
Every map contains a ''trigger list'' -- that is, an ordered list of its triggers. When playing the map, ''StarCraft'' reads the list and sorts the triggers by player before checking them. (Meaning that triggers owned by Player 1 will be checked first, followed by triggers owned by Player 2, and so on.) This, of course, means that the order the triggers appear in map editors is '''not''' the order they will be executed in. But you can view only one player at a time to see the order their triggers will fire in. You can also display all triggers owned by a playergroup, such as Forces and All Players.

To access a map's trigger list in [[SCMDraft 2]], either:
*Open Text Trigedit by going to '''Triggers > Trigger Editor'''.
*Open Classic Trigedit by going to '''Triggers > Classic Map Triggers''', and then select all players in the player selection box at the top of the window.

[[File:TriggerList1.jpg|alt=An image showing the menu sequence for opening Text Trigedit.]]

The text trigger editor looks like this:

[[File:SCMDraft 2 Text Trigedit.png]]

Text Trigedit shows every trigger in your map in the order that ''StarCraft'' will read them when the game begins. It is important to note that the triggers will execute in a different order, explained in the next section. The list is not necessarily sorted by player, but you can manually sort it. The utility explained here: http://www.staredit.net/topic/7694/ can help you sort your triggers by player.

== Trigger cycles ==
''StarCraft'' processes the trigger list every two game seconds (approximately 1.5 real-time seconds on the Fastest [[Game Speed|game speed]]), though some maps use triggers called [[Hyper Triggers|hyper triggers]] to shorten that time interval. This processing is called a ''trigger cycle''.

During a trigger cycle, only trigger actions happen -- nothing else occurs in the game. We cannot see the game stop, however, because a single trigger cycle can occur during the span of a few [[Wikipedia:Millisecond|milliseconds]]. This means that if you are, for example, trying to detect the presence of a unit in a given location, you do not have to worry about it exiting the location during a trigger cycle (and being missed by your trigger). It will only move if a trigger action moves it.

''StarCraft'' checks this trigger list in a very particular order. It starts at the top of the list and begins to search for Player 1 triggers. (This includes triggers owned by All Players and triggers owned by whichever Force contains Player 1.) When it finds one of these triggers, it checks the conditions for that trigger, and if the conditions are all true, it executes the trigger. Once ''StarCraft'' has reached the end of the trigger list, it returns to the top of the list and repeats the process for Players 2, 3, 4, 5, 6, 7, and 8. The trigger cycle ends when ''StarCraft'' finishes checking triggers for Player 8. Note that the game will not run triggers owned by players who have left (or were never in) the game. (Triggers owned by multiple players will still be checked, but not for any owners that are no longer present.)

Any use of "Current Player" in trigger actions or conditions is dependent upon which player ''StarCraft'' is currently running triggers for. When, for example, ''StarCraft'' is running Player 1 triggers, it will treat Current Player as Player 1. Also remember what has been said earlier: Triggers for Forces and All Players are split into their respective players so each of them owns a copy of the trigger.

Here is an example of a trigger cycle works.
*Start the trigger cycle by checking triggers for Player 1.
**Is trigger 1 owned by Player 1?
***If no, then ignore it.
***If yes, then is Player 1 in the game?
****If no, then ignore it.
****If yes, check if all conditions are true
*****If no, then ignore it.
*****If yes, run each of the trigger's actions in order and then move on to the next trigger..
**Is trigger 2 owned by Player 1?
***If no, then ignore it.
***If yes, then is Player 1 in the game?
****If no, then ignore it.
****If yes, check if all conditions are true
*****If no, then ignore it.
*****If yes, run each of the trigger's actions in order and then move on to the next trigger..
**''And so on.''
*All triggers have been checked for Player 1. Re-check them for Player 2.
**Is trigger 1 owned by Player 2?
***If no, then ignore it.
***If yes, then is Player 2 in the game?
****If no, then ignore it.
****If yes, check if all conditions are true
*****If no, then ignore it.
*****If yes, run each of the trigger's actions in order and then move on to the next trigger..
**''And so on. Run the checks again for Players 3 through 8.''
*All triggers have been checked for Player 8. End of trigger cycle.
Flowcharts can also be found [[:File:TriggerFlow1.jpg|here]] and [[:File:TriggerFlow2.jpg|here]].

==Common trigger-related bugs==
=== Why does my map spawn several Terran Marines for each player instead of just one? ===
When a trigger is owned by a Force, each player in the force will execute that trigger during their section of the trigger cycle, as long as the conditions are still valid. So your actions probably look something like this:

*Create 1 [[Terran Marine]] at Anywhere for Force 1.

When the trigger runs for Player 1, a Marine will be created for each member of the Force (if they are in the game). Furthermore, the trigger will run for each member of the Force. (So if Force 1 has three players in it, then all three players get three Terran Marines each, for a total of nine Marines.) The best way to fix this is by using Current Player:

*Create 1 Terran Marine at Anywhere for Current Player.

Now, the trigger will only create 1 Marine for each player that activates it.

=== Why does my map spawn Terran Marines even if that player is not in the game? And why do they attack me even though I allied them? ===
You have created a unit for a specific inactive player, but have it owned by another (active) player. Lets assume P8 is a computer in your map and P1-3 are members of Force 1 while Player 3 left the game. Then your trigger will look something like this:

{{StarCraft Trigger
|
*Player 8 (Computer)
|
*[any]
|
*Create 1 Terran Marine at Anywhere for Player 1.
*Create 1 Terran Marine at Anywhere for Player 2.
*Create 1 Terran Marine at Anywhere for Player 3.
}}

Since you specifically used Players 1-3, the game will create units for them even if they are not playing. The unit for P3 (not playing) will be given to a "ghost" player who is hostile to anyone, ignoring all AIs, including alliances. Use Current Player instead, so the players create the units for themselves; since absent players can't run triggers, the problem will be solved:

{{StarCraft Trigger
|
*Force 1 (P1-3)
|
*[any]
|
*Create 1 Terran Marine at Anywhere for Current Player.
}}

As you can see it makes the trigger shorter and you don't need the computer player anymore. But be careful as this can change the order in which the triggers are fired, since now the units are created in Player 1's (and P2-P3's respectively) section of the trigger cycle instead of P8 which fires his triggers last. So an alternative solution would be to create for the Force:

{{StarCraft Trigger
|
*Player 8 (Computer)
|
*[any]
|
*Create 1 Terran Marine at Anywhere for Force 1.
}}

''StarCraft'' automatically checks if players are present if you use Force x and skips it for inactive players.

=== Why does my map spawn one Terran Marine instead of multiple? ===
If a trigger is owned by a Force, each player in the force will execute that trigger separately during their section of the trigger cycle. So, if one of the actions of the trigger invalidates the conditions of the trigger, then when ''StarCraft'' checks the trigger's conditions for the next player in the Force, they will return false and the trigger will not execute for that player.

Let's use an example. Here is a trigger that might be used to create a Terran Marine for a member of Force 1 when they set a [[switch]].

{{StarCraft Trigger
|
*Force 1 (P1-3)
|
*Switch 1 is Set
|
*Create 1 Terran Marine at Anywhere for Current Player.
*Clear Switch 1.
}}

The problem is that when a member of Force 1 runs the trigger, it will be invalidated for the other members of Force 1 (because switches are global, and not specific to a player). It will not execute for them. The solution is to use a [[Death Counters|death counter]] owned by Current Player instead of a global switch. We would change the trigger to this (where "[unused unit]" is any unit that cannot normally appear on a map):

{{StarCraft Trigger
|
*Force 1 (P1-3)
|
*Current Player has suffered exactly 1 death of [unused unit].
|
*Create 1 Terran Marine at Anywhere for Current Player.
*Set deaths for Current Player: Set to 0 for [unused unit].
}}

Now, the trigger runs separately for each member of Force 1. To activate it, we set a player's death counter (for [unused unit]) to 1.

=== Bring condition update ===
The Bring condition may return false positives and false negatives in some cases. This is because ''StarCraft'' does not refresh location data during a trigger cycle. If a trigger invalidates that data, then it may cause false results to occur for triggers that use that data. We can force the data for a given location to update however, by using any of these trigger actions:

*Kill Unit
*Kill Unit at Location
*Remove Unit
*Remove Unit At Location
*Move Location
*Move Unit

[[Category:StarCraft]]
[[Category:Reference]]

Hyper Triggers

2015-08-03T02:52:08Z

Zurg: add categ ref

'''Hyper triggers''' (often shortened to "'''hypers'''") are ''StarCraft'' [[triggers]] that use game glitches to speed up the rate at which trigger cycles are executed. Under normal circumstances, triggers are checked every two game seconds; hyper triggers cause triggers to be checked every other frame of animation (about twelve times per real-time second on the fastest game speed).

== Basic hyper triggers ==
The basic hyper trigger method uses Wait actions. To avoid [[wait blocks]], the player that owns these triggers cannot own any other triggers that use Waits -- unless there is another player also running hyper triggers. Furthermore, these triggers must be placed at the bottom of the trigger list. This is for several reasons, firstly that (so long as you have at least two players running hyper triggers), one of them will be able to run a Wait action and the map hyper triggers will not pause (because there will be another player still properly running hyper triggers). If no computer players are available to run hyper triggers, hyper triggers must be included in the trigger lists of every player, thus ensuring that there will always be at least one set of hyper triggers running.

The following trigger is a hyper trigger. It is strongly recommended that you use multiple copies of it in your map; generally, about four of them will do.

If you wish to add a Comment action, simply remove one Wait action to make room for it. (The number of actions in the trigger should be sixty-four -- the maximum amount of actions a trigger can hold. So without a Comment, you should have 63 Waits; with a Comment, you should have 62. Do ''not'' forget the Preserve Trigger action.)

{{StarCraft Trigger
|description=A basic hyper trigger.
|players=*''[any player following the above recommendations]''
|conditions=*Always
|actions=
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Wait 0 milliseconds.
*Preserve trigger.
}}

Multiple copies of this trigger (at least four) are strongly recommended.

=== How it works ===
These hyper triggers cause ''StarCraft'' to check the map's trigger list about 11.904761904761904761904761904762 times per second. This happens because before a Wait action, ''StarCraft'' checks all trigger conditions in any trigger for any player. Thus, by stacking very short wait periods in a single trigger, ''StarCraft'' is forced to check all triggers many times per second.

The reason that multiple copies of the trigger are needed is because once ''StarCraft'' has finished running through all hyper triggers in a map (which does happen eventually), there will be a gap (known as an '''NEO''', or '''Next Ending Occurrence''') of approximately two seconds -- the normal cycle time. This gap can cause problems with timing. However, the more hyper triggers there are in a map, the longer the period between gaps will be, via the following formula:

(''x'' + 1)<sup>''n''</sup> * 0.084 = number of seconds until NEO

where ''x'' is the number of Wait actions in a hyper trigger, and ''n'' is the total number of separate hyper triggers in your map. Using the example of four copies with 63 wait actions in each:

(63 + 1)<sup>4</sup> * 0.084 seconds

(64)<sup>4</sup> * 0.084 seconds

16777216 * 0.084 seconds

1409286.144 seconds

Therefore, the time between NEOs will be approximately 391.5 hours, or about 16 days. All maps last considerably less time than this, and so this number of hyper triggers will be sufficient in all situations. Bear in mind, however, that there will be one NEO at the beginning of the map, which happens because ''StarCraft'' does not cycle triggers at the beginning of the game, instead waiting for a standard cycle period and then running through the trigger lists. As soon as the first cycle has been completed, however, you need not worry about NEOs.

== Complex Hyper Triggers ==
Complex hyper triggers are a rather ironically-named pair of triggers that are fairly easy to implement. They may be placed anywhere on the trigger list and do not cause wait blocks, making them more convenient than basic hypers. Furthermore, they rely on [[switch]]es or [[Death Counters|death counters]] (either may be used), so they can be activated or deactivated with ease. However, they are trickier to set up, because the two triggers must be assigned to two different players. As a note of trivia, complex hypers also have no NEOs.

Here are the triggers for complex hypers that use a switch. To convert them over to death counters, simply use the Deaths condition and Set Deaths action.

{{StarCraft Trigger
|description=Complex Hyper 1
|players=*Player 1 ''[can be any player, but the hypers must use different players]''
|conditions=*Switch 1 is Cleared.
|actions=
*Wait 0 milliseconds.
*Set Switch 1.
*Wait 0 milliseconds.
*Preserve trigger.
}}

{{StarCraft Trigger
|description=Complex Hyper 2
|players=*Player 2 ''[can be any player, but the hypers must use different players]''
|conditions=*Switch 1 is Set.
|actions=
*Wait 0 milliseconds.
*Clear Switch 1.
*Wait 0 milliseconds.
*Preserve trigger.
}}

== Nonzero waits ==
Should hyper triggers ever noticeably lag the map, the amount waited can be increased, which will delay each trigger cycle by an additional frame past multiples of 42 on fastest. On other speeds, there are different breakpoints for waits (faster is multiples of 48). Therefore, wait 0-42 will produce 2 frame hyper triggers, wait 43-84 will produce 3 frame hyper triggers, wait 85-126 will produce 4 frame hyper triggers, and so on. In practice, this has little use, as hypers should always be on wait 0 for speed. If you want any sort of delay, it's best to use [[death Counters]] as a timer. 3 frame hypers are peculiar, since they allow you to run triggers on frames which 2 frame hypers can't (ie frame 0, 3, 6, 9 vs frame 0, 2, 4, 6, 8). By utilizing complex hyper triggers, it is also possible to change the speed of hyper triggers from 2 or 3 frame on the fly.
[[Category:StarCraft]]
[[Category:Tutorials]]
[[Category:Reference]]

Hyper Triggers

2015-08-03T02:48:43Z

Zurg: complex hypers example had an error in it

Damage Order of Operations

2015-08-02T21:49:01Z

Zurg: Add more stuff about remainders in SC; lowest integer is .25, not .5.

To determine how much damage an attack will do to a unit, follow these steps.

#If the unit has shield HP, subtract shield armor upgrades from the damage.
#Apply the damage to the shield HP.
#If any damage remains, subtract the unit's armor from the damage.
#If the damage is Explosive or Concussive type, modify it based on the unit's size.
#Explosive damage deals 100% to large units, 75% to medium units, and 50% to small units.
#Concussive damage deals 25% to large units, 50% to medium units, and 100% to small units.
#Apply the remaining damage to the HP.

Remainder damage has some special rules and is calculated in the following way: The lowest integer of damage you can achieve in Starcraft is .25 HP, achieved from concussive damage under the right circumstances (an odd number after armour reductions on large units). This also happens to be the lowest increment of HP that Starcraft will count in: ie the base unit for HP is '''.25'''. The minimum damage in a single attack, however, is '''.5'''. Starcraft will display any remainder HP, even .25, as rounded up to 1 whole point.

=====Example 1:=====
Siege Tank (70 damage, explosive) attacks a Zealot (60 shields, 100 hit points, 1 armor)

#70 damage is reduced by 0. (No shield armor upgrades)
#60 shield points are removed from the zealot. 10 damage remains.
#10 damage is reduced by 1. (Zealot base armor)
#The damage is Explosive type and the Zealot is small. 9 damage becomes 4.5 damage.
#100 HP reduced to 96.5.

=====Example 2:=====
Hydralisk (10 damage, explosive) attacks a Matriarch (300 hit points, 3 armor, medium size)

#10 damage is reduced by 0. (No shield armor upgrades)
#0 shield points are removed from the Matriarch. 10 damage remains.
#10 damage is reduced by 3. (Matriarch base armor)
#The damage is Explosive type and the Matriarch is medium (75% damage). 7 damage becomes 5.25 damage.
#300 HP reduced to 294.75.

=====Example 3:=====
Ghost (10 damage, concussive) attacks a Siege Tank (150 hit points, 1 armor, large size)

#10 damage is reduced by 0. (No shield armor upgrades)
#0 shield points are removed from the Siege Tank. 10 damage remains.
#10 damage is reduced by 1. (Siege Tank base armor)
#The damage is Concussive type and the Siege Tank is large (25% damage). 9 damage becomes 2.25 damage.
#150 HP reduced to 147.75.

=====Spell Damage:=====
All spells except for Yamato Cannon and [[Nuke]] ignore unit armor. Yamato Cannon does 260 explosive damage to a single target. Plague also ignores Protoss shields and does damage directly to the unit or buildings HP. See the 3 spell pages for full details, including damage and duration, for all spells and abilities.

See also: [[Spells (Terran)]], [[Spells (Protoss)]], [[Spells (Zerg)]].

[[Category:StarCraft]]
[[Category:Reference]]

Switch

2015-08-02T08:23:43Z

Zurg: linking

A '''Switch''' is an on/off variable that can be found in "Set" or "Cleared" states. Switches are assigned values with [[List of Trigger Actions|actions]] and tested with [[List of Trigger Conditions|conditions]]. Switches may be given custom names which makes them use [[strings]]. There is a maximum of 256 switches that may be used in a [[map]]. Switches can be used to keep track of which triggers have been activated, to disable or enable certain triggers or to link multiple triggers together.

== Conditions ==
Condition text: <Switch name> is <switch state>.

Tests [[switch]] <switch name> against given [[switch|state]] <switch state>.

=== Editors syntax ===
Syntax in [[SCMDraft 2]]:
*Switch("Switch name", set/not set);

Syntax in [[StarForge]]:
*Switch(Switch name, Switch state);

== Actions ==
Action text: <Switch name> is <switch state>.

Tests [[switch]] <switch name> against given [[switch|state]] <switch state>.

=== Editors syntax ===
Syntax in [[SCMDraft 2]]:
*Switch("Switch name", set/not set);

Syntax in [[StarForge]]:
*Switch(Switch name, Switch state);

== See Also ==
*[[Map Limits]]

[[Category:StarCraft]]
[[Category:Reference]]

List of Trigger Conditions

2015-08-02T08:22:33Z

Zurg: remove categ conditions

Conditions are the things that have to happen for a trigger’s actions to start.

There’re a lot of conditions, and I’m going to go through all the ones available for basic StarEdit (there are better mapping programs out there, such as SCM Draft, for more advanced users), so if you’re looking for one specific condition, you might just want to <code>Ctrl + F</code> it in your internet browser. I have the variables for each example trigger underlined.
*'''ACCUMULATE:''' Causes the trigger to fire when the selected player gathers an amount of resources (''minerals and/or gas'') that you choose. (Ex. <u>Player 1</u> accumulates <u>at least</u> <u>50</u> <u>ore</u> --> Trigger fires when Player 1 passes the 50 mineral mark.)

*'''ALWAYS:''' This pretty much means there is no condition, it’ll happen ASAP. If you put ‘Always’ in a trigger with other conditions, it’s pointless. (Ex. Always --> Trigger fires.)

*'''BRING:''' Causes the trigger to fire when a certain unit, or group of units is brought to a location. (Ex. <U>Player 1</u> brings <u>at least</u> <u>2</u> <U>Terran Marine</u> to <U>‘Location 0’</u>.) NOTE: ‘Anywhere’ means anywhere on the map, not just any location (''technically ‘Anywhere’ is a location that spans the entire map, is precreated and exists on every map, and cannot be deleted''). Also, there are some units that '''bring''' doesn't work with, like [[map revealers]], and some that you might be surprised that it works on, like [[dark swarm]] (although you can't detect dark swarm with basic StarEdit).

*'''COMMAND:''' Causes the trigger to fire when the player owns the number of units specified. (Ex. <u>Player 1</u> commands <u>at least</u> <u>2</u> <U>Terran Marine</u> --> Trigger fires when player 1 has at least two marines somewhere on the map.)

*'''COMMAND THE LEAST:''' Causes the trigger to fire when the current player (that’s technical jargon for the player you first selected before going into conditions, ‘All Players’ in our case) is the player who owns the least of a type of unit (Ex. Current player commands the least <u>Terran Marine</u> --> Trigger fires when the current player has the least marines out of anyone else.) NOTE: If you try to use this condition with ‘All Players’ it won’t work how you want it to.

*'''COMMAND THE LEAST AT:''' The same as COMMAND THE LEAST, but more specific. This causes the trigger to fire if the current player has the least units at a certain location. (Ex. Current player commands the least <u>Terran Marine</u> at <u>‘Location 0’</u> --> Trigger fires when someone else has more marines in Location 0 than the current player.) NOTE: This also won’t work how you want it to if ‘All Players’ is selected.

*'''COMMAND THE MOST:''' The opposite of COMMAND THE LEAST. Causes the trigger to fire when the players owns more of a certain type of unit than anyone else. (Ex. Current player commands the most <u>Terran Marine</u> --> Trigger fires when the current player has more marines than anyone.) NOTE: See above note.

*'''COMMAND THE MOST AT:''' The opposite of COMMAND THE LEAST AT. I think you get the idea with these COMMAND conditions.

*'''COUNTDOWN TIMER:''' Causes the trigger to fire when the countdown timer (a little timer that you can make appear at the top of the screen with the SET COUNTDOWN TIMER action) reaches a certain amount of time left. (Ex. Countdown timer is <u>at least</u> <u>10</u> game seconds --> Trigger fires when there’s 10 game seconds left until the timer runs out.) NOTE: You can’t put in values like 1:12, instead you have to use the number of seconds, so 1:12 would be 72. Also, game seconds are different from real seconds (faster on Fastest), so if you think that your triggers are off, don’t get irritated, because they aren’t.

*'''DEATHS:''' Causes the trigger to fire when the player has lost X number of a type of unit. [[EUDs]] use this. (Ex. <u>Player 1</u> has suffered <u>at least</u> <u>2</u> deaths of <u>Terran Marine</u> --> Trigger fires when two of Player 1’s marines die.) NOTE: Deaths is one of the most useful conditions next to Bring, read Falkoner’s “[[Death Counts]]” tutorial to find out how to best utilize them.

*'''ELAPSED TIME:''' Causes the trigger to fire after X number of game seconds from the beginning of the game. Keep in mind that this is completely independent of COUNTDOWN TIMER. (Ex. Elapsed scenario time is <u>at least</u> <u>10</u> game seconds --> Trigger fires after the game has been going for 10 seconds.)

*'''HIGHEST SCORE:''' This condition is a bit confusing. You know the debriefing screen that shows up after your game that has the lists of points? Well, this relates to it. Causes the trigger to fire when the player has the highest amount of points of a certain type. (Ex. Current player has highest score <u>Kills and Razings</u> --> Trigger fires when the player has the most points from killing units and destroying buildings.)

*'''KILL:''' Causes a trigger to fire when a player kills X number of a certain type of unit. (Ex. <u>Player 1</u> kills <u>at least</u> <u>2</u> <U>Terran Marine</u> --> Trigger fires when player 1 has killed two or more marines.)

*'''LEAST KILLS:''' Causes the trigger to fire when the current player has killed the least of a certain type of unit. (Ex. Current player has least kills of <u>Terran Marine</u> --> Trigger fires when player is the most friendly to marines.)

*'''LOWEST RESOURCES:''' Causes the trigger to fire when the current player has the least minerals and/or gas. (Ex. Current player has least <u>minerals</u> --> Trigger fires when the player is the poorest on the map.)

*'''LOWEST SCORE:''' The opposite of HIGHEST SCORE. Causes the trigger to fire when the player has the least points. (Ex. Current player has lowest score <u>Units and Buildings</u> --> Trigger fires when current player has the least points from making buildings and training units.)

*'''MOST KILLS:''' The opposite of LEAST KILLS. Causes the trigger to fire when the current player has killed the most of a certain unit type. (Ex. Current player has most kills of <u>Terran Marine</u> --> Trigger fires when player has been the least kind to marines.)

*'''MOST RESOURCES:''' The opposite of LOWEST RESOURCES. I think you can take a guess at this one.

*'''NEVER:''' Causes the trigger to never fire. Ever. In case you’re wondering what the point of NEVER is, it’s good for testing when you want a certain trigger to not run, but you don’t want to delete the whole thing. (Ex. Never --> Trigger doesn’t fire.)

*'''OPPONENTS:''' Causes the trigger to fire when the selected player has a certain number of people unallied with them. (Ex. <u>Player 1</u> has <u>at least</u> <u>7</u> opponents remaining in the game --> Trigger fires when there are at least 7 players who aren’t allied with player 1, although it would be hard to get more than 7 opponents.)

*'''SCORE:''' Causes the trigger to fire when a player has a certain amount of points of a specified type. (Ex. <u>Player 1</u> <U>Kills</u> score is <u>at least</u> <U>9000</u> --> Trigger fires when player 1 has OVER NINE THOUUUSAAAAAND points from killing units.)

*'''SWITCH:''' Causes the trigger to fire when the selected switch is cleared or set (if you don’t know what a switch is, read Falkoner's tutorial on [[switch|switches]]). (Ex. <u>Switch 1</u> is <u>set</u> --> Trigger fires when switch 1 is in set status.)

====A NOTE ON CONDITIONS====
If you have multiple conditions in a trigger, the trigger will only fire if every condition is fulfilled, not just one. If you want something to happen from only one condition, but you want multiple things to set it off, make the trigger with one condition and use the ‘Copy’ button to make a copy of the trigger, and the ‘Modify’ button to change the condition of the new copy. This technique is useful for whenever you need to make a lot of very similar triggers.

==See also==
*[[Triggers]]
**[[Triggers#Conditions|Conditions]]
*[[List of Trigger Actions]]

[[Category:StarCraft]]
[[Category:Reference]]

Switch

2015-08-02T08:21:58Z

Zurg: remove trigger+action categs

A '''Switch''' is an on/off variable that can be found in "Set" or "Cleared" states. Switches are assigned values with actions and tested with conditions. Switches may be given custom names which makes them use [[strings]]. There is a maximum of 256 switches that may be used in a [[map]]. Switches can be used to keep track of which triggers have been activated, to disable or enable certain triggers or to link multiple triggers together.

== Conditions ==
Condition text: <Switch name> is <switch state>.

Tests [[switch]] <switch name> against given [[switch|state]] <switch state>.

=== Editors syntax ===
Syntax in [[SCMDraft 2]]:
*Switch("Switch name", set/not set);

Syntax in [[StarForge]]:
*Switch(Switch name, Switch state);

== Actions ==
Action text: <Switch name> is <switch state>.

Tests [[switch]] <switch name> against given [[switch|state]] <switch state>.

=== Editors syntax ===
Syntax in [[SCMDraft 2]]:
*Switch("Switch name", set/not set);

Syntax in [[StarForge]]:
*Switch(Switch name, Switch state);

== See Also ==
*[[Map Limits]]

[[Category:StarCraft]]
[[Category:Reference]]

Category:UMS

2015-08-02T08:19:01Z

Zurg:

Category UMS. All pages on the wiki to do with the UMS game mode. Incomplete.

Category:UMS

2015-08-02T08:18:05Z

Zurg: Created page with "Category UMS. Incomplete."

Category UMS. Incomplete.

Bring Condition Bug

2015-08-02T08:16:50Z

Zurg:

Although rare, there are cirumstances in which the "Bring" condition in Starcraft will return true when we know it to be false. Associated with each [[Locations|Location]] in Starcraft is a block of data, and unfortunately it does not always update correctly between triggers. The Location data will only update when certain [[Triggers|Trigger]] Actions fire, and at the beginning of a trigger cycle*. Here is a prime example of how this bug can occur:

*<span>*needs verification from someone who is 100% sure</span>

[[File:Location37.jpg]]

Trigger("Player 1"){
Conditions:
Always();
Actions:
Set Deaths("Current Player", "Terran SCV", Add, 1);
Preserve Trigger();
}

Trigger("Player 1"){
Conditions:
Deaths("Current Player", "Terran SCV", Exactly, 3);
Actions:
Kill Unit("Current Player", "Terran Marine");
Preserve Trigger();
}

Trigger("Player 1"){
Conditions:
Deaths("Current Player", "Terran SCV", Exactly, 3);
Bring("Current Player", "Terran Marine", "Location 37", At least, 1);
Actions:
Display Text Message(Always Display, "Whoa, this trigger thinks there is a Marine at Location 37!");
}

In the above example, the deaths of [[Terran SCV (StarCraft)|SCV]] are used to simulate whatever game event could be occuring where the bug happens, but has no actual effect on the bug. In these triggers, when the trigger cycle of exactly 3 SCV deaths (or whatever other event is in your map) comes around, the middle trigger kills all the [[Terran Marine (StarCraft)|marines]] on the map for Current Player. Then the next trigger, which fires immediately after the middle trigger, also fires, when we know it should '''not''' fire, since we know all the marines are already dead. This happens because the Location data did not update so StarCraft still thinks there is a Marine at Location 37.

This is not the only possible way for this bug to occur, but occurances of it are rare, which is one reason why it's such a frustrating bug. If it happens to you and you don't know about it, then you won't be able to find a logic error in your triggers.

Fortunately, we can force Starcraft to update the Location data for a given location between any two given triggers by using the actions Remove Unit at Location, Kill Unit at Location, Move Location, and Move Unit. The best action to use is "Remove 1 Map Revealer for Player at Location" because it will not actually remove a map revealer (they can only be removed by the Remove All Unit action) so the only effect it will have is to update the Location data.

[[Category:StarCraft]]
[[Category:Reference]]
[[Category:UMS]]

Category:Modding

2015-08-02T08:05:05Z

Zurg: Created page with "This is Category Modding. The following pages are all to do with modding StarCraft."

This is Category Modding. The following pages are all to do with modding StarCraft.

GRP Image Format

2015-08-02T04:40:48Z

Zurg: formatting, fix cat typo

*Byte = 8 bits
*Word = 2 bytes (Short)
*Long = 4 bytes
*All values are unsigned.<br/><br/>
==GRP File Layout==
*GRP Header
*Image Header * number of images
*Line Offsets * number of images * image height
*RLE Line * number of images * image height

===GRP Header===
Struct Size: 6 bytes
*Word - number of images
*Word - maximum width
*Word - maximum height
*Image Headers - one header for each image

===Image Header===
Struct Size: 8 bytes
*Byte - difference from maximum width (?)
*Byte - difference from maximum height (?)
*Byte - width (in pixels)
*Byte - height (in pixels)
*Long - offset to Line Offsets: the number of bytes from the beginning of the file to the offset for each line.

===Line Offsets===
Struct Size: 2 bytes * image height
*Word - offset to a RLE Line in bytes from the location of this Line Offsets.
*Word - another offset...
*Word - another...
*Word - another...
*...

===RLE Line===
*Byte - Instruction and length:
**if bit 7 is on, it indicates X number pixels are skipped aka transparency.
**if bit 6 is 1 indicates X number of pixels are "this" color. (RLE compression part)
**else X normal pixels should be copied over.

eh... i got lazy, sorry. :/

===Example Code===
struct definitions
struct grp_image_s
{
uint8_t x_offset;
uint8_t y_offset;
uint8_t width;
uint8_t height;
uint32_t offsets;
};

struct grp_header_s
{
uint16_t num_images;
uint16_t max_width;
uint16_t max_height;
};

struct color_s
{
uint8_t red;
uint8_t green;
uint8_t blue;
uint8_t alpha;
};

read the whole file into sprite_data
uint8_t sprite_data = new uint8_t[file_size_in_bytes];

allocate a color_s for each pixel (for just one image)
grp_header_s* gr_file_header = (grp_header_s*)sprite_data;
color_s* pixels = new color_s[grp_file_header->max_width *
grp_header->max_height ];

decoding algo
for (k = 0; k < num_images; ++k)
{
current_image = (grp_image_s*)(sprite_data + 6 + (k * sizeof(grp_image_s)));
line_offsets = (uint16_t*)(sprite_data + current_image->offsets);

image_width = current_image->width;
image_height = current_image->height;

memset(pixels, 0, grp_header->size_x * grp_header->size_y * sizeof(color_s));

for (y = 0; y < image_height; ++y)
{
line_data = (uint8_t*)line_offsets + line_offsets[y];
line_pixels = pixels + (image_width * y);
for (data_offset = x = 0; x < image_width;)
{
if (line_data[data_offset] & 0x80) // transparent
{x += line_data[data_offset++] & 0x7f;}
else if (line_data[data_offset] & 0x40) // data run
{
length = x + (line_data[data_offset++] & 0x3f);
rle_index = line_data[data_offset++];
while (x < length) {line_pixels[x++] = palette[rle_index];}
}
else // normal
{
for (length = x + line_data[data_offset++]; x < length;)
{line_pixels[x++] = palette[line_data[data_offset++]];}
}
}
}

COPY pixels TO ANOTHER PLACE
}

[[Category:StarCraft]]
[[Category:Reference]]
[[Category:Modding]]

Category:Terrain

2015-08-02T02:33:51Z

Zurg: Created page with "Category Terrain. Deals with everything to do with terraining in StarCraft."

Category Terrain. Deals with everything to do with [[terraining]] in StarCraft.

Category:Melee

2015-08-02T02:31:44Z

Zurg:

This category contains everything to do with mapmaking for the [[Melee]] mode of StarCraft. In common usage, this also includes the very similar [[FFA]] and [[Top vs Bottom]] modes.

Category:Melee

2015-08-02T02:30:33Z

Zurg: Created page with "This category contains everything to do with mapmaking for the Melee mode of StarCraft. In common usage, this also includes the very similar FFA and Top vs Botto..."

This category contains everything to do with mapmaking for the [[Melee]] mode of [[StarCraft]]. In common usage, this also includes the very similar [[FFA]] and [[Top vs Bottom]] modes.

Category:Mapmaking Tips

2015-08-02T02:06:07Z

Zurg: Created page with "This category contains pages of advice from fellow mapmakers on the various nuances and aspects of mapping."

This category contains pages of advice from fellow mapmakers on the various nuances and aspects of mapping.

Main Page

2015-08-01T02:09:54Z

Zurg: Sprucing up the front page a bit

<center><i><p style=font-family:Georgia;font-size:18pt>Welcome to the Staredit Network Wiki</p></i></center>
Staredit Network Wiki is a collaborative project at creating a comprehensive knowledge base for [http://en.wikipedia.org/wiki/StarCraft StarCraft] and [http://en.wikipedia.org/wiki/StarCraft:_Brood_War StarCraft: Brood War] map making and mod making with the emphasis on the description of fundamental game mechanics and common map making methods and practices. This wiki is supported by Staredit Network (SEN) community, feel free to visit our [http://www.staredit.net website.]

<center>
{| border="0" cellpadding="5" cellspacing="0" align="center" style="width: 62%"
! style="width: 30%" | <font size=4>[[:Category:Reference|Reference]]</font>
! style="width: 2%" |
! style="width: 30%" | <font size=4>[[:Category:Tutorials|Tutorials]]</font>
|- valign="top"
| align="center" | This category contains subcategories and pages describing either the behavior of the StarCraft engine or it's building bricks, these articles answer questions "How it works?" or "What happens?" and contain only reference and descriptive information
|
| align="center" | This category contains articles describing StarCraft common map making practices, techniques and concepts, they answer questions "How is it done?". Tutorials are a step by step descriptions explaining how to achieve a certain goal.
|}

{| border="0" cellpadding="5" cellspacing="0" align="center" style="width: 62%"
! style="width: 30%" | <font size=4>[[:Category:Mapmaking_Tips|Mapmaking Tips]]</font>
! style="width: 2%" |
! style="width: 30%" | <font size=4>[[:Category:StarCraft|Complete List of Articles]]</font>
|- valign="top"
| align="center" | These are your basic tips to help with map-making and working with the editor.
|
| align="center" | This is a list of all the articles on this wiki. Some may still be incomplete or outdated as things change with the editor or game, so if you find something that needs to be updated, by all means update it.
|}
</center>