SPK Format

Word = 2 Bytes
Long = 4 Bytes

Header/Bitmap References

• word - Number of Layers
  
• n words - (1 word for each layer) Number of images in the layer
  
• 1 struct for the total number of images in all layers:
  • word - Star X Position
    
  • word - Star Y Position
    
  • long - Bitmap Offset
    

Bitmap Structure

• word - Bitmap Width
  
• word - Bitmap Height
  
• n bytes - (width*height bytes) Image Data (0 = transparent)
  

cmdicons.grp

Unit Images

the first 195 images are correspond to unit ids in units.dat and are the outlines that appear in the selected unit panel in the middle of the hud while playing.
e.g. 0 = Terran Marine, 32 = Firebat, 84 = Protoss Observer.

note: some images are omitted and have placeholder images that read "BLANK" because they are not selectable.

Command Buttons

the rest of the images are the buttons used for unit commands. order pattern unknown.

Map Limits

# Location limit: 255 (Including Anywhere)
# String limit: 1024 in StarEdit/XtraEdit (Variable in other editors, see Strings)
# Unit HP range: -8388608 to 8388607 1/2
# Protoss Shield range: 0 to 65535
# Mineral/Gas cost range: 0 to 65535
# Build time range: 0 to 65535
# Armor range: 0 to 255 (+255 with upgrades)
# Upgrades range: 0 to 255
# Resource range for Mineral Fields and Geysers: 0 to 65535
# Damage range: 0 to 65535
# Sprite limit: 499
# Staredit sprite limit: 250
# Staredit unit limit: 1650
# Starcraft Unit limit: 1700
# Starcraft sprite limit: 2500
# Starcraft image limit: 5000
# Starcraft weapon limit: 100, cutoff of 80 for Valkyrie
# Number Value (Wait, set deaths, set mineral amount, scores, etc.) range: -2147483648 to 2147483647
# Min working map size: 1x6
# Max working map size: 256x256

Sharing Minerals

players in the force share the resources.

this system uses 6 Death Counters... with Binary Countoffs... like this http://www.staredit.net/wiki/Changing_Minerals_Mined

3 death counters for minerals and 3 for gas

DcA = Previously Owned Minerals (-cantina)

DcB = Temporary counter for minerals (-cave)

DcC = Temporary counter to subtract minerals (-ruins)



1. transfer DcA and current minerals to DcB.

--This will empty whichever is lowest, and leave the higher one with the difference.

2. If there are minerals remained, they are newly mined minerals. Add them as DcB to all players in the force.

--Now the newly mined ores are acquired by all players

3. If DcA's remained, add them ' DcB to current player and the DcC to the force

--Decrease the same amount of minerals for all players as used

4. return the minerals/DcA in DcB.



5. transfer the DcC to minerals/DcA at a 1:(-1) ratio





Demonstration Map : share resources

Port forwarding

To make it so other people can join your games do the following:

1. Go to Control Panel->Network Connections and double click on your network connection. Click the tab that says Support. You should see something like this:


2. Type the address given as Default Gateway into your web browser. You should be prompted for a password, like so:


3. If you don't know the username/password for your router, it is probably the default. Find the default password for your router here.

4. Find a page labeled either Port Forwarding, Applications, or Virtual Servers. StarCraft uses ports 6112 to 6118 so specify that as the port range. For IP address, put your IP address from Step 1. Protocol should be Both or TCP+UDP.


5. Press Save or Apply and you're done.

Multiple computers on the same network

StarCraft is not designed for several PCs sharing the same internet connection. There is a non-supported way, though, which may work out for you. It will require you to modify the Windows Registry. If you are not familiar with editing the registry, ask someone for help.

On one computer of your choice click Start, Run..., type "regedit" and press Enter.

Go to HKEY_CURRENT_USER\Software\Battle.net and click on "Configuration". On the right half of the window do a right-click and create a new DWORD value. Call it "Game Data Port". Then right-click on the newly created value and select "Modify". In the new window, click on Decimal (not Hexadecimal) and enter 6113 as value. Apply the settings, then close the registry again.

This computer will now use port 6113 on Battle.net (applies to StarCraft and maybe to Diablo II as well, but definitely not to Warcraft III). Repeat the procedure for any additional computers that may be behind the router, but use a different port value then (6114, 6115, 6116, ...). Keep in mind that each computer will have to have a different port value assigned. The default port value is 6112, so one computer will use this port by default, which is perfectly fine (since you will not need to modify anything here! :) ).


