Selection Systems

What is a Selection System?

Selection systems are the UMS map maker's way of allowing the player to communicate with the map. In order for a player to communicate with the map in which they are playing, they need a method for inputting information into the map. This article is on how to create selection systems for players to "select" different items in order to make decisions within the map.

Bascially any kind of player choice that triggers detect in order to change the current game state is a form of a selection system. Common selection systems include the use of a Brracks, Stargate, or Dropship.

Location-Based Selection Method

• Location Selection (AKA Beacon Select, AKA Bring Unit to Location) - A common selection system where a player moves units to static locations to make meaningful decisions. Usually this location is marked with a beacon.
  • Method of Implemenation - Creating this type of selection system is simple; lay out some locations with a couple units that players control. Detect when a player moves one of these units into a location to perform a specific task. As mentioned above, the location that players move to is often marked with a beacon.
    
  • Pros
    • Easy to implement.
      
    • Very simple and straightforward.
      
  • Cons
    • Slow; units need to physically travel to the location.
      
    • Requires player's focus; player usually must view the location (after having selected the unit) to order their unit correctly.
      
    • Requires locations for each individual option the player can take.

.

• Move Select A selection system that involves checking if a given unit is NOT inside any given location(s) - Often simply used for single option, toggle-only, or always-having-at-least-one-option-constantly-selected selections. A more specific variation of movement select.
  • Method - Single Option: Place a unit to use for selections (preferably something small and fast). Place a location, usually smaller than the unit (a 1x1 pixel sized location would work), on top of the unit. For maximum response time, an inverted location can be used to detect the unit movement. The purpose of this system is to detect when the unit leaves that specific location you placed. Once this happens, move it back and then make any wanted changes to the current state of the map.
    
  • Pros
    • Simple and easy to understand, as well as easily implementable.
      
    • Fairly fast; unit only need travel at least its own radius in any direction to trigger options.
      
    • Hotkeyable; can be activated without needing player focus -the player can simply hotkey this unit and click anywhere on the map to use this system, rather than having to center their screen on the unit before moving the unit.
  • Cons
    • Requires a designated unit and a designated location.
      
    • May require explanation to the player (non-standard unit behavior implied).
      

.

• Unit Select (AKA Bring Unit to Unit) - Another common selection system involving triggers that keep a location centered upon a given unit. Selections are made by either bringing other units within this unit's location or moving this unit itself up to other units. The type and player of the unit brought to it can be detected and used to select a given option. Alternate form includes checking if units are NOT near the given unit.
  • Method - Place selector unit. Place option units. Create a location (usually 2x2) on top of the selector unit. Use an Always trigger with Preserve Unit to Center the 2x2 location onto the selector unit. Detect when option units enter the location with Bring Unit triggers and activate the corresponding options.
    
  • Pros
    • Intuitive; easy for players to understand with little explanation.
      
    • Not hard to implement.
      
  • Cons
    • Slow; needs unit to physically travel to other units.
      
    • Requires physical space on the map for each options and enough room for the selector unit and location to go between them.
      
    • Requires a unique method of detection for each option location.
      Methods may include:
      • Differing between the specific type of the unit in the option location.
        
      • Differing between the player that owns the different units in the option locations.
        
      • Differing between the amount of units in an option location -usually done with multiple amounts of the same burrowed unit.
    • Requires a location to follow the selector unit (recycling possible with some effort, though).
      
    • Requires a designated unit as the option selector.
      

Holder-Based

• Bunker Select A method that uses a bunker to hold and store units to be ejected at player will - A Terran Bunker is used as the primary method of this selection system. Terran Infantry units are loaded inside a given bunker via. triggers. Triggers can then detect when the player unloads units from the bunker, allowing for up to 5 unique options per bunker (includes the Unload All option; also detectable). Triggers can be used to automatically reload the bunker to make reselection possible. Alternate form includes checking if units are loaded into the bunker instead of unloaded.
  • Method - A location is placed over the bunker, the size of the bunker. Units that are in a bunker are still detectable via the bring condition, so one will need to detect when there is a lack of a specific unit inside of the bunker.^{Confirmation Needed}
    
  • Pros
    • Hotkeyable; a bunker can hot-keyed and orders can be issued without requiring the player to center their screen on the bunker.
      
    • 5 different selection detections can be made with a single location (the 5th being all units ejected at once).
      
    • Rather simple and easy to implement.
      
    • If the bunker is properly labeled/named then the use of this system can be highly intuitive to players.
      
  • Cons
    • 4 different units are required to placed into each bunker.
      
    • Each bunker requires a specific amount of physical space on the map.
      
    • One location per bunker is required.
      

.

• Transport Select A method that uses a transport to hold and store units to be ejected at player will - A transport unit (Zerg Overlord, Yggdrasill (Overlord), Terran Dropship, Protoss Shuttle) can be used to hold units inside. Units unloaded from the transport can be detected and used to select up to 8 unique options. Triggers can be used to automatically reload the transport.
  • Method - A location is required to detect when units are ejected from the transport. It is recommended that triggers are used to ensure that the transport carrier stays within the detecting location. The detecting location must detect ground levels only. To do this, select your location and hit enter, or double click the location. Once in the location's properties, uncheck all the air detection check-marks. This will allow you to detect when a unit has exited the transport.
    
    
  • Optional Method: One could use inverted locations to detect pixel movement of the transport, and immediately move the transport back to their designated spot. This can also be used as another input option (in addition to loaded units), not only to keep the transport still.
    
    
  • Pros
    • 8-9 possible options from a single transport carrier.
      
    • Hotkeyable; a transport can hot-keyed and orders can be issued without requiring the player to center their screen on the bunker.
      
    • Rather easy to implement. -Complicated forms of menus using this selection system can get tedious
      
    • Users usually understand fairly easily what the transport is used for.
      
  • Cons
    • Requires one location per transport.
      
    • Requires differentiatable units within the transport.
      
      Optional Method: Once you load a transport full of peon units (SCV, Drone, Probe). These peons could each be carrying a different type of resource. The carried resources must be pre-placed on the map and next to the peons. When the map starts, the peons will pick up the resource chunk and hold it. With this, one can detect the resource chunk rather than the peons, making for a possible 24 different options with only 3 different peon units.^{Confirmation Needed}
      
      
    • Usually requires a trigger to keep the transport in a single spot without moving, if an inverted location is used that adds one more location to the required locations count.
      

.
Spell & Ability-Based

• Dark Swarm/Disruption Web Select - Using either the Zerg Defiler's Dark Swarm ability or the Protoss Corsair's Disruption Web ability, players can freely target specific points within range of the caster. Both the spell being cast and its exact location can be detected as units (Dark Swarm and Disruption Web units, respectively) belonging to the neutral player (Player 12). Spell units can be removed to allow repeatable selections.
  • Method - <how to goeth here>
    
  • Pros
    • <stuff>
      
  • Cons
    • <stuff>
      

• Mind Control Select - Using the Dark Archon's Mind Control ability, non-building units ('men') of different players can be targeted by the spell and detected as a player's selection choice.
  • Method - <how to goeth here>
    
  • Pros
    • <stuff>
      
  • Cons
    • <stuff>
      

• Hallucination Select - Using the High Templar's Hallucination ability, non-building units ('men') can be targeted by the spell and detected as a player's selection choice.
  • Method - <how to goeth here>
    
  • Pros
    • <stuff>
      
  • Cons
    • <stuff>
      

• Liftoff Select - Any buildings with the Liftoff ability (Terran Command Center, Terran Barracks, Terran Engineering Bay, Terran Factory, Terran Starport, Terran Science Facility, Infested Command Center) can be detected for option selections when either lifted from the ground or landed at a given spot.
  • Method - <how to goeth here>
    
  • Pros
    • <stuff>
      
  • Cons
    • <stuff>
      

