Starcraft Quirks and Nuances

Starcraft Quirks and Nuances
An eventual-comprehensive list of Starcraft's more counterintuitive and unknown details

• Hallucinations cannot be "Given"
  
• Hallucinations will not register in conditions (IE Bring and Command) but will be affected by actions (IE Move Unit, Move Location on Unit)
  
• Map Revealers cannot exist in a location (IE can be affected by Kill All Units and not Kill Units at Location)
  
• Broodlings created using "Create unit" trigger action will not expire, unless affected by the Modify Unit Hit Points action. Modify Unit Energy will not affect Broodlings. Broodlings created using 'Create Unit with Properties' will expire.
  
• Hero computer units will never stop following a unit unless directed otherwise by triggers or a new target is acquired. Hero computer units will never cast spells.
  
• Starcraft triggers affect units left to right across the location specified in. Ties are broken by whichever unit most recently occupied the tied x coordinate. If none of the tied units have ever moved (IE ties between two preplaced buildings) it is awarded to whichever has a greater index number (viewable in Scmdraft unit properties window)
  
• The 'Allies' denotation applies only to players that the trigger owner has Allied Victory with. A player can only have Allied Victory with all or none of his allies. Setting a player to 'Ally' will ally that player and turn Allied Victory off; setting a player to 'Allied Victory' will ally that player and turn Allied Victory on for the trigger owner.
  
• Triggers run top to bottom from Player 1 to Player 8. Checking in 'Force 1' is the same as checking in all the players in that force as the trigger owners (same rule applies for the other Forces and All Players)
  
• Neutral in Scmdraft is 'Player 12'. 'All Players' specifies players 1-12. Neutral Players includes players 9-11.
  
• Players that leave's units are given to Player 12 (Neutral). Any alliances the remaining player had with previous owner of the units will remain intact with the Player 12 units. Changing a player's alliance status with the previous owner of Player 12's units will likewise affect that player's alliance with those units.
  
• Zerg Eggs and Lurker Eggs will not register as 'Men' or 'Any Unit's in the Bring condition. The Zerg Egg will register as a Zerg Egg in conditions and the Lurker Egg will not register as a Lurker Egg. Preplaced Eggs will never finish morphing and cannot be canceled.
  
• Cocoons will register in triggers as a Cocoon, but not as 'Men' or as 'Any Unit's. Preplaced Cocoons will never finish morphing and cannot be canceled.
  
• Center view acts as a 'Wait' in Single Player until the screen has fully centered on the target location
  
• When units die they have one frame where they are at 0 health and designated to die. For that frame they are technically still there, have a collision area that can displace, can be detected with bring, can even be given (but cannot be moved) and will have already added a death to the death table. When you kill a unit with triggers, they are set to that 0 health dead-but-not-dead state. Since triggers run every other frame with hyper-triggers (but only on fastest as other settings have slower frame-rates), there is essentially a 50% chance that a unit killed (not by triggers) will be in that state when the triggers run. The "Kill" action isn't so much a "Kill" action as it is a "Sentence to death" action.
  
• You cannot create any of the extra units listed by Scmdraft that you can't create in the original StarEdit Campaign Editor, including extended heroes such as Raszagal, Aldaris and Arcturus Mengsk, and items like mineral chunks and vespene orbs.
  
• You cannot give units to a 'group' (IE Force 1, All Players, Foes), however units can be given from or created for groups.
  
• Units given to players 9-12 will retain the color of the previous owner, though they will reflect the P9-12 colors on the minimap.
  
• Players 9-11 do not have vision with themselves or any other player, and because they cannot own triggers they cannot be given vision.
  
• Some units, for example the Zealot and Dark Templar, have offset collision sizes from their true center (that locations will center to) and thus won't exist in an inverted location fit to their collision size that is centered on them.
  