In addition, please make sure that ports 6112 up to 6119 TCP/UDP are forwarded ("opened") on your router. Your router's manual and/or the the manufacturer's website surely offer help on how to forward ("open") ports.

Queue / Exclusive Triggers

Queue or Exclusive Triggers
by SonnieInn


"Queue" or Exclusive Triggers is a good method to use if you want to:
- Avoid conflicting triggers / conflicting conditions (for example: due to conflicting timing)
- Place priority on a trigger to be activated before another trigger which meets the same conditions
- To allow only the working of one trigger which meets the same conditions as any other trigger
- To skip certain triggers (going down the list of triggers) which meet equal conditions
- To enable or disable certain triggers or groups of triggers during the working of a particular trigger
- "Wait" conditions (as opposed to wait actions)
- "One Trigger at a Time Please"

This method is very effective when dealing with timing glitches of triggers which meet the same conditions or of a pair of triggers in which the later triggers' conditions depend on the previous triggers' actions. For example, when you don't want the later triggers to activate before the 1st trigger is finished.


How to:
One of the best things to use as a "queue" or exclusive trigger, is the death count. My favorite is the death count of the start location (you can use whatever unit you like).


Example:
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
Trigger("Player 1")
Conditions:
Deaths("Player 8", "Start Location", Exactly, 0);
Bring("Player 7", "Zerg Zergling", "Location A", Exactly, 1);
Switch("Switch0", set);

Actions:
Set Deaths("Player 8", "Start Location", Set To, 1);
Create Unit with Properties("Current Player", "Vulture Spider Mine", 1, "Location A", 1);
Set Switch("Switch0", randomize);
Set Deaths("Player 8", "Start Location", Set To, 2);
Preserve Trigger();
--------------------------------------------

Trigger("Player 1")
Conditions:
Deaths("Player 8", "Start Location", Exactly, 0);
Bring("Player 7", "Zerg Zergling", "Location A", Exactly, 1);

Actions:
Set Deaths("Player 8", "Start Location", Set To, 1);
Give Units to Player("Player 7", "Player 8", "Zerg Zergling", 1, "Location A");
Set Switch("Switch0", randomize);
Set Deaths("Player 8", "Start Location", Set To, 2);
Preserve Trigger();
--------------------------------------------

Trigger("Player 1")
Conditions:
Deaths("Player 8", "Start Location", Exactly, 2);

Actions:
Set Deaths("Player 8", "Start Location", Set To, 0);
Preserve Trigger();
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv

In the example above, I have 3 triggers:
- The 1st trigger and the 2nd trigger both have the exact same conditions, (except that the 1st trigger has one more additional condition: The Switch).
If Switch 0 is set, then the 1st trigger will be activated.