• Burrow Select - Using any burrowable unit in the game (Zerg Zergling, Zerg Hydralisk, Zerg Drone, Zerg Defiler, Infested Terran, Devouring One (Zergling), Hunter Killer (Hydralisk), Unclean One (Defiler)), triggers can be made to detect whether a player burrows or unburrows a given unit for use with option selections.
  • Method - <how to goeth here>
    
  • Pros
    • <stuff>
      
  • Cons
    • <stuff>
      

• Morph Select - Using any morphable units in the game (Zerg Drone, Zerg Hydralisk, Zerg Mutalisk, Zerg Creep Colony, Zerg Hatchery, Zerg Lair, Zerg Spire, Terran Siege Tank (Tank Mode), Terran Siege Tank (Tank Mode), Edmund Duke (Siege Tank), Edmund Duke (Siege Mode), Protoss High Templar (two needed), Protoss Dark Templar (two needed)), option selections can be made by detecting the changed unit.
  • Method - <how to goeth here>
    
  • Pros
    • <stuff>
      
  • Cons
    • <stuff>
      

• Cloak Select - Using any cloakable unit or unit capable of making others cloak (Terran Ghost, Terran Wraith, Tom Kazansky (Wraith), Sarah Kerrigan (Ghost), Alexei Stukov (Ghost), Samir Duran (Ghost), Infested Kerrigan (Infested Terran), Infested Duran, Protoss Arbiter), the visibility status of a given unit can be detected through certain methods when cloaking is turned on or off. May also apply for burrowable units, too (not in the same way as Burrow Select, however).
  • Method - <how to goeth here>
    
  • Pros
    • <stuff>
      
  • Cons
    • <stuff>
      

Build-Based

• Factory Build Select - A selection system where players can use any factories (Terran Command Center, Terran Barracks, Terran Factory, Terran Starport, Protoss Nexus, Protoss Gateway, Protoss Robotics Facility, Protoss Stargate) to build units for use as option selections.
  • Method - <how to goeth here>
    
  • Pros
    • <stuff>
      
  • Cons
    • <stuff>
      

• Factory Build Cost Select - Variant of the above optimized for slightly better responsiveness.
  • Method - Set each unit at the factory to a unique cost of one resource. Start each player with a certain amount of that resource. In order to avoid bugginess, ensure that the unique resource cost of each unit is more than half the starting amount of the resource. Instead of detecting the presence of a unit at the factory, detect the reserved resource being reduced to the difference between the starting amount and the unique cost. Then perform the action and restore the starting resource amount. Remove produced units as you wish.
    
  • Pros
    • Better 'feel' than standard Factory systems because it is detected instantly, rather than after the 1/15th-second build time.
      
    • Always operates exactly as fast as your triggers cycle.
      
  • Cons
    • Requires a resource type and your choice of unique unit types or a location.
      

• Addon Select - Through Terran buildings capable of constructing Addons (Terran Command Center, Terran Factory, Terran Starport, Terran Science Facility), the addons themselves can be detected for use as option selections.
  • Method - <how to goeth here>
    
  • Pros
    • <stuff>
      
  • Cons
    • <stuff>
      

• Hangar Select - Any unit with a hangar capacity (Protoss Reaver, Protoss Carrier, Warbringer (Reaver), Gantrithor (Carrier)) can be used to make selections; either by building hangar units (including how many are built), or by deploying hangar units through an attack of some sort.
  • Method - <how to goeth here>
    
  • Pros
    • <stuff>
      
  • Cons
    • <stuff>
      

Name	Hotkeys	1st Unit	2nd Unit	3rd Unit	4th Unit	5th Unit
Barracks	m,f,g,c	Marine	Firebat	Ghost	Medic
Command Center	s	SCV
Factory	v,t,g	Vulture	Siege Tank	Goliath
Starport	w,d,v,b,y	Wraith	Dropship	Science Vessel	Battlecruiser	Valkyrie
Gateway	z,d,t,k	Zealot	Dragoon	High Templar	Dark Templar
Nexus	p	Probe
Stargate	s,c,a,o	Scout	Carrier	Arbiter	Corsair
Robotics Facility	s,r,o	Shuttle	Reaver

Misc/Advanced/Composite

• Kill/Death Select - Through any means available that kills or gets a unit killed/removed (direct attacks/harmful abilities, area effect/splash abilities/attacks, Defiler's consume, Queen's Broodling, Archon Warp, Dark Archon Meld, Infested Terran Explode), unit deaths/disappearnaces can be detected and used to select options. This system comes in a large variety of possible forms. Deaths can be detected by the absence of the unit that was killed, a player's Kill Score increasing, the killed unit's player's Deaths count increasing for that unit, or the absence of a given detectable activity the killed unit was in the process of executing.
  • Method - <how to goeth here>
    
  • Pros
    • <stuff>
      
  • Cons
    • <stuff>
      

• Rally Select - An extension to build select. Options built at factories can be set to automatically move to player-selected locations via. setting the factory's rally point. These positions can be detected via. Location Select. Works best with air units.
  • Method - <how to goeth here>
    
  • Pros
    • <stuff>
      
  • Cons
    • <stuff>
      

• Mine Tripper Select - A variation of either Location Select, Kill Select, or even Burrow Select that involves triggering a burrowed Vulture Spider Mine to pop up and try to attack.
  • Method - <how to goeth here>
    
  • Pros
    • <stuff>
      
  • Cons
    • <stuff>
      

• Heal Select - Injured organic units can be used to con allied medics to attempt to heal them. The medic's automatic move to heal can then be detected (via. Location Selection) when an injured unit is within its heal range. Selections are therefore made by injuring any healable units near a given allied medic in some way.
  • Method - <how to goeth here>
    
  • Pros
    • <stuff>
      
  • Cons
    • <stuff>
      