• If there are no applicable units for a location to center on when prompted by the Move Location action, the location will center in the center of the location that it was specified for a specific unit type in; because map revealers are never in locations they are good units to use for centering a location on another.
  
• 'Highest Score' applies to all players that have tied for the highest score (same for lowest).
  
• Spider mines based on proximity rather than vision, and will attack cloaked units (but do not provide general detection). This means spider mines owned by P9-11 will attack their enemies despite that P9-11 do not have vision themselves.
  
• Dark Swarms and Disruption Webs are owned by default by Neutral (Player 12) and not by the player that cast them.
  
• Moving a power-up will move it directly on top of any ground unit that may be in the way of it's destination. The ground unit beneath will immediately walk away from the power up occupied space
  
• Units affected by spells that reveal them (IE plague, ensnare) will remain revealed even after burrowing until the effects wear out. Ensnare and plague will not reach burrowed units when cast.
  
• Pre-placed disabled unit-sprites have no collision box; that is other units can walk over the top of them, although they still cannot walk on other units. Disabled unit-sprite powerups therefore do not displace units they are moved on to.
  
• Several heroes have unusual properties; all hero ghosts have attack ranges of 6 instead of 7, the hero defiler has a larger collision box than normal units and Aldaris shares the same attack as Tassadar, so changing the values for 1 unit will affect the other. http://www.staredit.net/wiki/Heroes for a more detailed disparity listing.
  
• Using 'move unit' to move a unit to an implacable location will cause the unit to halt its current action. Implacable locations for ground units means any obstacle such as water or cliffs or simply an area crowded with other ground units, and air units can be halted by moving them to a crowded location such as a patch of lifted terran buildings. The most fool-proof way is to create a location and modify it's co-ordinates to be off-map, and move units to that. Units that are constantly moved to an implacable area (when hyper-triggers are active) will be unattackable (attacker's hits won't land), but will be able to shoot others. Scarabs moved to implacable locations will immediately detonate at their present location, which is a technique used in DDS.
  
• Giving a unit to another player and back to the original player will cancel any orders that unit was carrying out, as well as cause the player to lose selection on the unit. Buildings under construction will be cancelled and refunded, as will upgrades in progress.
  
• Lurkers only attack while burrowed, and the CPU players will only burrow a lurker when it is idle or automatically responding to the presence of enemy units. Ordering a lurker owned by CPUs to move, attack or patrol to a location when it is burrowed will cause the lurker to un-burrow and move to the destination, ignoring any enemies it encounters on the way, and it will not burrow again until it reaches its destination (or has its orders removed by some other means).
  
• Ordering units to 'Attack' to a location through the order action will only attack units that prohibit them from reaching their destination. The 'Patrol' to order will order the applicable units to attack all enemy units along the way and carry out the patrolling back and forth as expected. 'Move' order behaves as expected, where the units won't attack on their way to their destination.
  
• Moving a unit with the 'Move Unit' action will cause it to enact its next waypoint order (orders given with shift to be carried out sequentially) if it has one. Ordering a unit with the 'Order' action will cancel all current and waypoint orders.
  
• Deaths for P9-12 can be read in conditions but can not be altered with the 'Set Deaths' action. They will accurately represent the deaths their units have amassed.
  
• The Ai script "Turn OFF/ON shared vision" is a little counter-intuitive as well. For example: Player 1 running turn OFF shared vision for Player 2 will disallow Player 1 from seeing Player 2's view.
  
• Scarabs can be detected with the "bring" condition while they are inside of a reaver; thus a location smaller than the reaver, centered on a reaver, can detect when a reaver fires a scarab. This knowledge is implemented in DD systems. Similarly the same goes for carriers and interceptors.
  
• Scarabs cannot be directly given, instead, giving a Reaver will give all of its active scarabs.
  
• Locations created in SCMDraft appear to be one pixel shorter on the bottom and right sides. This applies to inverted locations as well. For clarification, I do not mean the edges labeled "Bottom" and "Right", but rather whichever bar is on the bottom and right; It could be "Top" and "Left" (if it were inverted).
  
