Units (Types)

A unit is any object in the game that can be controlled or selected at any point in time. Units include anything from Terran Marines to Protoss Pylons to Vespene Geysers and even the Installation tileset's various traps. Some units, such as Installation's Doors and the Defiler's Dark Swarm, cannot be controlled or selected.

Units are the most common element used and referenced in mapping. All maps rely very heavily on units. Also, because they are virtually the only thing that the players can control during the game, they are one of the few [wiki=Selection Systems]input devices[/wikil] available for use in advanced maps.

There are four basic types of units (aside from the technical classifications that shall be covered below). Buildings are (usually) immobile units that are (usually) constructed by worker units. (There are exceptions to both criteria; Terran buildings can lift off and become mobile, and a Zerg Nydus Canal can build another Zerg Nydus Canal to serve as its exit.) Men (the kind of unit most commonly meant when referring to units at all) are mobile units, and are usually capable of attacking. (There are exceptions here as well; Terran Siege Tanks (Siege Mode) are among several men that cannot move, and Terran Civilians cannot attack.) Unused units are unfinished or beta units, such as the Independent Starport. (Many of these crash the map.) Doodad units are units that typically appear in the form of Unit Sprites attached to doodads.

Extended Unit

Any unit whose ID is above the normal range (0-227, see the list below) is an Extended Unit. Such units tend to have very strange properties which can change when the game is patched. This is because these technically are not units; they are other types of data that the game is being coerced into interpreting as unit data. (Unit IDs can go up to 65535 due to binary-related restrictions on the size of computer variables, but Blizzard did not actually reserve space for 65535 units, as there are only 228 in the game!)