• Detection Select - Functionally the opposite of Cloak Select. Cloaked or concealed units detected through any means (Ally Vision, Scanner Sweep, Vulture Spider Mines, Terran Missile Turret, Terran Science Vessel, Magellan (Science Vessel), Protoss Photon Cannon, Protoss Observer, Ensnare, Plague, Devourer's Acid Spores, Zerg Spore Colony, Zerg Overlord, Yggdrasill (Overlord), Zerg Cerebrate, Zerg Cerebrate Danimoth, Zerg Overmind (each type) <did I miss any?>) can be used to detect any given cloaked or concealed units. Trigger methods can then be used to tell which units were detected and use that to select options accordingly.
  • Method - <how to goeth here>
    
  • Pros
    • <stuff>
      
  • Cons
    • <stuff>
      

• Recall Select - The Protoss Arbiter's ability to recall a player's 'men' from anywhere on the map to its position can be used to detect both the movement, type, and number of units recalled away from a given point.
  • Method - <how to goeth here>
    
  • Pros
    • <stuff>
      
  • Cons
    • <stuff>
      

• Nydus Select - Using the Zerg Nydus Canal's ability to create an exit point at any given location on the map covered by creep, the creation and position of the exit Nydus Canal can be used to make option selections.
  • Method - <how to goeth here>
    
  • Pros
    • <stuff>
      
  • Cons
    • <stuff>
      

• Flag Beacon Select - Using the Flag Beacon's ability to be moved onto any given buildable location on the map once per beacon (but only within the first 5 minutes of gameplay), the movement and position of the Flag Beacon can be detected for option selection use.
  • Method - <how to goeth here>
    
  • Pros
    • <stuff>
      
  • Cons
    • <stuff>
      

• Morph/Build Abort Select - Most morphable or buildable units have both a progress meter and a cancel option for their construction/morph duration. Through either the mineral/gas refund incurred from a cancellation of a build, or else the absence of the unit (using an odd property of the At Most modifier of the Brings Unit condition to detect this, usually), aborted attempts to build or morph units can be detected by triggers. Certain units, additionally, can also be set to build/morph indefinitely by setting them with the smallest possible non-zero build time.
  • Method - <how to goeth here>
    
  • Pros
    • <stuff>
      
  • Cons
    • <stuff>
      

• Ally/Vision Select - Players can adjust their alliance or allied vision settings to other players in-game. This can be detected.
  • Method - <how to goeth here>
    
  • Pros
    • <stuff>
      
  • Cons
    • <stuff>
      

• Upgrade Detection - Detect when players purchase upgrades.
  • Method - Very similar to Factory Build Cost Detection: set each upgrade to a unique cost of a certain resource, then detect when the starting amount of that resource is reduced. To reset, give the upgrade structure to an unused player and back again; doing so both cancels the upgrade and restores the resources. If your effect has a cost in the other (non-reserved) resource, you'll want to subtract it with your trigger, because the upgrade cost will be refunded.
    
  • Pros
    • Can easily limit options for player
      
    • Can easily select upgrades via hotkeys
      
    • Very few triggers are required.
      
    • Works well even in a wait-timing/non-hyper-trigger environment.
      
    • Instantaneous.
      
    • No locations or unit types required.
      
  • Cons
    • Only allows up to four options per building
      
    • Requires a Building
      
    • Requires a resource type.
      
    • Inappropriate for quickly repeated commands because selection is lost in the reset process.
      

[/list][list]

Changing Minerals Mined

With Binary Countoffs and Death Counters, it is possible to change the standard mineral and gas Input stream. While hyper triggers are not necessary, they are highly recommended for unnoticeable effects. A demonstration map can be found here.

Introduction

This system uses 3 death counters. They will henceforth be referred to as "DC1", "DC2", and "DC3". DC1 is a death counter, which, at all times will measure the amount of resources the player had the previous trigger run. DC2 is a temporary death counter. It keeps track of how many minerals were in the bank, as well as DC1's status, while the minerals that have been mined are counted. DC3 is a counter who's purpose is to keep track of how many minerals the player has gathered since the previous trigger run.

Counting Previously Owned Ore

First a dual transfer is made. Since all conditions must be met in order for a trigger to fire, this will empty whichever is lowest, and leave the higher one with the difference. The ore, as well as the value of "DC1" are transferred into "DC2". This will take the amount of ore that the player had previously, and put it into "DC2". Any additional ore will remain, since "DC1" will run out before the ore does.

Counting Newly Aquired Ore

This is the simplest part. Since we have already removed any previously owned ore, the remainder is all either ore that has been gathered, or leftover deaths, caused by spending money. There are two ways to deal with spent money, which will be explained later. For now, we will deal with ore gained. Simply transfer from ore, into "DC3". Since we know that it has been gained by multiples of 8, we only need to use binary values of 8 and above. Also, it is recommended that you either set DC1 to 0 at this point, or do something else to the remainder. We can also, at this point, confirm that no transactions have been made, and check for any remaining minerals. If a transaction has been made, there will be minerals leftover.

Returning Previously Owned Ore

There is nothing complex about this stage, except one important thing to remember. You must transfer the value of "DC3" back into the ore, at a 1:1 ratio. This is because we do not want the player's money in his bank to change between trigger runs. Also, you must transfer the same amount into DC1. This will set the stage for the next trigger run, when the player's resources are recounted.

Returning Newly Mined Ore

Now is the important part of the system. This is where we give back the resources a player has mined. You make a transfer from "DC3" into Ore, and "DC1". If you leave this at a 1:1 ratio, nothing will happen. The map will appear regular. However, if you change the ratio, say 1 DC3:2 Ore, and DC1, you will find the player mining 16 minerals per chunk. It is recommended that you use multiples of 8 for the last DC3 countoff, and the amount received per chunk for the ore returned, and DC1 value. Then double the values as you would for any binary countoff.

Summary

First The ore and "DC1" are transferred into "DC2". Then, the remaining ore is transferred into "DC3". "DC2" is then converted into ore and DC1, and finally, "DC3" is converted to ore and "DC1" at the transfer rate.

Use Alongside Triggers

Generally, when this system is being used alongside triggers, any time you add or remove ore for the player, you should also add or remove an equal amount of "DC1" along with them. The system will not apply the transfer rate, and will act as it should.

Dealing with Transactions

Hereinafter, a "transaction" is any use of money in which the player spends or receives money, not through ore, without the possibility of deaths being added or subtracted. There are two methods in which to solve these. Both have advantages and disadvantages.

Method 1

Method 1 is very simple. All that is done is confirming whether the minerals gained in between trigger run is divisible by 8. If there are any minerals left over after counting newly acquired ore, then a transaction has been made. The transfer rate is not applied that trigger run. One disadvantage is that if a player makes a transaction in which he has earned a number divisible by 8, it will be put through the transfer rate. The disadvantage to this system is that the ore the player has gathered that trigger run will not be changed. Hyper triggers are necessary for this system to run. Mainly because without them, that much more ore will not go through the transfer rate.

Method 2

This method detects whether the player has gained more resources than humanly possible in the timeframe between trigger runs. The tested value with 200 stacked resources at mineral distance, with 200 SCV's is 40 ore per trigger run. If the player has received more than the max ore, they have made a transaction. Then ore is counted back at a certain rate. 25 minerals at a time works for default stats. The disadvantages to this system are that it doesn't work for a variety of maps, and it doesn't work well for small prices.

These two methods can be combined, and mixed around for more effective results.

Grid Systems

Introduction

A grid is a method of 'marking' certain points (or 'coordinates') on a map without creating a location for each of the points. The ultimate goal of any grid is to move a location to the desired marked point and perform some actions at that point using that location. Often, having a grid system is the only way to achieve a goal, which is why grids are very important aspects of mapping.

There are three main typse of grids: Static Grids, Mobile Grids and Location Grids. Each type has its own advantages and disadvantages.

Some maps, such as Reflector and Maze Generator use multiple grid systems to achive their disired outcomes.

Static and Mobile grids use the way SC selects units from a location that are subject to certain actions. To understand how these two grid systems work, one must first understand the SC mechanics the systems are based on.

SC Mechanics Regarding Static and Mobile Grids

The three most important actions for these grid systems are "Move (Center) Location", "Give Units to Player" and "Remove Units". When any of these actions are performed on a group of units in a location, SC selects the leftmost, last created or moved (in that order) unit. For example, arrange a test map with 5 Terran Marines owned by P1 (red) scattered in a location called "Arena" and a separate, 1x1 tile location called "scan", as shown:


These marines are our grid coordinates. They will represent the points on the map where we want to move our "scan" location. Note that all Marines are placed with a fine grid; from the two marines that are one under another, the top one was created first.

The first and simplest test would be to create a unit (Khalys Crystal) at the location of the first Marine (bottom left). To do that, make the following trigger:

Code

Once "Switch1" is set, the trigger will execute the actions in the specified order:

1. Move the location "scan" on the first Terran Marine it finds in the location "Arena". It will first find the leftmost Marine(s) in "Arena" - the one with the lowest X coordinate - and since there are no other marines with the same X coordinate, it will select the bottom-left Marine as desired, and move the location "scan" on it.
2. Select the bottom-left Marine with the same selction process and give it to Player 2.
3. Remove the only Marine owned by Player 2 in "Arena", which is the one it just gave to that player
4. Create Khalis Crystal at 'scan', which is at the location of the Marine that just got removed
5. Clear "Switch1" so that this trigger runs only once on request.

After this trigger runs, the situation will look like this:


Suppose it is needed to create a Khalis Crystal at the location of the Marine that is right below the middle of "Arena". This means the system will have to 'skip' 2 Marines and center "scan" on the required one. To achieve that, the following trigger must be run:

Code

Following the same logics, it will skip two marines, remove the next one it finds and create the crystal at his position. After the trigger runs, the situation will look like this:


The trickiest case is when several units have the same X coordinate. In this case, SC will select the one that has been created, moved or placed last. Hence, if you followed the guidelines of this article and placed the top Marine (of the two that have equal X coordianates) first, and the bottom Marine last of the two, then running the first trigger associated with "Switch1" will create the crystal at the bottom Marine's location. Hence if you need a set of units all in with the same X coordinate, to know the order of their selection you must know the order in which they were created (or placed). If you want them to be selected from bottom to top, you must create (or place) them in reverse order - from top to bottom.



Static Grids

A Static Grid uses preplaced (often burrowed) units as its coordinates. These units are not moved and in most cases, not removed, hence the name 'static'. These grids are very often used to save locations at the cost of units. Static grids function as it was shown in the previous section of this article; the only difference is that most static grids do not remove the grid units, so they can be used again.

Here is a setup of the most common static grid:


The burrowed units are Zerg Zerglings owned by Player 9 (neutral). All burrowed units used in Static grids should be owned by neutral players at all times, because burrowed units owned by active players tend to unburrow when given to another palyer. Note that the Zerglings are placed with a fine grid (even though it may appear that they are lower than the grid points). It is important that each Zergling in every column is placed after the one above it - it is just another way of saying that you must create them from bottom to top in order for the SC unit selection to be consistent.

The action for this example would be an explosion at any desired position. The trigger for it would be similar to this:

Code

The given trigger is generalized to work with any number of grid units, as long as the variable N (in the first 'give units' command) is less than or equal to the number of grid units in the location "Arena" (in this case, there are 25 Zerglings). The units are given between two neutral players (9 and 10) to avoid unburrowing problems.

Problems

Static grids use the "Give Units" command to work, which is one of the most 'lag-heavy' commands in SC. Constantly giving too many units can make the map lag a lot, which is why constantly running big Static grids is a bad idea.

Another problem is the amount of units the grid uses. Some maps such as RPGs or RPs require a lot of units, which conflicts with the grid - it may happen that a too big Static grid will require too many units, causing the map to hit the unit limit.

Try not to use big and accurate (meaning the distance between the grid units is small) grids in areas the player may look at - even if it will not lag because of the give commands, it may lag because of too many units on-screen (even if they are burrowed, they still have this effect).




Mobile Grids

Mobile grids are more 'fregile' systems than Static grids, but offer greater capabilities. A Mobile grid is a system that creates a set of air units (in most cases), using the "Remove Unit" action centers a location on the desired air unit and removes the remaining air units. To understand how Mobile grids work, one must understand the patterns in which certain air units are created and chosen by triggers.

There are two main types of Mobile grids: 1x1 and 1.5x1.5 grids. These sizes denote the distance in tiles between nearby grid points in the resulting grid.

The center of a Mobile grid is the location (or coordinate) where the first unit of the grid was created. An accurate mobile grid is one that produces consistent, equally spaced grid points.

1x1

An accurate, 9-unit 1x1 mobile grid is created with the following trigger:

Code

Meaning that one must create a Scourge at the center of th egrid, then an Observer at the center of the grid, then a Scourge, then an Observer... and so on. It is very important for the first unit to be a Scourge. The resulting grid contains 9 units, and the grid points are spaced by one tile, hence it is a 1x1 grid.

The units of this grid are created in the following pattern:
8 7 6
9 1 5
2 3 4

To center a location on the desired unit, one must know the order in which the units are selected by SC:
2 4 7
1 6 8
3 5 9

Thus, to center a location on the upper-right grid point (in the above diagram, represented by '7'), one must first remove 6 units from the grid and then center the location. If one could see triggers in slow-motion, this is how the creation and removal (or in this case, killing) of the grid units would occur:



1.5x1.5

An accurate, 9-unit 1.5x1.5 mobile grid is created with the following trigger:

Code

It is important that one uses Zerg Devourers. Other units such as Mutalisks *may* give accurate grids, but that information is yet to be confirmed.

The units of this grid are created in the following pattern:
7 6 5
8 1 4
9 2 3

To center a location on the desired unit, one must know the order in which the units are selected by SC:
3 4 7
2 6 8
1 5 9

Thus, to center a location on the middle-right grid point (in the above diagram, represented by '8'), one must first remove 7 units from the grid and then center the location. If one could see triggers in slow-motion, this is how the creation and removal (or in this case, killing) of Devourers would occur:


It is important that the grid units are removed and the location is centered in the same trigger cycle (or even in the same trigger), because other air units or triggers may disrupt the air units of the grid if they are left unremoved for atleast one trigger loop.

Problems

Mobile grids cannot work properly if there are air units in their path, as they will cause the grid units to be displaced, bugging the grid. One must always make sure there are no air units atleast in the area where the grid is about to be made.

Lag is a problem of Mobile grids, just like it is of Static grids, the only difference is that now you create/remove units instead of giving them, which is quite laggy as well.

Lag Reduction and Partial Mobile Grids

A Partial Mobile grid is one where the units of the grid do not form a square with a center i nthe middle of the grid. In other words, it is any grid other than a 9, 25, 49, etc. unit grid.

If only one grid point is needed at a time, one can create the grid only until that point (thus making it a Partial grid). For example, one is interested in the grid point to the right of the grid center, then it is possible to create the grid units as follows:

For a 1x1 grid:
X X X
X 1 5
2 3 4

And for a 1.5x1.5 grid:
X X X
X 1 4
X 2 3

With 'X' representing no units at the grid point. This allows to create less units, hence cause less lag. Compare this with the unit selection patterns:

For a 1x1:
1 4 7
3 6 9
2 5 8

For a 1.5x1.5:
3 4 7
2 6 8
1 5 9

One can see that removing 4 units for a 1x1 grid and 2 units for a 1.5x1.5 grid and then centering the location will give the required result - the rightmost grid point is selected.

Examples

Mobile grids are a powerful tool in a mapper's arsenal, as it allows to do most things a Static grid can do without any preplaced units. For example, creating a line of crystals.

Spaced by 1 tile. Direction: up.

Code

Spaced by 1.5 tiles. Direction: bottom-right.

Code

The Offset Glitch

If a grid is created incorrectly, even if following all the instructions and precautions, one is most probably experiencing the Offset Glitch.

The Offset Glitch often occurs when the Mobile grid is created at a unit that can move around (like a hero in an RPG). Please note that the unit's motion does not cause the glitch by itself, it is the unit's position that causes it.

SC divides each tile into 4 equal square segments or subtiles. These subtiles are equivallent to the fine grid in the editor. The first unit of the Mobile grid is always created directly at the specified location, however, all the following units are created centered on the nearest fine grid point (where subtiles' corners meet). Hence, if the grid center is not on one of the fine grid points, the grid units are created incorrectly, thus ruining the grid:


To prevent this, first use a Partial grid to move the center one grid point south (down) or south-west (bottom-left). After this, the new grid center will be without any offset, thus one can use a Mobile grid to move the grid center back. This will result in the grid center being centered on the subtile grid without offsets, hence allowing you to use Mobile grids normally from that point.


SC Mechanics Regarding Location Grids
To understand how Location grids work, one must know three facts:

1. A location can never leave the map in any of its dimensions.

2. If a location is attempted to be centered on a unit, the center of the location will be moved as close as possible to the center of the unit in both coordinates without breaking rule (1).

3. If a location A is attempted to be centered on a non-existing unit in location B, then the center of location A will be moved as close as possible to the center of location B in both coordinates without breaking rule (1).



Location Grids
Location grids are capable of moving a location to any grid point on the map. The closer the grid points are to each other, the more accurate the grid. Grid points are defined by the map maker - he has the ability to make a grid of any accuracy within the map limits.

The basic idea of Location grids is to use sets of locations as the X and Y axis along the map borders. Here is an example of a 1-tile-accurate Location grid:


The 1x1 tile "X=0" and "Y=0" locations are the coordinate start, the zeros for X and Y. All the axis locations must touch at least two borders of the map (all the shown locations touch the bottom and left borders of the map). All locations centers coinside with the corresponding tile centers. The shown grid can center a location on 9 possible points (3*3=9) buy using rules (1) and (3). One of the axis is chosen to be the 'static' one, and th eother - the dynamic one. For this example, let X be static and Y be dynamic.

Then the actions taken to center a location on a grid point X=1, Y=2 are the following:
1. Center a 'middleman' location "scan" on the required X coordinate, X=1:


2. Center the required Y coordinate location (Y=2) on the 'middleman' location "scan":


The two triggers that rearrange the locations for this specific case are:

Code

First, it centers the 1x1 tile "scan" location on the required coordinate of X, then it centers the required coordinate of Y on "scan". This two-step process is much more trigger-efficient than having to make a trigger per grid point.

Note that all the trigger code in the Location Grid section is not valid in the text trigger editor, as the parameters "X Coordinate" and "Y Coordinate" are not accepted - they must be original unit names. They are used simply to make the triggers understandable.

The general trigger system for this grid would be the following:

Code

Map Coverage

Since each next coordinate location is two tiles longer than the previous one, it is clear that with the setup shown above it is possible to cover only 25% of the map area. Meaning that each such set of coordinate locations covers one corner of a map. A logical solution is to make similar sets of locations for the other 3 corners of the map, but that will require too many locations. Alternatively, one could create 'origin' locations for each corner and reuse the same set of coordinate locations for all corners of the map buy centering them on the required origin locations. So if it needed to center a location on a point in the upper-right portion of the map, it would be enough to center the already existng coordinate locations on the new origin and work from there.

Pros and Cons

Though lagless, Location grids eat up locations very fast. The good thing about them is that they make the use of locations not needed - they can detect whether a unit is in a location or not, detect a unit's coordinates and create events at locations; so if all used areas of the map are covered by a Location grid system, other locations are simply not needed.



Grid Combinations

It is often wise to combine grid systems to complement the weaknesses of one system by the strengths of another.

Static and Mobile

It is possible to reduce lag caused by a Mobile grid traveling too much by creating a spread-out Static grid and launching the Mobile grid from one of the points of the Static grid.

Static and Location

To save locations (though sacrifice units) used in a Location grid, it is possible to replace the static axis of the grid with a line of units. One advantage of this is the ability to cover the entire map without going through the trouble of moving the coordinate locations from one corner to another - there are no coordinate locations; all that is needed are two lines of units along two parallel borders of the map or you can use shift locations to cut the units in half. Be advised that such a combination will not allow intense use due to lag that is brought into the system by the static grid unless you have enough units available so you don't have to give any at all.

Mobile and Location

Another way of saving locations in a Location grid is making it less accurate and using its grid points as launch points for a more accurate, albeit more laggy and air unit incompatible, Mobile grid.

Static, Mobile and Location

The combination of all three: use preplaced units as the static axis for the inaccurate Location grid, and use that grid's points to launch Mobile grids.

Simple Datediting

Foreword

This is a basic tutorial on how to use DatEdit. It's a tad outdated, so feel free to edit it with newer information and screenshots.

This tutorial was originally created by Killer_Kow(MM) at the [MM]odding resources, at Corboland.

Simple Dat Editing!

Here you will learn to:

1) give a unit shields
2) change a unit's weapon
3) change a unit's spell.