• Banning a player in the game lobby while their download is at the 99th percentile (and sometimes less) will still give them the map.
  
• Terran add-ons cannot be given normally. You must instead give the building they are attached to and the addon will also be given.
  
• Nuclear missiles can be automatically created by giving the nuclear silo to a CPU player and having that CPU run the "Broodwar Terran 2 - Town B" AI at a location on the nuclear silo; note that this is a campaign AI and is said to have other actions also tied to it such as creating ghosts, although in my testing I did not find this to be an issue. The command center and nuclear silo can then be given back to a human player and launched by that player's ghosts, however the nuke inside the silo will still be owned by the CPU. You can remedy this by using a trigger at the silo location that gives all nukes owned by CPU player to the human player - when the nuke is launched it will briefly show as the CPU colours before being given to the human player. Note that nuclear missiles cannot be detected as [Any unit] or [Men], you must use Nuclear Missile. Creating a nuke for the player in this way will not provide the normal "Nuclear missile ready" audio prompt, so it is recommended that you play this via trigger if required. There appears to be no other way to automatically arm a nuclear silo: add x to unit hanger and creating/giving nuclear missiles directly does not work.
  
• Powerups will not be detected by [Any unit] in conditions, instead you must check for the powerup itself. [Any unit] will work as actions on powerups, however.
  
• Incomplete buildings will not be counted with "At least" or "Exactly" conditions, but they will be counted for "At Most" conditions; unfortunately this is generally not very useful. Incomplete buildings will be considered for actions.
  

Randomization

Games often need to make use of random numbers. Use one of the methods described below if your map requires randomization.

[h1]Switch Methods[/h1]
Switches have two states, CLEAR (0) and SET (1).
Switch randomization is a built-in function of the Set Switch trigger action.
If two different outcomes is not be enough for you, there are ways of generating higher random numbers using switches.

[h2]Multi-Switch[/h2]
This method will allow you to create a random number within the range of zero to some power of 2.
Here is a list of how many switches you should use in this method, based on the number of outcomes you need:

Code

After you determine how many switches you will need, make a trigger to randomize that amount of switches.
In this example, we need to select one of the 8 players to go first. There are 8 outcomes, so we will be using 3 switches.

Quote

Actions:
- Randomize Switch 1.
- Randomize Switch 2.
- Randomize Switch 3.

With three switches (bits) randomized, there are 8 possible outcomes:

Quote

000
001
010
011
100
101
110
111

Or, in other words:

Quote

Switch1 is CLEAR, Switch2 is CLEAR, Switch3 is CLEAR.
Switch1 is SET, Switch2 is CLEAR, Switch3 is CLEAR.
Switch1 is CLEAR, Switch2 is SET, Switch3 is CLEAR.
Switch1 is SET, Switch2 is SET, Switch3 is CLEAR.
Switch1 is CLEAR, Switch2 is CLEAR, Switch3 is SET.
Switch1 is SET, Switch2 is CLEAR, Switch3 is SET.
Switch1 is CLEAR, Switch2 is SET, Switch3 is SET.
Switch1 is SET, Switch2 is SET, Switch3 is SET.

Create a trigger for each possible switch outcome.
For out example, we will need 8 triggers:

Quote

Conditions:
- Switch1 is CLEAR.
- Switch2 is CLEAR.
- Switch3 is CLEAR.
Actions:
- (Player 1 goes first)

Quote

Conditions:
Switch1 is SET.
Switch2 is CLEAR.
Switch3 is CLEAR.
Actions:
- (Player 2 goes first)

Quote

Conditions:
Switch1 is CLEAR.
Switch2 is SET.
Switch3 is CLEAR.
Actions:
- (Player 3 goes first)

Quote

Conditions:
Switch1 is SET.
Switch2 is SET.
Switch3 is CLEAR.
Actions:
- (Player 4 goes first)