- The 2nd trigger will be activated regardless. This means that both triggers will be active at the same time (I don't want to be).

- The death count of the Start Location for player 8 is used in both triggers (in the conditions, and at the beginning and end of the actions) to make it exclusive; that is: Only ONE trigger will be activated while the Other Skipped.

- Notice that when Switch 0 is set, the 1st trigger is activated; and the death count changes to exclude the very next trigger.

- The 3rd trigger I used is only to "reset" the "queue".

Queue or Exclusive Triggers

Queue or Exclusive Triggers
by SonnieInn


"Queue" or Exclusive Triggers is a good method to use if you want to:
- Avoid conflicting triggers / conflicting conditions (for example: due to conflicting timing)
- Place priority on a trigger to be activated before another trigger which meets the same conditions
- To allow only the working of one trigger which meets the same conditions as any other trigger
- To skip certain triggers (going down the list of triggers) which meet equal conditions
- To enable or disable certain triggers or groups of triggers during the working of a particular trigger
- "Wait" conditions (as opposed to wait actions)
- "One Trigger at a Time Please"

This method is very effective when dealing with timing glitches of triggers which meet the same conditions or of a pair of triggers in which the later triggers' conditions depend on the previous triggers' actions. For example, when you don't want the later triggers to activate before the 1st trigger is finished.


How to:
One of the best things to use as a "queue" or exclusive trigger, is the death count. My favorite is the death count of the start location (you can use whatever unit you like).


Example:
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
Trigger("Player 1")
Conditions:
Deaths("Player 8", "Start Location", Exactly, 0);
Bring("Player 7", "Zerg Zergling", "Location A", Exactly, 1);
Switch("Switch0", set);

Actions:
Set Deaths("Player 8", "Start Location", Set To, 1);
Create Unit with Properties("Current Player", "Vulture Spider Mine", 1, "Location A", 1);
Set Switch("Switch0", randomize);
Set Deaths("Player 8", "Start Location", Set To, 2);
Preserve Trigger();
--------------------------------------------

Trigger("Player 1")
Conditions:
Deaths("Player 8", "Start Location", Exactly, 0);
Bring("Player 7", "Zerg Zergling", "Location A", Exactly, 1);

Actions:
Set Deaths("Player 8", "Start Location", Set To, 1);
Give Units to Player("Player 7", "Player 8", "Zerg Zergling", 1, "Location A");
Set Switch("Switch0", randomize);
Set Deaths("Player 8", "Start Location", Set To, 2);
Preserve Trigger();
--------------------------------------------

Trigger("Player 1")
Conditions:
Deaths("Player 8", "Start Location", Exactly, 2);

Actions:
Set Deaths("Player 8", "Start Location", Set To, 0);
Preserve Trigger();
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv

In the example above, I have 3 triggers:
- The 1st trigger and the 2nd trigger both have the exact same conditions, (except that the 1st trigger has one more additional condition: The Switch).
If Switch 0 is set, then the 1st trigger will be activated.

- The 2nd trigger will be activated regardless. This means that both triggers will be active at the same time (I don't want it to be).

- The death count of the Start Location for player 8 is used in both triggers (in the conditions, and at the beginning and end of the actions) to make it exclusive; that is: Only ONE trigger will be activated while the Other Skipped.

- Notice that when Switch 0 is set, the 1st trigger is activated; and the death count changes to exclude the very next trigger.

- The 3rd trigger I used is only to "reset" the "queue".

Inverted Locations

Inverted Locations

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

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

A simple way of saying it, is that with a regular location, a piece of the unit merely needs to be inside the location. With an inverted location, the entire location needs to be inside the unit.

The advantage of using inverted locations is that they can be used to detect if a unit is in an exact position (if fitted to that specific unit) and thus can be deployed for near instant unit movement detection. They can also be centered on units near the edges of the map without being pushed off the edges. Other uses include varying degrees of unit movement.

¹ A "newb-friendly" three step guide for creating inverted locations:

• 1. Create a location in your map editor (Scmdraft 2)
  
• 2. Go to its properties (double click or select and press 'Enter')
  
• 3. Swap the values of right and left borders and swap the top and bottom border values. (It should no longer be selectable in the map window- you must find it in the Location listing at the left and press enter to edit it now).

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


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


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


Specific application triggers

Detecting unit movement
One of the reasons why inverted locations are used is because they can detect if a unit has moved much faster than with a 1x1 pixel location. To do so, you must make it so the inverted locations' edges is exactly (or a bit smaller) the same size as the unit's one (which is represented by the green rectangular surrounding the unit when you're placing it).
Then, with this, you must use two little triggers:

Quote from Trigger 1: Center the location over the unit ONCE

Conditions:

• Always

Actions:

• Center location labelled 'inverted location' on 'custom unit' owned by 'Player x' at 'Anywhere'

Quote from Trigger 2: Detect when the unit leaves the location

Conditions:

• 'Player x' bring 'at most' '0' 'custom unit' to 'inverted location'

Actions:

• Move '1' 'custom unit' at 'Anywhere' to 'inverted location'
  
• 'Set' 'custom unit has moved'
  
• Preserve Trigger

You may now use the 'custom unit has moved' switch as 'Set' like if it was the same thing as if the unit has moved.

Detecting unit stopping
The second most common use for inverted location is to make life easier when you want to detect when a unit has stopped moving. To do so, you must have these triggers (in this order):

Quote from Trigger 1: Detect if the unit is STILL in the location

Conditions:

• 'Player x' bring 'at least' '1' 'custom unit' at 'inverted location'

Actions:

• 'Set' switch 'unit has stopped'
  
• Preserve Trigger

Quote from Trigger 2: Center the location

Conditions:

• Always

Actions:

• Center location labelled 'inverted location' on 'custom unit' owned by 'Player x' at 'Anywhere'
  
• Preserve Trigger

You may now use the 'unit has stopped' switch as 'Set' like if it was the same as if the unit has stopped.

Waypoint Casting system

Waypoint Casting system
by bg-payne (which means "may not be totally right")
P.S. This require the use of Inverted Locations

How to create one in the editor

• 1) Place a caster and 2 units (we'll call them respectively 'stable unit' and 'moving unit')
  
• 2) Center a location over the caster permanently and order the 'moving unit' to move to a destination. Once it reaches that destination, make it patrol between it initial position and this point.
  
• 3) Have a trigger detecting if the 'stable unit' has moved. If so, set a switch (which will represent if a player has casted a spell) and give the 'stable unit' to a "disabling" player (p9, p10 or p11). Also move the 'moving unit' over the caster, wait(0) (very important), and then give the 'moving unit' to the same disabling player.
  
• 4) Use an inverted location to detect when the unit has stopped, which would mean the target has been reached.
  