The programs you will need are:

Datedit
WinMPQ
MPQDraft

We'll start by giving the marine shields.

First, open Datedit.

Find the marine entry under the "units" tab. If you want to change the view, go View> Sort by Origin. Find what works best for you.

When you have the marine selected, it will look like this:

http://www.maplantis.org/storage/wiki/DatEdit/pic1qs4.png (img: failed to get size)

Under the "Vital Statistics" section, find the "Shields" box. Check the flag (a flag is a checkbox) next to it, and set the number to 50. Also, set the marine's Hit Points to 50. You can modify its existing armor using the "Armor" box. The "upgrade" menu shows which upgrade will upgrade the Marine's armor.

That's all that we'll do here. Go to file>save as and save the file as units.dat. The name you save it as MUST correspond to the tab you are working in (units in this case).

Now, we'll change the marine's weapon. We could change its weapon in the "weapons" section in the Marine's units.dat, but instead, we'll fully customize his attack.

To find the marine's gauss rifle, you could look through the list under the weapons tab, but there's an easier way! Since we're already in the marine's unit entry, we can click the "Jump ->" button next to his weapon name. See the screenie:

http://www.maplantis.org/storage/wiki/DatEdit/pic2ij1.png (img: failed to get size)

Either Jump will work, seeing as they point to the same weapon.