Quote

Conditions:
Switch1 is CLEAR.
Switch2 is CLEAR.
Switch3 is SET.
Actions:
- (Player 5 goes first)

Quote

Conditions:
Switch1 is SET.
Switch2 is CLEAR.
Switch3 is SET.
Actions:
- (Player 6 goes first)

Quote

Conditions:
Switch1 is CLEAR.
Switch2 is SET.
Switch3 is SET.
Actions:
- (Player 7 goes first)

Quote

Conditions:
Switch1 is SET.
Switch2 is SET.
Switch3 is SET.
Actions:
- (Player 8 goes first)

If you need a number of outcomes that is not a power of 2, use the next-highest power of 2, and just re-randomize for all the outcomes you aren't using. It will eventually land on a valid outcome.

[h2]One Switch[/h2]
This method will allow you to create a random number within the range of zero to some power of 2.
It is possible to use just one switch to make a random number. This method can be easier to use than the multi-switch method because it stores the outcome in a counter, instead of in a bunch of switches. You can use 'at least' and 'at most' with a death counter.

Start by randomizing the switch.

Quote

Conditions:
- Always.
Actions:
- Randomize Switch 1.

If the switch is set, add 1 to your counter.

Quote

Conditions:
- Switch 1 is SET.
Actions:
Modify death counts for Player: Add 1 for Unit.

Randomize the switch again.

Quote

Conditions:
- Always.
Actions:
Randomize Switch 1.

If the switch is set this time, add 2 to your counter.

Quote

Conditions:
- Switch 1 is SET.
Actions:
Modify death counts for Player: Add 2 for Unit.

Randomize the switch **again**.

Quote

Conditions:
- Always.
Actions:
Randomize Switch 1.

If the switch is set this time, add 4 to your counter.

Quote

Conditions:
Switch 1 is SET.
Actions:
Modify death counts for Player: Add 4 for Unit.

Now the death counter for 'Unit' will have a random number in the range of 0-7.
Use the Deaths condition to detect the number.

If you want to make a random number in a higher range, keep randomizing the switch and adding the next highest power of 2 to the counter.
See the list above for how many outcomes you get for the amount of times you randomize the switch.

[h1]Other Methods[/h1]
There are some easier, but less accurate, methods of getting random numbers.
View these methods as making 'ever-changing' numbers, rather than actual random numbers.

[h2]Cycling Counter[/h2]
The numbers you get from this method will not be random, but if you use some kind of user input, it will be an unpredictable number. (Example: A human player has to take a unit to a beacon to activate the trigger)

Create a trigger that always adds 1 to a counter.

Quote

Conditions:
Always.
Actions:
Preserve trigger.
Modify death counts for Player: Add 1 for Unit.

Also make a trigger that resets the counter to 0 when it goes past a certain range. Our range is 0-7, so 8 is out of bounds.

Quote

Conditions:
Player has suffered At Least 8 deaths of unit.
Actions:
Preserve trigger.
Modify death counts for Player: Set to 0 for Unit.

Use the Deaths condition to detect the number. Make a trigger to detect each possible outcome.
The number you get will depend completely on when the trigger is activated.
Use hyper triggers for this method.

[h2]Roaming Unit[/h2]
Units using the junkyard dog AI script move around in an unpredictable manner.
To use this to get a number, first make an area for the unit to move around in, and put locations that cover all parts of it.


Critters are not recommended for this because their movements are not random (they move up and left over 90% more often than they move down or right). Also, units using the junkyard dog AI do not move randomly when they are near the edge of the map (they have an extremely high chance of moving away from the edge).

Use the Bring condition to detect which location the unit is touching. Make different outcomes based on the location.

It is possible for the unit to remain in the same location for a long time.
The quality of this method is questionable. Its usefulness is limited.

EUDs

[h1]What Will I Need?[/h1]