• 5) Do what you wanted to do when the spell would reach it target and then give back the 'stable unit' to the player and move back the 'moving unit' to it's patrolling area (don't forget to give it back to the player too)

Vital informations

It is highly recommended to...

• 1) Use an air unit that CAN attack ground and air units as the 'stable unit' (ex: Wraith)
  
• 2) Use an air unit that CANNOT attack the ground units (and the air too if ever you have air units as enemies) (ex: Scourge)

+ If both units cannot attack ground units, you'll receive an error message if you directly click (in-game) on an enemy.
+ If the 'moving unit' can attack the ground units, if you directly click on an enemy, it'll attack in (which means it will also stop before reaching your it ordered target).

• 3) Do not give "disabled" units to the neutral player, give them respectively to the players 9, 10 and 11

+ If you do not do this, some triggers may mess up when someone will leave.

• 4) Be sure that the 'stable unit' and the 'moving unit' are disposed far enough from each other

+ Else, you will get a screwed order command because when units are too near to each other, they keep their initial formation while moving instead of going to the targeted point, get it?

• 5) Make the path of the 'moving unit' unit long enough

+ Casting a spell when the 'moving unit' is reaching the "point B" will cancel the spell

• 6) Use the 'move unit' command to teleport the moving unit that has reached the point B to the point A and order it to move from A to B

+ Else, you get a higher chance of failure when you cast it (will be explained into "Glitches" category).

• 7) Make in sort that the 'stable unit', once given to a "disabling player" (p9, p10 and p11), won't move (you can simply use a 'move unit' trigger to keep it on place)

+ If you do not do so, a player setting multiple waypoints would make the 'stable unit' move out and it would screw the whole system.

• 8) Do not forget to set limits!

+ Else, the player would be able to send their spell into the area where the 'moving unit' and the 'stable unit' are, which would screw it up.

Glitches (need someone to work on those and fix them)

• 1) The 'moving unit' is keeping its initial "inertia" (which is to move to the "Point B") when it is casted (for a very short moment). This means that if you cast it to your left, it will kind of spin a round in the air before starting to move to the point, which reduces it effectiveness...
  
• 2) If you cast the spell when the 'moving unit' reaches the point B, the cast will get canceled...

Cons

• 1) There is no instant effect (except if you do it so it affects in radius from the hero). The spells can only: move from the caster to their destination and then effect, effect as long as they are casted (aura), affects unit within a certain range (radius) and affect all through its way until it stops.

To have an instant effect, you would need to either use FRAGs or a system like the Dark Swarm detection. Sorry :P

How it works in-game

• 1) Select both 'moving unit' and 'stable unit' (you may need to use Shift if they are too far from each other)
  
• 2) Hotkey them
  
• 3) Shift+Click anywhere (OR Double-Click)
  
• 4) Enjoy

The concept

The concept is centered on Starcraft's waypoint system. For those of you who don't know, the waypoint system is essentially a "to-do" list for units. When you order a unit while holding shift, it sets destinations/commands for that unit, which performs each in order. An other important information is that when you move a unit or give it to an other player, it only cancels it actual order, keeping the next orders in memory.
With this in mind, it's easy to figure out how the system actually works:
The 'stable unit' would simply act as a "cast detection": if it has moved, it's because the player wants to target something/somewhere.
The 'moving unit' had to be in movement when you casted because it is that order that gets canceled by Starcraft so when you move it over the caster, it will directly execute the next order, which is the one you've just done.