You'll end up seeing this:

http://www.maplantis.org/storage/wiki/DatEdit/pic3jt2.png (img: failed to get size)

Let's make the marine fire lasers. Under "Graphical Properties", set "Graphics" to "Burst lasers". Change the icon to whatever you feel is fitting. set the "Behaviour" to "Flies to Target".

These should be self-explanatory. Leave the missile as "Normal".

Again, do File>Save as and save the file as weapons.dat. Remember, it MUST correspond to the tab you're working in.

Now that we've done this, let's change a unit's spell. Unfortunately, we can't change the marine's stimpack, but we CAN change the ghost's lockdown ability.

For something fun, let's let the ghost call down a long-range arclite shock strike as you would have been able to in SC: Ghost.

Switch to the "Orders" tab. Find the "Magna Pulse" order. Why the lockdown order is called that is beyond me, but its true.

Under "Order Options", set "Weapon" to "Arclite Shock Cannon (Edmund Duke)". You can also change THAT weapon, but we'll leave it how it is.

Save as orders.dat. Don't make me remind you again.

Congratulations! You've finished your .dat work. Now to compile it to an MPQ!

Open WinMPQ.

Press the "New" button. Save it as whatever you want. This one doesn't matter. Press the "add" button. Find your files, and select them. When you press "open", a little box will pop up. Type in "arr\" (without the "") and confirm your choice. All .dat files work like this.

When all your files are in, close WinMPQ. It saves automatically.

Running Your Mod

Open MPQDraft.

Press "Load MPQ Patch".

Select Starcraft, Starcraft again, and press next. Browse for your MPQ, find it, ensure that the little box is checked, and press next, and then finish.

Enjoy your mod!

External Links

The original tutorial, at Corboland.

Terrain

A map's terrain is its landscape. Terrain's most basic function is to limit where ground units can walk and where structures can be built. Well-placed terrain can add aesthetic appeal to a map.

Tiles (Squares)

The most basic unit of terrain is the tile. Tiles are rectangular 32x32 pixel images. Each tile has certain properties, such as which parts of it are walkable, what elevation (low, medium, or high) it is at, and whether or not structures can be built on it. In StarEdit, X-tra Edit, or SCMDraft 2, you can toggle the tile grid by pressing alt+g. Only third-party map editors allow you to alter individual tiles of terrain.

Usually, tiles are combined into predefined groups of isometric pieces (ISOM, see below). However, third-party editors allow users to assemble tiles in unusual ways to create custom terrain formations called "extended terrain" or "blends". (See "Extended Terrain", below, for more information.)

ISOM

Isometric terrain, or ISOM, is the normal unit of terrain; this is the level that StarCraft's built-in Campaign Editor can work with. Tiles are assembled to form isometric terrain, and are designed to look like pieces of such terrain. When placing terrain normally, you manipulate isometric pieces rather than individual tiles.

Brushes

So far, brushes are only usable in two map editors: StarForge and SCMDraft 2. Brush files are collections of brushes, or groups of tiles -- they are like palettes for terrain. Brush files make it easy to reuse and share blends. SEN has a forum topic where useful brushes can be shared.

To open SCMDraft 2's brush dialog, go to Windows > Brush Palette. Brushes can be opened by clicking Open File, and selecting a brush. Multiple brushes can be opened at a time. To use a blend, simply select it in the Brush Palette window, and then click on the map to apply it. To create a new brush, select the appropriate tiles, type a name into the text field on the Brush Palette window, and then click Add Brush. Brush files can be saved by clicking Save File on the Brush Palette window.

Extended Terrain

Generally, any configuration of terrain tiles that cannot normally be placed in StarEdit is called extended terrain. Extended terrain usually refers to blended terrain tiles (placing tiles individually, but choosing ones that match each other on the edges). Typically, simple "square terrain" (using individual tiles with no regard as to how they blend together) is not considered to be extended terrain.

Common types of extended terrain

Custom ramps

Custom ramps are often made. The most common kinds of custom ramps are backwards ramps and ramps between two types of terrain that normally cannot connect. Lengthened and shortened versions of standard ramps have also been made.

A backwards ramp on the Space tileset:

