Maximum Number of Units on a Map: 1700
Trying to create more units than this will result in the unit not being placed, and an error of the
"WARNING: UNIT UNPLACABLE (xxxx,yyyy)" type in-game. This could interfere with burning building virtual-timers and other
similar map systems.
Start Locations do not count towards the unit max.

Maximum Number of Sprites on a Map: 500.

Maximum Number of Locations: 255
Technically, there are 256, but if you make all 255 locations with SCMDraft you'll notice it skips
from "Location 62" to "Location 64". "Location 63" is the "Anywhere" location. In the original release of
Starcraft, the location limit was 64, and location 63, being the 64th location (Location 0 counts) became the
"Anywhere" location.

Maximum Number of Strings in a map: See below
Strings are made up of characters, and each character takes 1 byte. There is a limit of 65535 bytes set aside, and to make a string
you need to add 3 extra bytes to the total number of characters (a 2 byte offset a 1 byte null terminator. As Falkoner once said:

Quote from Falkoner

Yes, a null(empty) string takes up 3 bytes, any additional characters add a byte, so the string "Fat chicks" would take up 2(offset) 10(characters 1(null terminator), 13 bytes out of your maximum of 65535.

Max Amount of Triggers: Unknown.
In the most recent version of SCMDraft, somewhere between 90 and 120k triggers are supported. There is no known limit for Starcraft itself however, except perhaps physical memory restrictions.

In the Jungle tileset, with the "low ground" box checked, units on jungle, ruins, and raised jungle will be detected.
"low air" corresponds to an air unit above "low ground"

"Medium ground" is high dirt, high jungle, high ruins, and high raised jungle, or regular temple.
"Medium air" corresponds to air units above "medium ground"

"High ground" is high temple, or temple on high dirt, and nothing else.
"High air" corresponds to air units above "high ground."

http://www.staredit.net/starcraft/Terrain_Height

A unit is registered as inside a location if any part of the unit is right of the location's left border, left of the right border, below the top border and above the bottom border. Under normal circumstances, of course, this creates a rectangular area that units can enter.

Inverted locations are locations that have any borders that have been flipped (you can do this in Scmdraft by manually setting the location parameters in the location's properties window) . The same principle given before applies in this situation- if the left and right borders are inverted (the right border is left of the left border) a unit still needs to be right of the location's left border and left of the right border- in other words, the unit's 'area' must be outside both the left and the right borders and within the top and bottom. For a location with both the top and bottom and left and right borders inverted a unit must be outside all four sides of the rectangle to be 'inside' it.

The advantage of using inverted locations is that they can be used to detect if a unit is in an exact position (if fitted to that specific unit) and thus can be deployed for near instant unit movement detection. Other uses include varying degrees of unit movement.

In this normal (not inverted) location, the Goliath is inside the location


In this horizontally inverted location (left and right borders are flipped) the red Ultralisk is 'inside'
the location because it is outside both the left and right borders. The blue Ultralisk is not inside.


In this inverted location (all borders are flipped) the Ultralisk is inside the location because it is outside
all four borders (above the bottom border, left of the right, right of the left, and below the top border)


Inverted Locations wiki article

A Wait:

Code

This action will prevent the rest of the trigger (the actions below it in the list) from running until 1000 milliseconds have elapsed.
The wait will elapse in the same amount of time, regardless of game speed (typically not a problem as usually only "Fastest" is played
on battle.net)
Only 1 Wait( ); action may occur at any time per player. This is where Wait Blocks occur.
If we have two triggers where the
Wait(1000); occurs, the second Wait cannot execute until the first finishes.
So if we have two triggers:

Code

The second Wait will have to wait for 5000 ms until it can begin its own 7000ms wait, and it will take 12000ms total for these two Waits
to finish.

Hyper Triggers:

Code

Player X must be in the game, or the Hyper triggers will not work. It's typically easiest to have Player X be a computer player with no other waits, lest
wait blocks be encountered.

I personally find it easiest to have Player 8 (a computer player) have the Hyper Triggers at the bottom of his trigger list, just for good measure.

Wait() actions will only work in intervals of 84 milliseconds. That is to say, Wait(0) is the same as Wait(84), and Wait(85) is the same as Wait(168). This is due to
the minimum time between checking triggers, which is 84 milliseconds, or 2 frames.

The wiki article:
http://www.staredit.net/starcraft/Wait_Blocks

A Death Counter is a integer variable used in many maps to store numerical information. Each unit type has its own death counter, and each player has his own deathcounters for each unit type, so a Player 1 Terran Marine death counter is not necessairly the same as Player 2 Terran Marine death counter. A death counter stores the number of deaths of a certain unit type each player has suffered (kills via triggers do not count). So each time a Player 1 Terran Marine dies, the corresponding deathcounter is increased by 1.

Death counters can act as conditions for triggers. One can make a condition such as "Player 2 has suffered at least 5 deaths of Terran Marine", which will be true every trigger loop when the death counter of Player 2 Terran Marine is greater than or equal to 5.

As well as being used in conditions, death counters can be modified by trigger actions, like so: "Modify death counts for Player 1: set to 5 deaths of Terran Marine". This will make the Player 1 Terran Marine deathcounter equal to 5, disregarding the amount of deaths of Player 1 Terran Marines. As well as setting death counters to a specific value, one can add or subtract from the values by using "add" or "subtract" instead of "set" in the given trigger action. This crucial aspect allows death counters to be used as variables. It is important that if you decide to use some death counter as a variable, you must make sure that the corresponding unit does not die anywhere on the map, because that will add 1 to the deathcounter and edit the information it holds.

Here is a simple diagram explaining Death Counters:


In this case, "Player 1 has suffered exactly 12 deaths of Marine" will be a true condition, and so will "Player 3 has suffered at least 2 deaths of Ghost"

The simplest example of death counter application is a revival system for a hero in an RPG. The simplest trigger would look something like this:

Code

In the given case, gas represents the amount of revives the player has. Every time the player's Terran Marine (hero) dies, the corresponding death counter is set to 1. Hence, if the player has atleast one revive, a new marine is created at the "hero_revive" location, one gas is subtracted, the Terran Marine death counter is subtracted, the player's screen is centered on the hero and a "You have been revived!" messge is displayed.

Using Forces in death counts takes the sum of all players deaths in that force.

Say we want to do something like "Force 1 has suffered at least 5 deaths of Unit Y", and Players 1,2,3, 4 and 5 are in force 1.
There are multiple ways to fulfill this condition, Player 1 could have 5 or more deaths of Unit Y, Player 2 could have 2 deaths and player 3 could have 3 deaths, or each player (1,2,3,4,5) could each have 1 death, or any other assortment of ways so that the sum of deaths for all players in the force for Unit Y is at least 5.

Since not every unit is used in every game, death counters can also make very good timers, which is critical to avoiding wait blocks.

Some Useful Death Counter Articles:
http://www.staredit.net/starcraft/Death_Counters
http://www.staredit.net/starcraft/Counter_Arithmetic

There are 256 switches that can be used in a map. Each one is like a light switch, it can be "On" or "Off", or in SCMDraft terminology,
"Set" or "Cleared". These don't actually affect anything in the game, but are useful because they are global, and can save you some death counts.
By global, I mean that if Player 2's trigger "Sets" Switch 1, and Player 3's trigger depends on Switch 1 being set, it works out fine, whereas if you had
an action like "Set deaths for Current Player to 1 for Unit Z" in Player 2's triggers, it won't add a death count for Player 3.

Switches are also useful for Randomization:
You can randomize a switch, meaning it will randomly be "Set" or "Cleared" and this gives you two possibilities. By randomizing more than one switch,
you can have 2 ^ (number of randomized switches) possibilities. For example, with 2 randomized switches, these are the possible cases:

Switch 1: Set
Switch 2: Clear

Switch 1: Set
Switch 2: Set

Switch 1: Clear
Switch 2: Clear

Switch 1: Clear
Switch 2: Set

Some Useful Switches Articles:
http://www.staredit.net/starcraft/Switch
http://www.staredit.net/starcraft/Randomization

For a player to be able to burrow, he must have the ability researched or enabled.


If it is disabled, a player can still control a burrowed unit but will be unable to unburrow it, even if it's a lurker, by first creating it burrowed for a player with burrow enabled, then giving the unit to the player who has it disabled.

Quote from payne

a computer will always be able to unburrow even if he doesn't have the burrow ability researched.

Burrow Detection:
http://www.staredit.net/starcraft/Burrow_Detection

You can change the maxiumum number of upgrades as high as 255, in this screen:



Upgrades Article:
http://www.staredit.net/starcraft/Upgrades

Unfortunately, even nowadays maps lag. The most common perpetrators of map lag are actions which modify units in some way, namely,
Kill Units
Move Units
Give Units
Order Units

Other actions still contribute to lag, and having a great deal of triggers which run every trigger cycle by nature of the "Preserve Trigger" action
will contribute as well.

Spamming AI scripts has also been known to cause lag, and large numbers of units moving will contribute to lag, due to the necessary memory and processing requirements for pathfinding.

When checking the conditions of triggers Starcraft reads from top to bottom. When one of these returns false, it discontinues. Lag created by excessive condition scanning can be partially diverted by putting the conditions most likely to return false at the top of the condition list, limiting the number of conditions that need to be checked.

http://classic.battle.net/scc/faq/aiscripts.shtml
Starcraft comes with a number of useful AI Scripts. To use an AI Script, the script must be run by the player whose units you wish
to affect, for example: If you want Player 2's men to enter a dropship, Player 2's trigger must run the AI Script.

How to Use AI Scripts to Nuke:
--Nuking Link: We don't have an article to link yet!!!


Another action which isn't exactly an AI Script, is the "Order" action. The "Order" action doesn't have to be run by the player
whose units you wish to affect, for example: Player 1's trigger could order Player 2's Marine to walk across the map.
"Move" will make the unit walk there without attacking anything (unless perhaps it is blocked along the way)
"Attack" will make the unit walk to its destination and only attack if it is attacked first
"Patrol" will make the unit walk to its destination, actively seeking enemies along the way to engage, then walk back and forth between
its destination and the place where it was given the patrol order (still seeking enemies along the way)

Players 9, 10, 11, and 12 are extraneous neutral players that can be used for many capacities but have many limiting attributes (Player 12 is listed as 'Neutral' in Scmdraft). Players 9 though 12 cannot own triggers, and hence cannot run AI scripts, disabling the ability to set alliance or vision statuses. If provoked player 9-11 units will follow the assailant but not attack it- this is because they do not have vision (and cannot be given it by any means), not even for their own units which makes them unable to attack. You can read Player 9-12 death counters but you cannot set them by actions (adding to their death counters must be done manually by killing their units) effectively eliminating use of their deaths as a dynamic variable.

While players 9-11 act as hostile computers without vision, player 12 is neutral. When any player leaves the game their units are automatically given to player 12. Similarly, all dark swarms and disruption webs are cast automatically owned by Player 12, no matter the player that cast it; this is why it is impossible to know which player cast them unless only one player could have (IE only one player has the ability to cast it, or only one player has a defiler/corsair within range to cast it). Abandoned addons are automatically given to player 12 and resources are owned by player 12.

Perhaps the most intriguing aspect of player 12 is that players retain alliance statuses with units given to player 12. If player 1 is unallied with player 2 and a player 2 unit is given to player 12 unit, player 1 will still be unallied with that unit, despite his alliance status with player 12. If player 1 then allies player 2, player 1 will then be allied with all player 12 units that were given from player 2. Setting alliance status with player 12 only effects the player's alliance status with preplaced player 12 units and the color of the selection ring (yellow vs red) around player 12 units.

Players 9-12 can not have units created owned by them, but can be given units (even immediately after creation by different player) and can have preplaced units. Units given to player 12 also retain their colors (however, this is not reflected on the minimap). Players 9-12 do not need start locations, cannot be set to human open slots, cannot have player color set and cannot be seen in the game lobby.

To alter a player's vision statuses, we can use "Run AI Script" action "Turn ON/OFF Shared Vision for Player X". The action may operate opposite of how you might imagine, however- turning ON/OFF vision with a player does not change the trigger owner's status with that player, but rather turns on or off that player's shared vision with you, the trigger owner.

For instance, if one wanted to give Player 2's vision to Player 1, we would Run the Ai Script "Turn ON Shared Vision for Player 2" in a trigger owned by player 1. After this trigger owned by P1 runs, he will be able to see all of Player 2's units, and cloaked units owned by Player 2. One should note, however, that it takes a moment for this change to be taken into effect.

Another application and possibility of changing vision statuses is to turn OFF shared vision with the player that owns the trigger. IE Player 1 would run the action 'Execute AI Script 'Turn OFF Shared Vision for Player 1'. This would remove Player 1's ability to receive vision from his own units. If, however, his units are visible to him (by being within vision of a player he receives vision from) the units will always be detected for him. For example, Player 1 could not own a Dark Templar and see the area its in but have it be cloaked. Either P1 can not see the whole area, or he can see the area AND his own cloaked units.

Scarabs can be put to a number of good uses. They cannot simply be created, but you can "harvest" them then issue them orders. To order a scarab,
the shooting reaver must be owned by a computer player, then you can use the AI Scripts "Set Generic Command Target", which allocates the patrol destination,
and "Make these Units Patrol" at the location where the scarab is.

To harvest the scarab, the basic idea is to have a setup where a reaver shoots at an enemy target, but its path is blocked or the scarab is moved away too
quickly.

Here's a good Article on Scarabs:
http://www.staredit.net/starcraft/Direct_Damage_System_(DDS)

To have scarabs attack like in certain rpg "spells", you need to harvest the scarab and move it to a location, and the owner of the reaver must be enemies with
the player you are trying to attack, then run the AI Script "Junkyard Dog" at the scarab.

Quote from JaFF

The location you run JunkYard Dog at must be as small as possible, because the scarabs tend to attack targets that are outside the location.

Or, you can harvest a Human player's own scarab, wait for at least 1 trigger cycle, then move it to its target destination. Once at the target destination, use the "Move Unit" action to attempt to move the scarab to an
unwalkable location, like a location over water, or a location on a cliff face (anywhere a marine cant walk to), and it will detonate, dealing damage.

One major problem with starcraft, is there is no way to modify the number of kills a player has, only deaths. This often becomes a problem
when trying to create a money/experience system for a map. Fortunately, there are some work arounds, as provided in these links:

The following article is titled "Kills to Cash", but you can modify it easily to "Kills to EXP" or any other bonus for a map you might need in return for kills:
http://www.staredit.net/starcraft/Kills_To_Cash

http://www.staredit.net/starcraft/Triggers

Many people are confused as to how they can save their text triggers in SCMDraft. Currently, File -> Save does not work. Instead, we use the
compile button, as shown below:

After hitting the compile button, you should get an "Error" message like the following:

If you get any other error message, your text triggers are not formatted correctly and they didn't save correctly.


Text Triggers are a useful way of dealing with triggers, and some of the useful tools for creating them are linked below:
Link to Notepad : http://notepad-plus.sourceforge.net/uk/site.htm

Link to Trigger Sorter: Trigger Sorter

Link to Macrotriggers: MacroTriggers production thread

Link to Ruby Wrappers: Ruby Wrappers for Trigedit generation

To cloak a beacon, two things are required.
Use the action "Disable Doodad State" on the beacon.
This action alone however, will make the beacon visible but unclickable, to cloak it completely and make it glowy, you need to
either give vision to the player owning the beacon for a short time, or cloak it near a detector.

Cloaking other units is explained here:
http://www.staredit.net/starcraft/Cloaking_(Disabling)_2

This article explains how to make invisible bunkers that you can walk over top of but can still shoot:
http://www.staredit.net/starcraft/Invisible_and_Removed_(but_shooting)_Bunkers

This article has... more information:
http://www.staredit.net/starcraft/Invisible_Bunkers

One good trick to know, wherever you place the start location is the area that the player in-game first sees, also if they hit F4
it will center their view on the start location.

Players without start locations will not be present in your game, even if you placed 100 other units for them.

In the Forces menu, if you have "randomized start location" checked, a player might not always be the color you want.
(Need to do more testing with that)

Each unique set of unit properties in the "Create units with properties" trigger action takes up one CUWP slot. There are 64 CUWP slots in total. This means that one can have an unlimited amount of identical CUWPs in the triggers' actions, but only 64 unique ones.

Map revealers can be pre-placed or created. The strange thing about them however, is that they do not exist in any location.

The action "Center Location X on Map Revealer owned by Player Y at Location Z" will not center Location X on a map revealer, it will
center Location X on the center of Location Z. This can be a useful little trick for manipulating locations, or an annoying bug since
its hard to figure out why your location isn't going on the map revealer for apparently no reason.

Map revealers can not be removed or killed with the "Remove units at location" or "Kill units at location", but they can be removed by the
"Remove Unit" or "Kill Unit" action, since they are not location-dependant. This will remove all map revealers for a player.
Map revealers also cannot be given to another player once created.

Just a quick personal note: COMPRESS YOUR MUSIC BEFORE PUTTING IT IN A MAP! NO ONE LIKES 12 HOUR DOWNLOADS!

Once a you play a sound, it can not be stopped.

More than one sound may be played at any given time.

It is recommended to use death count timers and hyper triggers to loop music correctly, and to really get a good loop
is just a matter of trial-and-error.

Here is a useful WAV article:
http://www.staredit.net/starcraft/Wav_Files

Audacity is a free program which you can use to compress your music. Starcraft only plays Mono, so you can take a stereo track
and make it a Mono track right off the bat, cutting down a lot of filesize, and you can also reduce the bitrate to make the file smaller.
Audacity can also do some cool things like making your music louder or quieter, faster, ect.
Audacity Link:
http://audacity.sourceforge.net/

Please refer to the wiki articles:
Protoss Spells
Terran Spells
Zerg Spells