The vast majority of extended Unit IDs will produce units that either do nothing (disappear at the start of the game) or crash the game. (Some can even crash map editors that use the game's resource files, such as SCMDraft 2.) It is possible, however, for an extended unit to have useful properties. In a previous patch, an extended unit was discovered that enabled units to shoot much further than they normally could (up to 140 tiles away).

Unit Sprite

Unit Sprites are one of the two types of sprites supported by the StarCraft engine. Unit sprites appear to have been intended for use as a mechanism for attaching units to doodads. They therefore possess several behaviors that are useful for that purpose. Several Installation doodads, including the doors and traps, incorporate unit sprites to give doodads (which are ordinarily just terrain) unit-like behaviors. Third-party editors allow mappers to place unit sprites without an associated doodad.

These units have different properties than regular units.

• All sprite units will start with their current HP at the default of that unit. Example: Firebats will start at 50 current HP.
  
  • Max HP will be whatever it was set to in the map editor.
    
  • Using this, it is possible to create a Firebat that has 50/10 HP. This will result in the unit having a wireframe glow, as if they had Protoss shields.
    
• Normal units can have negative Max HP values with no problems, but if you click on a sprite unit that has negative Max HP, the game will crash.
  
• Some unit sprites become non-solid when disabled. (This is used for Installation's floor traps and doors.)
  
• Pre-placed sprite units appear in the game regardless of whether the Player player who owns them is in the game or not. (This is used so that non-rescuable floor traps that are hostile to all players can be placed without having to allocate an additional slot, add a Start Location, etc..)
  

Units with negative HP

Third-party map editors allow mappers to set a uint's Max HP to a zero or negative value. Units with negative Max HP are killed in one hit. Units with zero max HP aren't damaged by attacks.
Some spells do not work on units with negative HP. Among them are:

• Plague
  
• Heal
  

Hallucination

Units that have the hallucinated property appear solid blue to the player who owns them. They take double damage from attacks and are killed instantly by spells. They have energy that rapidly counts down to zero; when it runs out, the unit dies. When they are killed or die from losing their energy, they turn into a little blue cloud animation and disappear. Finally, they can attack, but they deal no damage.

Conditions cannot detect them, but Actions can be used on them. It is possibly to detect a hallucinated unit based on an action. For example, you can move a location to one, and detect if the location has moved and where it has moved to. Note that the energy of hallucinated units and Broodlings cannot be set with the Modify Unit Energy action, so their lifespan cannot be prolonged.

Third-party map editors allow the creation of pre-placed hallucinated buildings. Some hallucinated buildings will still function to some degree before they run out of energy and disappear.

Powerups

Powerups are immobile units that can be picked up and carried by worker units (SCVs, Probes, and Drones). Triggers can create powerups in areas that are occupied by other units (but not buildings or other powerups). When a powerup is on a ground unit, that unit will try to move off of it, except in the case of immobile units such as a Siege Tank or Door. (The same happens when any two mobile units occupy the same space.)

Normal powerups

The standard powerups that are available to map makers are:

• Data Disc
  
• Psi Emitter
  
• Young Chrysalis
  
• Khaydarin Crystal
  
• Uraj Crystal
  
• Khalis Crystal
  
• Flag
  

All of the normal powerups are invincible.

Extra powerups

The standard Campaign Editor cannot place the extra powerups. Only third-party map editors can add them. They also cannot be created with triggers. They are not invincible by default; they take .5 damage from all attacks.

• Mineral Chunk (Type 1)
  
• Mineral Chunk (Type 2)
  
• Vespene Orb (Protoss Type 1)
  
• Vespene Orb (Protoss Type 2)
  
• Vespene Sac (Zerg Type 1)
  
• Vespene Sac (Zerg Type 2)
  
• Vespene Tank (Terran Type 1)
  
• Vespene Tank (Terran Type 2)
  

Stats

These unit stats cannot be edited in a normal map. For the default unit stats such as mineral and gas cost, build time, damage, HP, etc., just check in your map editor.

UnitIDs

Each type of unit has a number associated with it. This number is called a UnitID. UnitIDs determine what a unit is. What we think of as a "Terran Marine", StarCraft thinks of as a unit whose UnitID is 0.

Code

Attack Speeds

Code

Kill Score

Code

Unit Spells

This information should all be transferred to the three pages on Spells (if it isn't already there). This should then link to those pages.

Code

External Links

http://en.wikibooks.org/wiki/StarCraft:Units

Hyper Triggers

Hyper triggers are triggers that utilize Wait actions to speed up the check rate of triggers at up to 8.0 times per "game-time" second, or 11.9 times in real-time seconds (fastest game speed with wait(0); actions).
Normally the trigger cycle only occurs once every two seconds, but when a Wait action "waits" the trigger cycle repeats prematurely. A hyper trigger is simply a collection of waits that are constantly activating, making the trigger cycle occur as fast as Starcraft will allow, or however fast the mapmaker chooses.

Common Hyper

The most commonly used method of creating hyper triggers only requires one player without other wait triggers. Note, however, that there is a disadvantage to having waits constantly being activated. A player can only have one Wait action waiting at any given time, so hypers can cause extreme wait blocks.

The player who the hyper triggers are assigned to will not be able to reliably use any other Wait actions. For this reason it is highly recommended that hyper triggers not be set to All Players or any of the Forces, as these options simply copy the trigger over to multiple players.

In order to bypass the restriction of not being able to use waits, death counters-- as a timer-- are often used in their place.

Another possible problem with this form of hyper trigger is the next ending occurence, or "NEO" for short, which is a moment where the hyper triggers lapse, and the normal 2 second cooldown between trigger cycles occurs. This can be mostly avoided by adding extra copies of the hyper trigger. NEO is explained below. To avoid a quick NEO there only needs to be three copies of the hyper trigger, any more is simply a waste of space.

Hyper triggers are usually made like this:

Quote

Players:
(A player that doesn't use any other waits. Avoid using the Forces or All Players.)

Conditions:
Always.

Actions:
Preserve trigger
Comment. "Hyper Trigger"
Wait 0 milliseconds
Wait 0 milliseconds
Wait 0 milliseconds
Wait 0 milliseconds
Wait 0 milliseconds
(Fill the action list with waits)

Switch Hypers

This method of hyper triggers does not have a NEO. It is not quite as simple, however, and it requires an additional player with no other wait triggers. This method will also never cause wait blocks. At the most this method will add a fifth of a second to the wait, although while the wait occurs the hyper triggers will turn off, this method also gives the ability to turn the hyper triggers on and off without having to wait for them to turn off.

Quote

Players:
(Player "X")

Conditions:
Switch 1 is set.

Actions:
Preserve trigger.
Comment. "Clear"
Wait 0 milliseconds.
Clear Switch 1.

Quote

Players:
(Player "Z")

Conditions:
Always

Actions:
Preserve trigger.
Comment. "Set"
Wait 0 milliseconds.
Set Switch 1.
Wait 0 milliseconds.

Calculating the NEO

The frequency of the NEO (in seconds) can be calculated by finding the power (number of copies of the hyper triggers) of the number of wait conditions in a single hyper trigger plus one, then by finding the product of the result and 0.084 (the speed of the hyper trigger cycle in milliseconds).

NEO = (x + 1)ⁿ * 0.084 seconds; x < 64, n > 0

In this example, I have 4 copies of hyper triggers with 62 waits per hyper trigger which will look like this:

[62][62][62][62]

[]=hyper trigger
62=# of wait actions

NEO = (62 + 1)⁴ * 0.084 seconds
NEO = 63⁴ * 0.084 seconds
NEO = 15792161 * 0.084 seconds
NEO = 1323248.724 seconds

1323248.724 seconds is around 367.56909 hours, which is over two weeks of a grace period before the NEO comes around. Nobody in their right mindset will play a map for over two weeks straight, usually.

Adding one more copy increases the grace period to over two and a half years, but as a general rule, four copies will be sufficient.

Hyper Triggers and Map Lag

Often, complex maps or maps that require actions every trigger cycle will cause map lag, due to the CPU load of running triggers 12 times every 1.008 seconds. Fortunately with hyper triggers, the Wait time can be customized to determine how many cycles per second the triggers will run. Since in most cases it is not necessary to run hyper triggers as fast as Starcraft allows, unintentional map lag is often caused by attempting to run triggers faster than is necessary.

Most of this misunderstanding seems to be centered on a confusion around what the Wait action actually does. When the computer comes across a wait action it will run a full trigger cycle at approximately 1/12th of a second, then wait the alotted time. An isolated Wait(0) action will thus run two trigger cycles at 1/12th of a second, whereas an isolated Wait(168) action will run one cycle at 1/12th of a second and one cycle after waiting 1/6th of a second.

Basically, Starcraft always runs triggers at 1/12th of a second, regardless of how long the cooldown between trigger cycles is. The Wait action, when used properly, customizes this cooldown to whatever the mapmaker wishes, with a minimum of 84 milliseconds. Common hypers at Wait(84) are thus equivalent to hypers set at Wait(0), simply because the trigger cycle in Starcraft will NOT repeat faster than 84 milliseconds.

Applying this understanding, say you wanted to run a trigger cycle 6 times every second instead of 12 throughout the entire game. You would use something similar to the common hypertrigger above, except with your wait set at 168 milliseconds instead of 84 or 0 milliseconds:

Quote

Actions:
Preserve trigger
Comment. "Hyper Trigger"
Wait 168 milliseconds
Wait 168 milliseconds
Wait 168 milliseconds
Wait 168 milliseconds
Wait 168 milliseconds
(Fill the action list with waits)

Four times every 1.008 seconds would be 252 milliseconds, three times would be 336 milliseconds, etc.


Using the knowledge on this page it is possible to fully customize when and how fast your triggers are running, eliminate map lag and optimize trigger timing. Using a combination of simple hyper triggers and switch hyper triggers, an understanding of how adding more Wait actions influences how many trigger cycles will reset prematurely, and varying wait times, a mapmaker has total control.

Wait Blocks

Wait Blocks

"Wait blocks" is a common term for a wait action problem that many mappers face when their maps become more complex.
Exactly what happens during a wait block is not entirely clear, but some of it has been figured out.
Any given player can only run one wait action at a time. Additional waits trying to run will be delayed, or blocked.

The most common wait block occurs when players use hyper triggers in conjunction with other triggers containing waits. Generally what happens is when their trigger with the wait action runs, it doesn't finish for a very long time.

How do I avoid wait blocks?

Set up your hypers triggers correctly: (only if you're using them)
- The simplest way is to have the hyper triggers owned by a player that doesn't have any other wait actions. Hyper triggers are typically given to a computer player, in order for the human players to be able to use waits.
- If all players are using waits you have give the hyper triggers to "All Players" and move them to the bottom of the trigger list.
(In ScmDraft 2 this works by marking every player, force and All Players and then mark a hyper trigger and hold the 'o' key until it reached the end; or delete and remake the hyper triggers. That way they are automatically last in the list.)
Note that this method still fails if each player is running a wait the same time. Then the hyper trigger effect will be disabled until one of the waits is finished.

Substitute your waits with other forms of timers:
- with Death Counters (recommended)
- order a unit to move from Point A to Point B. When it reaches point B, activate the trigger and move the unit back to Point A.
- using the countdown timer.
- set a terran building to < 30% hitpoints. When it burned down, activate the trigger and recreate the building

What's happening during a wait block?

Triggers run actions one at a time.
When a trigger in the trigger list contains a wait, before StarCraft begins the "waiting" process, the trigger engine decides to check all the triggers before this one (in the trigger list) to see if their conditions are fulfilled. If any trigger's conditions are fulfilled, those triggers run before the "waiting".

Quote

Conditions:
Always.
Actions:
Create 1 Marine.
Preserve trigger.

Quote

Conditions:
Always.
Actions:
Display text message: "Hello!"
Wait 1000 milliseconds.
Display text message:"Good-bye!"

Theoretically, these 2 triggers should run like this:
1. Create 1 Marine.
2. Display text message: "Hello!"
3. Create 1 Marine (hit the wait, before the wait this runs).
4. Waiting 1000 milliseconds.
5. Display text message:"Good-bye!"
That would be 1 trigger cycle (going through all the triggers once).

Example

When there's a wait instead of a marine creation trigger or a hyper trigger, the waits could go on longer, perhaps even "never" end.

Counter Arithmetic

It is possible to do basic mathematical operations with triggers. Refer to the map Binary Calculator for an example of add, subtract, multiply, and divide.

Binary Countoffs can be used to speed up these calculations.

Addition

Adding two counters is fairly simple. All you need to do is subtract from one counter while adding to the other.
As an example, suppose you have two counters, minerals and gas, set to 10 and 8 respectively, and you need to add gas to minerals.
It is possible to do this with a single trigger.

Quote

Conditions:
Current Player accumulates at least 1 gas.

Actions:
Preserve trigger.
Modify resources for Current Player: Subtract 1 gas.
Modify resources for Current Player: Add 1 ore.

This trigger will need to be allowed to run untill gas reaches zero in order to get the correct sum. The use of hyper triggers will speed up this process greatly.

If you need to have this operation finish in one trigger cycle, you can copy this trigger many times, or use a binary countoff.

Subtraction

Subtraction can be done similarly to addition. Instead of subtrating from one counter and adding to the other, subtract from both counters. A problem with this method of subtraction is that it will not handle negative numbers. If the subtrahend is larger than the minuend, the result will incorrectly be zero.

Subtraction With Negatives

Since negative values are common when dealing with subtraction, and StarCraft's counter system won't deal with them, your system will need to be able to.

The above subtraction method, with no regard for negative numbers, will attempt to keep subtracting when it is not possible to do so. For example, if you're trying to subtract 5 from 2, the system will attempt to subtract one from the result thee times when it is already zero, which will not change it.

To counter this, simply prevent the system from doing it. When the number being subtracted from reaches zero, stop.
The other counter will still have a positive value. If you use your imagination and pretend that this value is negative, then this is your result.

Multiplication

For this method of multiplication, you will need additional counters.
Check if either of the numbers are 0 before you start, as this indicates that the result will be zero.

If the numbers (minerals and gas) are non-zero, then do the following operations:
　　1) Add the amount of gas to a Result counter and to a Storage counter.
　　2) Subtract 1 from minerlals.
　　3) Use the Storage counter to restore the amount of gas.
　　4) Repeat steps these untill the amount of minerals is zero.

For this operation to happen in a reasonable amount of time, you will almost certainly need to use binary countoffs. If the numbers are very large, it may also be necessary to copy the entire system a few times over to speed up the calculation.

Division

Divide is similar to multiply.
Just subtract the denominator from the numerator, and add 1 to the result. Repeat this untill the numerator reaches zero.
You can store the amount subtraced during the last cycle in another counter if you want a remainder.

Running StarCraft Mods

How to Run a StarCraft Mod

In this tutorial you will learn how to run the mods, also known as customs. It's quite simple. Obviously you'll need to download your custom first, and extract it out of its ZIP file if it came in one. The customs we host will have a recommended patch number displayed on their pages. If you don't have the recommended patch version, the custom may or may not run properly. In that case, try downgrading or upgrading to the recommended patch version.

Step 1: The Two Main Methods

There are two main ways an author can distribute their custom.



Have a look at what you downloaded. Look for a file with an EXE extension or an MPQ extension. This file is your custom file.

Step 2a: EXE Method

» If your custom has an EXE extension...
All you need to do is double click the EXE. The custom automatically executes StarCraft with all the changes contained in the custom.

Step 2b: MPQ Method

» If your custom has an MPQ extension...
You will require MPQDraft to run this custom. You can find MPQDraft in the DLDB

Step 3: Loading the Mod

MPQDraft doesn't need to install itself, so once you've downloaded it, just run MPQDraft.exe. Click on 'Load MPQ Patch'

Step 4: Selecting StarCraft as the Component

Select the program StarCraft, and the component StarCraft, as shown in this diagram. Then click next.

Step 5: Selecting the MPQ

Click 'Browse for MPQs.' I'm sure you will be familiar with the open file dialog box that comes up. Use that dialog box to select the MPQ custom file that you downloaded, and click next to continue.

Step 6: Loading the Mod

Click finish. StarCraft will run with all the changes included in the custom.

External Links

SCORG Tutorial: Running StarCraft Mods

Fog of War

StarCraft maps have a Fog of War layer, which can be used to reveal parts of the map. When playing the single player missions, you may have noticed that certain buildings are visible on the mini-map, despite your units not ever having seen them. This was done by "cutting out" a piece of the fog of war over the building.

Typically, map makers never touch the Fog of War layer, and if/when they do, they either remove a small chunk to reveal a building, or remove all of it.
What they don't realize is that other effects can be achieved with this layer.

Editing the Fog

Simply go to the Fog of War layer and click in the main window. Clicking will toggle the fog between on and off for the player you have selected.
If you hold down Ctrl you can edit the fog for all players at once.
Completely covering a large map with a Fog of War pattern can take quite some time. You can edit the size of the Fog of war brush the same way you do it with other Brushes.
If you want to make a large grid, like shown in the first picture of "Darkness degrees" beneath, first make all horizontal lines with a brush size of 100/1 than make all vertical lines with a brush size of 1/100, or bigger. It depends on the size of your map.
If you want all the players to have the effect visible, make sure to hold down Ctrl when you edit the fog. If you don't, you'll end up having to repeat the entire process for the other players.

The fog of war in SCMDraft 2 ------------- The fog of war in StarCraft.

Darkness degrees

The fog of war isn't strictly all-or-nothing. By making a pattern in the fog of war layer, you can create various levels of darkness.

Mini-map Appearance

Each terrain tile shown on the in-game mini-map can be either unrevealed (Black), partly revealed (Grayscale), or revealed (Color).
Using the technique shown above will give your unrevealed mini-map a distinctive "pixelated" look.

SCMDraft 2

With SCMDraft 2 you can reveal or un-reveal the entire map at once.

Crashlist

All of the things listed here can/will cause StarCraft to crash.
If your map is crashing and you can't figure out why, go down this list and make any fixes necessary.

Unit/Sprite Related Crashes

• Setting a building's max HP to zero. (Windows-only crash.)
  
• Setting a unit's build time to zero and viewing the unit production bar while the unit is being trained. (Windows-only crash.)
  
• Placing certain units on the map.
  
• Placing certain sprites on the map. (Example: Psionic Storm, Grenade Shot Smoke, White Circle)
  
• Placing extended units or sprites on the map. (Buffer overflow)
  
• Placing units for extended players. (Buffer overflow)
  
• Disabling certain units.
  
• Clicking on Flags with high index player colors. (Buffer overflow)
  
• Clicking on any extended unit. (Buffer overflow)
  
• Clicking on a unit sprite with negative HP.
  
• Clicking on a unit with 8388607 HP and a nonzero HP flag (small box next to HP box).
  
• Giving units from one player to another just as they hatch or are finished building.
  
• Placing certain disabled unit sprites on the map. (Example: Protoss Archon, Protoss Pylon, Terran Siege Tank, etc.)
  

Map Setting Crashes

• Making a map with both dimensions non-standard sizes. (Standard sizes are 64, 96, 128, 192, 256.) This only crashes without data in the terrain and mini-map buffers from a standard-sized map. (In other words, play a normal-sized map before playing a odd-sized map in order to avoid the crash.)
  
• Setting an active player's race to an invalid one. (Buffer overflow)
  
• Setting an active player's controller to an invalid one. (Buffer overflow)
  
• Setting an active player's color to an invalid one.
  
• Invalid terrain. Can happen when making picture maps.
  

Other Crashes

• Attempting to use Play WAV with strings that don't exist in the map. (String pointer is beyond max strings (default: 1024))
  
• Displaying text that is mapped to a non-existent string. (String pointer is beyond max strings (default: 1024))
  
• Initiating non-existent triggers. (Buffer overflow)
  
• Displaying illegal/invalid portraits. (Buffer overflow)
  
• Placing non-existent terrain tiles. (Buffer overflow)
  
• Running conditions that read as a buffer overflow and reach non-readable memory.
  
• Saving the game in a map with more than 65535 triggers.
  

Forces

Description

Forces provide an easy way to organize different players in a scenario. You can also uses Forces to assign starting alliances between different players or to create Triggers that only affect one Force or another. Usually, it's a good idea to separate opposing players into different Forces. When players join a scenario game with Forces, they will see their Force name listed in the pre-game chatroom and can join any Force with an open human slot. While in the game lobby, if a computer player is in the same force as human players, the players in that force will not be able to change forces or move down in their current force.

By default, all players are a part of the same Force. To assign a player to a different Force, open up the Forces dialog and drag the player's name to the Forces box that you want them to join. You can also rename the Forces from the Forces dialog, and set several options for each Force.

There is a max of four different forces.

Force Options

The different options available for Forces are:

Allies - All players in the Force start out allied with each other, and their units will not attack each other.
Computers in the same force as humans will not be allied to them.
Computers in different forces as other computers will still be allied to them.

Allied Victory - All players in the Force start with Allied Victory turned on. Allied Victory settings affect the Opponents Condition. If you want to make a map that allows for allied victory, you should use the Opponents Condition in your Victory Triggers.

Random Start Location - All players in the Force will be assigned a random starting location.

Shared Vision - All players in the Force start out with Shared Vision turned on. Each player can see everything that the other players see, including cloaked and hidden units.

Note that these options (other than Random Start Location) are identical to the options in the Diplomatic Settings in the game. Players in the same Force can change their own settings once they are in the game.

Strings

Strings are sequences of text. StarCraft maps use strings for virtually every piece of custom text. Strings can include various control codes to change their alignment, color, and visibility. Maps have string tables, where custom strings are stored.

String usage

The following elements are stored as strings:

• Map title and description
  
• Force names
  
• Locations (even if unnamed)
  
• The "Anywhere" location
  
• Custom Switch names
  
• Custom unit names
  
• All text used in the Comment, Display Text Message, Leaderboard, Set Mission Objectives, Set Next Scenario, and Transmission trigger actions
  
• All text used in the Mission Objectives, Text Message, and Transmission mission briefing actions
  
• WAV sound paths
  

String limits

StarEdit and StarForge both limit mappers to 1024 individual strings. StarEdit additionally limits all strings to 1024 bytes. (That is, 1024 characters including control codes.) SCMDraft and both of the Uberation programs support an unlimited number of strings. However, the total size of all strings cannot exceed 65536 bytes.

Each character in a string (including control codes) takes up one byte of data. Each string has a two-byte offset value and a one-byte null terminator (which marks the end of the string). So the string "Hello", for example, takes up 8 bytes.

Some third-party map editors, such as SCMDraft 2, will automatically recycle strings that are exact duplicates of each other (whitespace and control codes included). So if someone uses the string "Hello" eight times, SCMDraft 2 will only create one string. (Other map editors would create eight identical and useless copies of that string.) This helps keep maps from reaching the string limit.

Saving strings

There are ways to save on strings if you hit the limit.

• Set Forces to all share the same name (or leave the default names in).
  
• Remove names from Switches. You can write down their functions in a text file.
  
• Remove names from named units that are being used as Death Counters. You can write down their functions in a text file.
  
• Removing names from Locations will not save strings, but setting all Locations to the same name will. (This could cause problems with SCMDraft 2's Text Trigedit, however.)
  
• When displaying multiple variables at once via Display Text Message, do not have multiple variables on the same line. (If you do, then you need to create a string for every possible combination of both values.)
  

Map Limits

Map limits:

• Location limit: 254 (+ Anywhere = 255)
  
• String limit: 1024 in StarEdit/XtraEdit (Variable in other editors, see Strings)
  
• Trigger limit: 65535 (This is the number of Triggers that a map can have until Starcraft crashes while saving the game.)
  
  
• Minimum working map size: 1x6
  
• Maximum working map size: 256x256
  
  
• StarEdit Unit limit: 1650
  
• CHK load Unit limit: 1700 (This does not include Start Locations)
  
• StarCraft Unit limit: 1700 (This does not include Start Locations)
  
• StarEdit Sprite limit: 250
  
• CHK load Sprite limit: 499 (This is the number of Pure Sprites starcraft will load which obviously includes the sprites that are on some doodads like the tree doodads. If ever you over-pass this limit, Starcraft will ignore the last sprites created)
  
• StarCraft Sprite limit: 2500
  
• StarCraft Image limit: 5000
  
• StarCraft Weapon limit: 100 (cutoff of 80 for Valkyries)
  
  

• Unit HP range:
  -8 388 608 to 8 388 607.5
  
• Protoss Shield range:
  0 to 65 535
  
• Mineral/Gas cost range:
  0 to 65 535
  
• Build time range:
  0 to 65 535
  
• Armor range:
  0 to 255 (+255 with upgrades)
  
• Upgrades range:
  0 to 255
  
• Resource range for Mineral Fields and Geysers:
  0 to 65 535
  
• Damage range:
  0 to 65 535 (+ 65 535 bonus * 255 upgrades)
  
• Number Value (Wait, Set Deaths, Set Mineral Amount, Scores, etc.) range:
  -2 147 483 648 to 2 147 483 647