Stacked cliffs

Stacked cliffs are relatively easy to create on most tilesets. On Badlands and Jungle, stacked cliffs can be created with ridiculous ease. Simply take the tops of Dirt-to-Water cliffs, and paste them over the tops of Dirt-to-High-Dirt cliffs. Then, copy the middle and top sections of Dirt-to-High-Dirt cliffs, and paste those just above the Dirt-to-Water tops.

This diagram shows how stacked High Dirt cliffs are pieced together.

Custom doodads

Custom Doodads come from a variety of tiles. While the term is mostly used to refer to terrain constructed from Doodad tiles, it can also refer to non-doodad-based terrain that can be used in a similar fashion to doodads.

Here is a custom doodad built by mirroring two opposite-facing doodads on the Jungle tileset.


Here is another example: a large tree. The tree's trunk was constructed from Cliff Doodad tiles. The leaves and branches came from Sprites.

Square terrain

Square terrain is terrain placed tile-by-tile, with little regard for how well the tiles blend. It is often used for interiors on maps.

Here is an example of square terrain, used for an interior in Leeroy_Jenkins' Middle of the Ocean RPG.

High-Low

On tilesets such as Jungle and Badlands, there are two types of terrain that look (almost) identical, the grass.


Good references for extended terrain include:

• Falkoner's Terrain Compilation
  
• WoodenFire's Crescent Dyne RPG map (which is included in Falkoner's Terrain Compilation, but it is such a big project that it deserves to be stressed out)

Starcraft 1.14 Memory Map

Note: This article has poor formatting. Help Maplantis by improving the formatting of this article and removing it from the Article Request/Cleanup page.