First off, it is recommended that you download the following programs, which are free.

ArtMoney or Cheat Engine
EUD Trig
SCMDraft 2

Once you have all of these programs downloaded, unzipped, and installed you can continue.

[h1]What Do I Do First?[/h1]

First off, you need to make sure that what you want to search for is something that can actually be read by StarCraft's memory. Although you can only use EUD Conditions in the current patch (1.16.1) you can still do some pretty cool things. If you want to widen your array, simply downgrade to version 1.12 or less using SCDG3 by FaRTy, or use the new EUD Action Enabler. Once you have figured out what you want to search for run your StarCraft.exe and then the Artmoney.exe files. In this tutorial I will be showing you how to search for a units hit points.

Once you have both of the programs open go to Artmoney and "Select process" bar and select "Brood War" Now that you have that done, you should make a simple map which features two units. One of them that you will try to detect is HP and the other to decrease its HP. In This test we will be using a "Terran Marine" and attacking it will be a modified "Terran Ghost" I chose to modify its attack to 1 so I don't kill the "Terran Marine" too fast.

Now that you have you completed these steps you should now open the game and start playing your map.

[h1]Searching For An Address[/h1]

[h2]First Search[/h2]

With both Artmoney and StarCraft running and while in a game, click on the "Search" button in Artmoney. This will bring up another window titled "Search ( Step 1 )" You will notice that you have different types of searches you can proceed with, but for this one, you will need to use "Exact value". Now you want to try to search for the current Hit Points of the "Terran Marine". To do this input the current HP of the "Terran Marine", normally 40. All you have to do now is just hit "ok" and the left most tree should be populated with addresses followed by there byte value. You will also notice that there is a lot of values that will populate your list, this is normal of most first searches.

[h2]Filter 1[/h2]

Now that you have populated the list with the search for "40", you now need to go into StarCraft and decrease the Terran Marine's hit points by what ever variable, in this test we will just attack the Terran Marine enough to decrease its hit points by 1 making its new hit points 39. Now that this is completed, go back into Artmoney and click on the Filter button right next to the Search button. This time instead of the original search of 40, you should now search for the new hit points of the Terran Marine, in this case it will be 39. Enter the number and hit OK. You will now notice that the list is decreased dramatically this time. If you messed up, or it comes back saying something like "there were no results for your search", simply repeat steps 1 and then step 2 again. Note: Searching and Filtering will not always work every time you start a Search, or Filter more in depth for your address. Now that we have the First Filter complete, we can now go on to the next step.

[h2]What Now?[/h2]

With the First Filter complete we now decreased the list from many addresses to just 2 this time. Now instead of Filtering the search we now want to find the address with the 2 byte value. To do this simply click on the value (anywheres in the box) and click the top red arrow (add only selected) This should move that specific address with its value and some other custom information into the bigger window. Now what you do is click on the number under the Value in the table. You can now type in a number to test and see if this is the correct address for the Terran Marine's hit points. The Value was 39 and now we will make it 60, just for fun. Now after the number is inputed, go into StarCraft again and view the Terran Marine's hit points. If it says 60/40, or what ever you inputed, you will know you have the correct address for the Search. If any of this has not worked for you, simply restart the map and start over from step 1. NOTE: It will not always work for you.

[h1]Inputting The Address[/h1]

Now that you have the address, for me its "0059CC99" now you need to do some calculations. EUDTrig 1.3 can do some of this calculation for you. However, it is still important to understand how the math explained below works.

The formula for creating an EUD condition is Memory Address = Death Table Start + (4*Player) + (48*Unit:ID). The Memory Address is the address you just found with ArtMoney. The Death Table Start is the lowest readable address in StarCraft's RAM (with extended unit deaths), and is equal to 0x0058A364, or in decimal 5808996. The Player is simply the player number for the condition you are making: e.i. a condition for Player 1 would make Player in the equation equal to the number 1. Unit:ID is the ID for the unit you are using to create the condition. The memory condition in newer versions SCMDraft 2 uses the Terran Marine to create EUD conditions. The ID of a Marine is 0, so you can just change (48*Unit:ID) to 0 for this equation. Once you convert your address into decimal format, you can quickly solve this equation by using this simplified form: P = (Address - Death Table Start) / 4. The number calculated here will tell you how to construct your comparison in the Memory condition.