Thanks to Lethal_Illusion, Kaias and qPirateKing for thinking of this.
Waypoint casting system <-- The topic

A map of a mix of the Direct Damage system and of the Waypoint Casting system will soon get uploaded.

Creating Bouncing Weapons

Credits/Source

Author: BSTRhino
Source: RTSBANANA. The article in turn was from the old starcraft.org, before it asploded.
IceCC opcodes have been updated to conform with IceCC v1.3. Note that the original has been updated for this Wiki.

Requirements

The tools required for this: Arsenal III (or DatEdit or PyMS's PyDAT), IceCC (or PyMS's PyICE).

Procedure

While playing some of the mods on this site, you might have seen people create weapons that bounce just like the Mutalisk's weapon. How do you do this?

There are two parts to it.

1. In Arsenal III _{[or other DAT editor]}, change the "Missile Type" and "Behaviour" to "Bouncing". This step is very, very easy, and if you have no idea how to do this, you really need to do some more modding with Arsenal III before attempting to create an effect of this level.
2. You need to fix the iscript_{[using an iscript editor]} of the weapon's flingy/sprite/image so that it is capable of bouncing. I'll explain this in more detail below.

Whenever I turn a weapon into a bouncing weapon, I always use IceCC. You can use ICE if you choose, but this tutorial is written for an IceCC scripter, so if you choose to use ICE, you will need to adapt the concepts yourself.

If you look at the Glave Wurm iscript, and then you look at iscripts for other weapons, you'll notice the main difference is that the Glave Wurm has an animation called BurrowInit, while the others don't. I'm sure you can guess that BurrowInit is the animation that is called whenever the weapon bounces. So, when editing the iscript to turn a non-bouncing weapon into a bouncing weapon, the goal is to create some code that to be run on the BurrowInit animation.

Now, the first difficulty in most cases is that most weapon iscript headers don't have a BurrowInit animation. To illustrate this, take a look at the iscript header for the Glave Wurm:

Code

Notice how it has a BurrowInit animation right at the bottom? Let's compare that to the script of the Vulture's Fragmentation Grenade:

Code

It has no BurrowInit animation like the Glave Wurm does, and because of that, this flingy cannot bounce. We can change that, but first we need to do is add BurrowInit to the iscript header of the Fragmentation Grenade. This is done by remaking the header so that it looks just like the Glave Wurm one, except using the offsets that are relevant to the Fragmentation Grenade. So here it is edited to look like the Glave Wurm header:

Code

There are a few things to notice here. First, the type up the top was changed to 13, which is the same as for the Glave Wurm. The type sets which animations are in the iscript header. Type 13 happens to have Init, Death, GndAttkInit, and everything else up to BurrowInit. To make this work, first you have to copy the extra animations from the Glave Wurm's type 13 header so that all of the required animations for type 13 are present in your weapon's iscript. Just use [NONE] for all the new animations you have to add. Second, the BurrowInit block name was changed to BounceCode and this indicates we're going to make a new block label titled BounceCode.

So now to write the BounceCode block. This is what the Glave Wurm has in its Unknown511BurrowInit block, which does what our BounceCode block for the Fragmentation Grenade will need to do.

Code

So now, knowing how the Glave Wurm's bouncing BurrowInit block is coded, you can now code your own BounceCode block in the same way. Like with anything in iscript, you can write whatever commands you want for your BounceCode block, but if you just want to write something that makes a weapon bounce normally, what you need to do to have the last two lines of your BounceCode block very similar to the Glave Wurm's. That is, you need to include a domissiledmg line to apply damage on bouncing, and you also need to jump back to the main loop of the iscript. So, if I were to write a simple Fragmentation Grenade BounceCode block, this is what it would look like:

Code

You might want to add "play sound" commands to make your bouncing sound nicer, but that's your choice. So now that you have added your bouncing animation and set your values in Arsenal III, you now have a bouncing weapon. It's really quite simple, all you really did was copy the Glave Wurm and adapt it to the new weapon. If in the future if you find an effect you would really like to do, try investigating how it is already done by Blizzard, or by one of your favourite modders. You might be surprised to find that you have all the tools you need to learn how to do anything you see in modding.