Start	Length	Description
511800	240 (60*4)	Action function pointer table
511BA0	12	Load information for Mapdata.dat
.
5126E0	144 (12*12)	Load information for Upgrades.dat
512770	16	Data alignment
512780	72 (12*6)	Load information for Portdata.dat
5127C8	16	Data alignment
5127D8	132 (11*12)	Load information for Techdata.dat
51285C	12	Data alignment
512868	288 (24*12)	Load information for Weapons.dat
.
512c30	648 (54*12)	Load information for Units.dat
512eb8	16	Data alignment
512ec8	228 (19*12)	Load information for Orders.dat
512FA8	16	Data alignment
512FB8	72 (6*12)	Load information for Sprites.dat
513000	16	Data alignment
513010	168 (14*12)	Load information for Images.dat
.
513178	1090	Units.dat Build Requirements
5135BA	6	Data alignment
5135C0	838	Upgrade.dat Upgrade Requirements
513906	2	Data alignment
513908	318	Techdata.dat Research Requirements
513A46	2	Data alignment
513A48	688	Techdata.dat Usage Requirements
513CF8	1324	Orders.dat Requirements
.
5144A0	60 (5*12)	Load information for Sfxdata.dat
.
514A40	84 (7*12)	Load information for Flingy.dat
514A94	12	Data alignment
514AA0	96 (24*4)	Condition function pointer table
514BF0	11264	start of Button Sets
5177F0	3000 (250*12)	start of Unit->Button Set table
.
5183A8	2736 (228*12)	start of Unit->Status Function table
.
51AAF8		Starcraft.exe location string
.
51B4A0		Starcraft.exe location string
.
51BA00		Broodat/Stardat.mpq location strings
.
51BC20		Starcraft.exe location string
.
51BD38		Patch_rt.mpq location string
.
52E548	325120 (5080*64)	Image array
.
57E0B8	48 (12*4)	Player minerals
57E0E8	48 (12*4)	Player gas
57E118	48 (12*4)	Player gas score
57E148	48 (12*4)	Player minerals score
57E178	4	Unknown
57E17C	12 (12*1)	Player controller
57E188	12 (12*1)	Player race
57E194	8 longs	Unknown
57E1B4	1 long	Player 1 gives vision to (in bits)
57E1B8	1 long	Player 2 gives vision to (in bits)
57E1BC	1 long	Player 3 gives vision to (in bits)
57E1C0	1 long	Player 4 gives vision to (in bits)
57E1C4	1 long	Player 5 gives vision to (in bits)
57E1C8	1 long	Player 6 gives vision to (in bits)
57E1CC	1 long	Player 7 gives vision to (in bits)
57E1D0	1 long	Player 8 gives vision to (in bits)
57E1D4	1 long	Player 9 gives vision to (in bits)
57E1D8	1 long	Player 10 gives vision to (in bits)
57E1DC	1 long	Player 11 gives vision to (in bits)
57E1E0	1 long	Player 12 gives vision to (in bits)
57E1E4	1 long	Player 1's colour
57E1E8	1 long	Player 2's colour
57E1EC	1 long	Player 3's colour
57E1F0	1 long	Player 4's colour
57E1F4	1 long	Player 5's colour
57E1F8	1 long	Player 6's colour
57E1FC	1 long	Player 7's colour
57E200	1 long	Player 8's colour
57E204	1 long	some counter
.
...		Unknown.
.
57E244	2736 (12*228*1)	Unit availability (unit+player*228)
.
...		Unknown.
.
580DDC	48 (12*4)	Men produced (does not include pre-placed units) by player
580E0C	48 (12*4)	Men owned by player (cumulative count, includes pre-placed units)
580E3C	48 (12*4)	Men (or units??) lost by player
580E6C	48	Unknown
580E9C	48 (12*4)	units score by player
580ECC	48 (12*4)	Kill score
580EFC	144 (3*12*4)	?? structures constructed ?? (1 long each for 12 players, seems to be repeated 3 times)
580F8C	48 (12*4)	?? structures lost ??
580FBC	48 (12*4)	?? structures razed ??
580FEC	48 (12*4)	buildings score
58101C	48 (12*4)	razings score
58104C	48	Unknown
58107C	48	Unknown
5810AC	48 (12*4)	Factories lost
5810DC	48	Unknown
58110C	48 (12*4)	Zerg supply
58113C	48 (12*4)	Zerg supply used
58116C	48 (12*4)	Zerg supply max
58119C	48 (12*4)	Terran supply
5811CC	48 (12*4)	Terran supply used
5811FC	48 (12*4)	Terran supply max
58122C	48 (12*4)	Protoss supply
58125C	48 (12*4)	Protoss supply used
58128C	48 (12*4)	Protoss supply max
5812BC	48 (12*4)	Custom score (1 long each for 12 players)
5812EC	10944 (228*12*4)	Number of units on the map (player + unit*12)
583DAC	10944 (228*12*4)	Number of units on the map (player + unit*12)
58686C	10944 (228*12*4)	Player kill counts (player + unit*12)
58932C	10944 (228*12*4)	start of deaths table (player + unit*12), 4 bytes each)
58BDEC	288 (12*24*1)	Techs available by player (SC techs only [0-23], tech+player*24)
58BF0C	288 (12*24*1)	Techs researched by player (SC techs only [0-23], tech+player*24)
.
58C050	552 (12*46*1)	Upgrade max by player (SC upgrades only [0-45], upgrade+player*46)
58C278	552 (12*46*1)	Upgrades researched by player (SC upgrades only [0-45], upgrade+player*12)
.
58C578	8 (8*1)	Force membership of each player
58C580	4 (4*1)	Force flags
58C584	120 (4*30)	Force names (30 bytes each, null-terminated strings)
58C5Fc	144 (12*12*1)	Player alliances (First 12 bytes are player 1's alliances, next 12 are player 2's, etc)
58C68C	48 (12*4)	Mission objectives string index for each player
58C6BC	4	Countdown timer value
58C6C0	4	Elapsed game time
58C6C4	4	Unknown
58C6C8	4	Unknown
58C6CC	4	Unknown
58C6D0	4	Leaderboard computer players enabled
58C6D4	1	Unknown
58C6D5	1	Unknown
58C6D6	2	Unknown
58C6D8	4	Unknown
58C6DC	4	Unknown
58C6E0	8 (8*1)	Pauses left for each player
.
58CC08	32	Switch states (1 bit per switch)
58CC28	5100 (255*20)	Locations (In [longs]: X Start, Y Start, X End, Y End, [shorts]: String, Flags)
58E014	4	Countdown timer paused
58E018	240 (12*20*1)	Tech available by player (BW techs only [24-43]) tech + player*20)
58E108	240 (12*20*1)	Tech researched by player (BW techs only [24-43]) tech + player*20)
.
58E240	180 (12*15*1)	Upgrade max by player (BW upgrades only [46-60]) (upgrade + player*15)
58E2F4	180 (12*15*1)	Upgrade researched by player (BW upgrades only [46-60]) (upgrade + player*15)
.
59B048	260 (65*4)	MapData.dat string pointers (points beyond data segment)
59BC70	571200 (1700*336)	UnitNode table
.
628140	90000 (2500*36)	Sprite array
.
653144	61 (61*1)	Upgrades.dat - upgrade max
653188	122 (61*2)	Upgrades.dat - mineral cost base
653208	122 (61*2)	Upgrades.dat - gas cost factor
653288	122 (61*2)	Upgrades.dat - gas cost base
653308	122 (61*2)	Upgrades.dat - unknown
653388	122 (61*2)	Upgrades.dat - time factor
653408	122 (61*2)	Upgrades.dat - mineral cost factor
653488	122 (61*2)	Upgrades.dat - label
653508	122 (61*2)	Upgrades.dat - Icon
653584	61 (61*1)	Upgrades.dat - Broodwar flag
6535C8	122 (61*2)	Upgrades.dat - time base
653644	61 (61*1)	Upgrades.dat - race
.
653Be0	88 (44*2)	TechData.dat - Unknown 5
653C38	88 (44*2)	TechData.dat - Gas cost
653C90	88 (44*2)	Techdata.dat - mineral cost
653CE8	88 (44*2)	Techdata.dat - Label
653D40	88 (44*2)	TechData.dat - unknown 6
653D98	44 (44*1)	TechData.dat - researched
653DC8	88 (44*2)	TechData.dat - energy cost
653E20	88 (44*2)	TechData.dat - research time
653E78	88 (44*2)	TechData.dat - icon
653ED0	44 (44*1)	TechData.dat - race
653EFC	44 (44*1)	TechData.dat - broodwar flag
653F28	130 (130*1)	Weapons.dat - damage factor
653FB0	260 (130*2)	Weapons.dat - target error message
654140	130 (130*1)	Weapons.dat - explosion type
6541C8	130 (130*1)	Weapons.dat - icon
6542D0	260 (130*2)	Weapons.dat - splash inner
6543D8	130 (130*1)	Weapons.dat - attack angle
654460	520 (130*4)	Weapons.dat - minimum range
654668	130 (130*1)	Weapons.dat - offset y
6546F0	520 (130*4)	Weapons.dat - missile sprite
6548F8	260 (130*2)	Weapons.dat - damage amount
654A00	130 (130*1)	Weapons.dat - coldown delay
654A88	130 (130*1)	Weapons.dat - missile type
654B10	260 (130*2)	Weapons.dat - splash medium
654C18	130 (130*1)	Weapons.dat - upgrade group
654CA0	130 (130*1)	Weapons.dat - type
654D28	260 (130*2)	Weapons.dat - label
654E30	130 (130*1)	Weapons.dat - special attack
654EB8	520 (130*4)	Weapons.dat - maximum range
6550C0	260 (130*2)	Weapons.dat - damage bonus
6551C8	260 (130*2)	Weapons.dat - splash outer
6552D0	130 (130*1)	Weapons.dat - launch spin
655358	130 (130*1)	Weapons.dat - offset x
6553E0	260 (130*2)	Weapons.dat - attack type
.
65D660	228 (228*1)	Units.dat - max hit air
65D748	456 (228*2)	Units.dat - vespene cost
65D910	228 (228*1)	Units.dat - Armor
65D9F4	4 (4*1)	Unknown
65D9F8	456 (228*2)	Units.dat - What sound start
65DBC0	228 (228*1)	Units.dat - Comp AI unit type
65DCA8	456 (228*2)	Units.dat - custom name
65DE70	456 (228*2)	Units.dat - build time
65E038	228 (228*1)	Units.dat - starting direction
65E120	228 (228*1)	Units.dat - broodwar flag
65E208	456 (228*2)	Units.dat - subunit 1
65E3D0	228 (228*1)	Units.dat - transport space
65E4B8	456 (228*2)	Units.dat - restriction flags
65E680	456 (228*2)	Units.dat - subunit 2
65E848	456 (228*2)	Units.dat - shield amount
65EA10	228 (228*1)	Units.dat - movement type
65EAF8	912 (228*4)	Units.dat - construction animation
65EE88	212 (106*2)	Units.dat - sound yes end
65EF60	456 (228*2)	Units.dat - Staredit availability flags
65F128	228 (228*1)	Units.dat - air weapon
65F210	1824 (228*8)	Units.dat - Unit boundaries (RECT structs)
65F930	212 (106*2)	Units.dat - Pissed sound end
65FA08	212 (106*2)	Units.dat - Ready sound
65FAE0	228 (228*1)	Units.dat - Action type
65FBC8	228 (228*1)	Units.dat - Size
65FCB0	228 (228*1)	Units.dat - Human AI Init Action
65FD98	912 (228*4)	Units.dat - Hit points
660128	384 (192*2)	Units.dat - Addon location
6602A8	912 (228*4)	Units.dat - Building dimensions
660638	456 (228*2)	Units.dat - What sound end
660800	228 (228*1)	Units.dat - Seek range
6608E8	228 (228*1)	Units.dat - Comp AI Init Action
6609D0	456 (228*2)	Units.dat - Portrait ID
660C80	228 (228*1)	Units.dat - Unit sight range
660D68	228 (228*1)	Units.dat - Ground attack action
660E50	456 (228*2)	Units.dat - Build score
661018	228 (228*1)	Units.dat - Armor upgrade group
661100	228 (228*1)	Units.dat - Ground weapon
6611E8	228 (228*1)	Units.dat - Group flags
6612D0	456 (228*2)	Units.dat - Mineral cost
661498	228 (228*1)	Units.dat - Ait attack action
661580	212 (106*2)	Units.dat - Unknown
661658	456 (228*2)	Units.dat - Unknown
661730	228 (228*1)	Units.dat - Unknown
661818	228 (228*1)	Units.dat - Unknown
661900	456 (228*2)	Units.dat - Destroy score
661AC8	228 (228*1)	Units.dat - Special ability flags
661E58	228 (228*1)	Units.dat - Transport size
661F40	228 (228*1)	Units.dat - Unit graphic
662028	228 (228*1)	Units.dat - Max hit ground
662110	228 (228*1)	Units.dat - Supply produced
6621F8	228 (228*1)	Units.dat - Unit has shield
6622E0	228 (228*1)	Units.dat - Idle action
6623C8	192 (96*2)	Units.dat - Infestation unit
662488	189 (189*1)	Orders.dat - Flag 4
662548	189 (189*1)	Orders.dat - Use weapon targeting
662608	189 (189*1)	Orders.dat - Flag 12
6626C8	189 (189*1)	Orders.dat - Flag 11
662788	189 (189*1)	Orders.dat - Animation
662848	189 (189*1)	Orders.dat - Tech
662908	189 (189*1)	Orders.dat - Group
662A88	189 (189*1)	Orders.dat - Can be interrupted
662B48	189 (189*1)	Orders.dat - Flag 7
662C08	378 (189*2)	Orders.dat - Flag 9
662CC8	378 (189*2)	Orders.dat - Label
662E48	378 (189*2)	Orders.dat - Emulated order
662F08	378 (189*2)	Orders.dat - Flag 10
662FC8	378 (189*2)	Orders.dat - Flags
663148	189 (189*1)	Orders.dat - Flag 8
663208	189 (189*1)	Orders.dat - Flag 5
6632C8	189 (189*1)	Orders.dat - Weapon
663388	189 (189*1)	Orders.dat - Flag 2
663448	189 (189*1)	Orders.dat - Flag 3
663508	387 (387*1)	Sprites.dat - Selection circle
663690	387 (387*1)	Sprites.dat - unknown
663898	387 (387*1)	Sprites.dat - HP bar length
663A20	387 (387*1)	Sprites.dat - Selection circle offset
663BA8	1034 (517*2)	Sprites.dat - image index
663FB8	517 (517*1)	Sprites.dat - visible
6641C0	3996 (999*4)	Images.dat - overlay 4
6651C0	999 (999*1)	Images.dat - floats
665548	3996 (999*4)	Images.dat - overlay 3
6664E8	3996 (999*4)	Images.dat - GRP file name
667488	999 (999*1)	Images.dat - Palette
667870	999 (999*1)	Images.dat - Palette type
667C58	3996 (999*4)	Images.dat - Overlay 2
668BF8	3996 (999*4)	Images.dat - Overlay 1
669B98	999 (999*1)	Images.dat - Shadow turns
669F80	3996 (999*4)	Images.dat - Overlay 0
66AF20	999 (999*1)	Images.dat - Unknown
66B308	3996 (999*4)	Images.dat - Overlay 5
66C2A8	999 (999*1)	Images.dat - image turns
66C690	3996 (999*4)	Images.dat - iscript
.
6C7240	209 (209*1)	Flingy.dat - movement control
6C7318	836 (209*4)	Flingy.dat - acceleration
6C7660	418 (209*2)	Flingy.dat - turning style
6C7808	209 (209*1)	Flingy.dat - turn radius
6C78E0	836 (209*4)	Flingy.dat - speed
6C7C28	209 (209*1)	Flingy.dat - unknown
6C7D00	418 (209*2)	Flingy.dat - sprite index