[h2]What To Do With The Information?[/h2]

After you complete your calculation and solve for your value, you can end up with a few different numbers in the decimal. Whatever ends up in the decimal will tell you how to create your comparison.

In the case of a value with a decimal, an even number means it's divisible by 4 and you want to just simply detect the exact value of HP (easiest by far). A .25 at the end of your value means you're looking for byte 2, so you have to multiply your desired HP amount by 256 (256=1 hp, 25600=100 hp). .5 means you're looking for byte 3, so multiply by 256^2. .75 you will probably never encounter, and you just multiply by 256^3.

Deaths read every 4 bytes. That means they actually read 4 bytes, no matter what is there. In the case of HP, HP is split up into 4 bytes (lucky us!).

Zerg HP regeneration is basically adding 4 to this number every frame. Once this byte reaches 256, it loops back to 00 and adds 1 hp that you can actually see in game. The second byte through the fourth byte are all the HP that you see in game. If a marine has 100 hp, it's actually got a 100 in the 2nd byte, and 00 in the first byte.

So now you take your solved value, which is 19021.25 in this example, and place it in the first section of the Memory condition in SCMDraft. The HP value for this unit is in the second byte, as denoted by the .25, and as denoted by the red 00's in EUDTrig. When you place this value into SCMDraft the .25 is shaved off - that is perfectly fine; EUDTrig doesn't even show you the .25. See Byte Values below for more information.

Since the HP for this particular example is in the second byte, that means you will multiply whatever HP amount you want to detect by 256. Here is a complete condition for detecting 40 HP for the unit in our example: Memory(19021, Exactly, 10240);. Take note that the 10240 is really 40 * 256.

[h2]Byte Values[/h2]

Byte Offset: 00 00 00 00 00 00 00 00 = 0x01 multiply by 1
Byte Offset: 00 00 00 00 00 00 00 00 = 0x02 multiply by 2^8
Byte Offset: 00 00 00 00 00 00 00 00 = 0x03 multiply by 2^16
Byte Offset: 00 00 00 00 00 00 00 00 = 0x04 multiply by 2^38
Byte Offset: 00 00 00 00 00 00 00 00 = 0x05 multiply by 2^40
Byte Offset: 00 00 00 00 00 00 00 00 = 0x06 multiply by 2^48
Byte Offset: 00 00 00 00 00 00 00 00 = 0x07 multiply by 2^56

[h2]If All Else Fails...[/h2]

When in doubt and all else fails, make a topic in the UMS Mapmaking Assistance thread for specific questions or uncertainty.

[h2]Extra information[/h2]

Quote from O)FaRTy1billion

Not including single-player actions (for obvious reasons), these are all of the actions will not drop (brute-testing, ftw):
Preserve Trigger, Wait*, Transmission, Play WAV, Display Text Message, Center View, Set Mission Objectives, Set Switch*, Set Countdown Timer*, All Leader Board (and Goal), Set Score*, Minimap Ping, Talking Portrait, Mute Unit Speech, Unmute Unit Speech, Move Location*, Set Invincibility**, Set Deaths*, Comment, Pause Timer*, Unpause Timer*.

Quote from a text file I wrote a while ago with this information

* Be cautious if you have any other desynching triggers that are dependant on these or use them in any way because they may cause a desync.
** Set Invincibility wont desync by itself, but if you target a unit that was effected by the action then it will desync.

[h2]Video Tutorial[/h2]
This video provides an animated tutorial of how to use artmoney to search for an address.