Modifying Supply Limits

Ever wanted to expand the 200 unit limit? Now you can!

Modifying Supply Limits

This really isn't that difficult... It just requires you to look a bunch of crap up in lists.

Note: Some things will add to another race's supply limits... (such as in my example screenshot the zerg have 1/2) I haven't looked into it very much, so I'm not exactly sure what causes it specifically.

1. Decide what you want your values to be.
As an example, I'll use Terran 1000 max with an initial 100 available for player 1.

2. Subtract 200 of the Max (and Max only!) as it is already available.
1000 - 200 = 800.

3. Use the Supply Modifier Unit List to find values that add up to what you want. Be sure to take note of whether or not what you are using is a building or unit as we will use this later!
"Nuclear Missile 400 Unit" Two will add up for my 800 Max.
"Citadel of Adun 100 Building" 100 for my initial available.

4. Use the Player Look-up List for the players you want.
Player 1:
Terran Available for Building: 109
Terran Limit for Unit: 217

5. Place your unit.
Place two Nuclear Missiles for player 217.
Place one Citadel of Adun for player 109.

http://www.maplantis.org/storage/wiki/SupplyLimit2.png (img: failed to get size)

Supply Modifier Unit List

Note: Units which do not add anything (0) have been removed. Resources have also been removed as they would require a player greater than 256 to use. They only add 5 anyways. ;)

Code

Player Look-up List

Note: For Player 5 and above, the Protoss Limit for units will require a player number greater than one byte. This is not possible. These are in square brackets.
Players 9-12 are useless and not included in this list.

Code

Player Look-up Form

Help you be more lazy. ;)
Supply Modification Lookup (External Link)

Ammo Systems

Ammo Systems

You'll find these kinds of triggers in some UMS maps-- particularly realistic horror (such as Raccoon City) and GTA maps. It can be pretty frustrating to implement this instead of a real Ammo System because it doesn't actually detect when a player shoots, but when a player kills a unit.

Regardless, this system makes it so you have to watch your ammo gauge, because if you don't you'll be caught in some crossfire without any ammo. Usually you'll be shooting at units with one-shot kills (with notable exceptions) and no buildings. Note: You cannot completely disable a unit from firing at all because the player can manually firing by clicking on the attack button and clicking on the target (although with hyper triggers, it makes doing this much harder with most units). Most of the time, you should set it so that the minerals and the gas is their ammo gauge - Minerals for the ammo in their current clip, and gas for clips they have stored.

Ammo Triggers

Ammo Initialization

Quote

Players
Force 1

Conditions
Always

Actions
Modify resources for Force 1: Set to 6 Ore //Ore is used as ammunition
Modify resources for Force 1: Set to 2 Gas //while Gas is used as Ammo Clips

This makes it so that they'll have six shots to start off with, and 2 extra clips, meaning 18 shots.

Ammo Usage

Quote

Players
Force 1

Conditions
Current Player Kills score is At least 1 //NOTE: This detects a player's kill, not a player's shot.

Actions
Modify score for Current Player: Set to 0 Kills //Resets the kill score to prevent endless loops.
Modify resources for Current Player: Subtract 1 Ore //Uses up ammo per kill.

There you go. This will take away ammo from the unit's ammo gauge.

Ammo Reload

Quote

Players
Force 1

Conditions
Current Player accumulates exactly 0 Ore //0 Ammo
Current Player accumulates at least 1 Gas //and at least 1 Ammo Clip are prerequisites for reloading.

Actions
Preserve Trigger
Display for current player: "Reloading..."
Set All Players to Ally // Temporarily allies the enemy to prevent free kills.
Wait for 2500 milliseconds //Reloading wouldn't make sense if it was instant (although I recommend you use Death Counters as timers)
Modify resources for Current Player: Set to 6 Ore
Modify resources for Current Player: Subtract 1 Gas
Set Force 2 to Enemy //Remarks enemies as hostile so you can shoot again.

You can take out the Wait trigger if you want. The Force 2 in the 2nd Set Alliance after the reload could be the enemies that you're firing at. Anyways, a player has to run out of ammo, doesn't he?

Out of Ammo

Quote

Players
Force 1

Conditions
Current Player accumulates exactly 0 Ore and Gas

Actions
Preserve Trigger
Set All Players to Ally

This is best used with Hyper Triggers.

Ammo Reload

Quote

Players
Force 1

Conditions
Current Player brings at least 1 men to 'retrieve ammo location'

Actions
Modify resources for Current Player: Add 3 Gas

And that's it. If you want to keep that location to always give the player ammo, preserve trigger.

Anti-Lifting off

The Terran building's Liftoff ability cannot be disabled directly, but there are several ways to prevent players from moving their buildings.

Simply destroying buildings that lift off is probably the easiest method. This can be done by placing enemy air attackers near the buildings, or by creating an air-only location over the buildings and killing anything that enter it. If you destroy a player's building for lifting off, you may want to recreate it on the ground.


Another way is to disable the buildings with the Set Doodad State action. This cannot be used on the Command Center, Starport, or Science Facility. Disabled buildings are unable to liftoff, but their other functions are disabled as well.

Placing the buildings as Unit Sprites and checking their Disabled property will also prevent them from lifting. As with the above method, disabling Liftoff this way will also disable all of the building's other functions. This can be used on all of the buildings. Additionally, this will cause the buildings to appear half-built.


Lastly, you can allow buildings to lift off, but move them back or destroy them if they leave a designated area. One thing to remember about doing this is that the Move Unit and Order actions are unable to effect buildings that have been given an order to land.

Damage Order of Operations

Damage Order

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

1. If the unit has shield HP, subtract shield armor upgrades from the damage.
2. Apply the damage to the shield HP.
3. If any damage remains, subtract the unit's armor from the damage.
4. 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.
5. Apply the remaining damage to the HP. If the remaining damage is one-half or less, it will do a half-point of damage.

Example 1:

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

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

Example 2:

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

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

Example 3:

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

1. 10 damage is reduced by 0. (No shield armor upgrades)
2. 0 shield points are removed from the Siege Tank. 10 damage remains.
3. 10 damage is reduced by 1. (Siege Tank base armor)
4. The damage is Concussive type and the Siege Tank is large (25% damage). 9 damage becomes 2.25 damage.
5. 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).