Table of contents

CHK File

The scenario.chk file contains all the map data. This includes strings, units, triggers, doodads, mission briefings, terrain, fog of war, etc.; anything except the physical .wav files. It is stored inside an MPQ file with the .scx or .scm file extension, along with any .wav files included in the scenario.

Format

The scenario.chk file consists of "chunks," or "sections." Each section contains a particular group of data describing the scenario. For example, there is a separate section for strings, mission briefings, triggers, units, unit settings, etc.

Section Headers

Each section starts off with a 4 byte string, and a 4 byte unsigned long.
The string indicates which section it is. For instance, the mission briefing section has "MBRF", the trigger section has "TRIG", etc.

The 4 byte unsigned long indicates how many bytes the section contains, not including the header itself.

After this 8 byte header, the rest of the section follows. Section order does not matter. The sections are only listed the way they are written by the original Campaign Editor.

"TYPE" Section

Required for all game types (hybrid, broodwar)
Not required for StarCraft
This section specifies the type of scenario.

• 4 byte string: Specifies the type of scenario: RAWS for 1.04 StarCraft and above ("hybrid"), RAWB for Brood War.

"VER " Section

Required for all game types (vanilla, hybrid, broodwar)
This section identifies the file format version.

• 2 byte integer: File format version. 57 for early beta, 59 for 1.00 Starcraft, 63 for 1.04 Starcraft and above ("hybrid"), and 205 for Brood War.

This appears to be the only version code section, besides TYPE, to actually be read by StarCraft (of TYPE, VER , IVER, and IVE2).

"IVER" Section

Not required (vanilla, hybrid, broodwar)
This section "additionally identifies" the map version.

• 2 byte integer: "Additional file format version:" 9 for beta/obsolete versions, 10 for current versions

Contrary to popular belief, it doesn't get "replaced" by IVE2 in hybrid/Brood War scenarios: both seem to be written by StarEdit but not read by StarCraft.

"IVE2" Section

Not required (hybrid, broodwar)
This section "additionally identifies" the map version.

• 2 byte integer: "Additional file format version:" 11 for 1.04 StarCraft and above ("hybrid") or Brood War.

Contrary to popular belief, it doesn't "replace" IVER in hybrid/Brood War scenarios: both seem to be written by StarEdit but not read by StarCraft.

"VCOD" Section

Required for all game types. (vanilla, hybrid, broodwar)
This section has a verification code to make sure this is actually a CHK file.

• 1024 bytes: Verification code.
  
• 16 bytes: Operation codes to produce the resulting hash.
  

There are some protections out there which only slightly alter the code: it seems to still work in StarCraft while failing in StarEdit. Please edit this part if you know more.
SC probably calculates the CRC of the VCOD sections and compares it with a hardcoded CRC (?). Thus if two VCOD sequences output the same CRC SC won't notice it.

"IOWN" Section

Not required (vanilla, hybrid, broodwar)
This section specifies the owner of each player.

• 12 bytes: One byte for each player, specifies the owner of the player:
  • 00 - Inactive
    
  • 01 - Computer(game)
    
  • 02 - Occupied by Human Player
    
  • 03 - Rescue Passive
    
  • 04 - Unused
    
  • 05 - Computer
    
  • 06 - Human (Open Slot)
    
  • 07 - Neutral
    
  • 08 - Closed slot
    

This section is seperate from ownr as a staredit value. Staredit does not display "inactive" as a valid option. Grey settings denote invalid map options which may involve a buffer overflow.

"OWNR" Section

Required for all game types (vanilla, hybrid, broodwar)
This section designates the controller of a particular player. It is exactly the same as the "IOWN" section, except there is an additional value (0x00 for Unused).

• 12 bytes: One byte for each player, specifies the owner of the player:
  • 00 - Inactive
    
  • 01 - Computer(game)
    
  • 02 - Occupied by Human Player
    
  • 03 - Rescue Passive
    
  • 04 - Unused
    
  • 05 - Computer
    
  • 06 - Human (Open Slot)
    
  • 07 - Neutral
    
  • 08 - Closed slot
    

Grey settings denote invalid map options which may involve a buffer overflow.

"ERA " Section

Required for all game types (vanilla, hybrid, broodwar)
This section indicates the tileset of the scenario.

• 2 byte integer: Designates tileset:
  • 00 - Badlands
  • 01 - Space Platform
  • 02 - Installation
  • 03 - Ashworld
  • 04 - Jungle
  • 05 - Desert
  • 06 - Arctic
  • 07 - Twilight
  • 08+ - Loop

StarCraft masks the tileset indicator's bit value, so bits after the third place (anything after the value "7") are removed. Thus, 9 (1001 in binary) is interpreted as 1 (0001), 10 (1010) as 2 (0010), etc.
Desert, Arctic, and Twilight are Brood War-only tilesets.

"DIM " Section

Required for all game types (vanilla, hybrid, broodwar)
This section contains the dimensions of the map.

• 2 byte integer: Width of the map
• 2 byte integer: Height of the map

The Width/Height of the map is measured in the number of square 32x32p tiles.
Standard Dimensions are 64, 96, 128, 192, 256

"SIDE" Section

Required for all game types (vanilla, hybrid, broodwar)
This section contains the species/race of each player.

• 12 bytes: 1 byte/player for species of player:
  • 00 - Zerg
    
  • 01 - Terran
    
  • 02 - Protoss
    
  • 03 - Unused (Independent)
    
  • 04 - Unused (Neutral)
    
  • 05 - User Selectable
    
  • 06 - Random (Forced; Acts as a selected race; Does not randomize race like user select;)
    
  • 07 - Inactive
    

"MTXM" Section

Required for all game types (vanilla, hybrid, broodwar)
Note: Required for all game types, all versions.
Terrain section that contains a map of the level's appearance. StarEdit disregards this section; it is only used in Starcraft.

• (variable size) 2 byte integers: one integer for each tile.

The Width/Height of the map is measured in the number of square 32x32p tiles.
Tiles in this section are listed from left to right, top to bottom.

The values for each integer are their respective "MegaTile" values in the scenario's tileset. If the size of this section is greater than width*height*2, the data following is ignored. If the size of this section is less, the resulting tiles that have not been defined will be null tiles.

This section includes doodads as terrain; TILE, which is otherwise identical, doesn't. Out of the terrain sections (TILE, ISOM, and MTXM), SC only reads MTXM for the sake of not having to generate this data on-the-fly: it contains the exact representation of the level's appearance, including doodads. TILE, on the other hand, is directly tied via a tile lookup function to ISOM, and exists for the sake of not having to generate tiles from ISOM on-the-fly in StarEdit.

"PUNI" Section

Required for Use Map Settings game type (vanilla, hybrid, broodwar)
This section contains player unit restrictions: it indicates whether the player can or cannot build a particular unit.

• (228 * 12) bytes: 1 byte for each unit in order of its unit id, then each player, for player availability:
  • 00 - That unit is not available for production if the player has 'override defaults' on
  • 01 - That unit is available for production if the player has 'override defaults' on

• 228 bytes: 1 byte for each unit in order of it's unit id, for global availability defaults (for all players):
  • 00 - That unit is not available for production
  • 01 - That unit is available for production

• (228 * 12) bytes: 1 byte for each unit in order of its unit id, then each player, indicating whether a player uses the global availability defaults.
  • 00 - Player overrides defaults for this unit
  • 01 - Player uses defaults for this unit

"UPGR" Section

Required for the Use Map Settings game type in vanilla maps or hybrid maps when run in vanilla mode (vanilla, hybrid)
This section contains player upgrade restrictions: it indicates the starting/maximum levels at/to which a player can perform a particular upgrade.

• (46 * 12) bytes: 1 byte for the maximum level a player can upgrade to, in order of its upgrade id, then each player
• (46 * 12) bytes: 1 byte for the level of an upgrade a player starts off with, in order of its upgrade id, then each player
• 46 bytes: 1 byte for the global default maximum level of each upgrade, in order of its upgrade id.
• 46 bytes: 1 byte for the global default starting level of each upgrade, in order of its upgrade id.
• (46 * 12) bytes: 1 byte for each upgrade in order of its upgrade id, then each player, indicating whether a player uses the global upgrade defaults:
  • 00 - Player does not use global upgrade defaults for this upgrade
  • 01 - Player uses upgrade defaults for this upgrade

This section is overridden with "PUPx" when the scenario is Brood War or hybrid run in Brood War mode.

"PTEC" Section

Required for the Use Map Settings game type in vanilla maps or hybrid maps when run in vanilla mode (vanilla, hybrid)
This section contains player technology availability restrictions: it indicates whether a player starts off with a particular technology or can research a particular technology.

• (24 * 12) bytes: 1 byte for each technology id, then each player, for player availability:
  • 00 - Technology is not available for a player
  • 01 - Technology is available for a player

• (24 * 12) bytes: 1 byte for each technology id, then each player, for "already researched" status:
  • 00 - Technology is not already researched
  • 01 - Technology is already researched

• 24 bytes: 1 byte for each technology for global availability defaults:
  • 00 - Technology is not available by default
  • 01 - Technology is available by default

• 24 bytes: 1 byte for each technology for global "already researched" defaults:
  • 00 - Technology is not already researched by default
  • 01 - Technology is already researched by default

• (24 * 12) bytes: 1 byte for each technology in order of its technology id, then each player, indicating whether a player uses the global defaults:
  • 00 - Technology overrides defaults for player
  • 01 - Technology uses default settings for player

This section is overridden with "PTEx" when the scenario is Brood War or hybrid run in Brood War mode.

"UNIT" Section

Required for all game types (vanilla, hybrid, broodwar)
This section contains all the pre-placed units on the map and their properties. Each unit on the map gets the following structure:

• 4 byte long: The unit's class instance (sort of a "serial number")
• 2 byte integer: X coordinate of unit
• 2 byte integer: Y coordinate of unit
• 2 byte integer: Unit ID
• 2 byte integer: Type of relation to another building (i.e. add-on, nydus link, etc.)
• 2 bytes: Flags of special properties which can be applied to the unit and are valid:
  • Bit 0 - Cloak is valid
  • Bit 1 - Burrow is valid
  • Bit 2 - In transit is valid
  • Bit 3 - Hallucinated is valid
  • Bit 4 - Invincible is valid
  • Bit 5-15 - Unused

• 2 bytes: Out of the elements of the unit data, the properties which can be changed by the map maker:
  • Bit 0 - Owner player is valid (the unit is not a critter, start location, etc.; not a neutral unit)
  • Bit 1 - HP is valid
  • Bit 2 - SP is valid
  • Bit 3 - Energy is valid (unit is a wraith, etc.)
  • Bit 4 - Resource amount is valid (unit is a mineral patch, vespene geyser, etc.)
  • Bit 5 - Amount in hangar is valid (unit is a reaver, carrier, etc.)
  • Bit 6-15 - Unused

• 1 byte: Player number of owner (0-based)
• 1 byte: Hit points % (1-100)
• 1 byte: Shield points % (1-100)
• 1 byte: Energy points % (1-100)
• 4 byte long: Resource amount
• 2 byte integer: Number of units in hangar
• 2 bytes: Unit state flags
  • Bit 0 - Unit is cloaked
  • Bit 1 - Unit is burrowed
  • Bit 2 - Building is in transit
  • Bit 3 - Unit is hallucinated
  • Bit 4 - Unit is invincible
  • Bit 5-15 - Unused

• 4 bytes: Unused
• 4 byte long: Class instance of the unit to which this unit is related to (i.e. via an add-on, nydus link, etc.). It is "0" if the unit is not linked to any other unit.

The X/Y coordinates are the center of the sprite of the unit (in pixels).
The "type of relation to another building" field is not fully discovered yet: please edit if you know more information.
Also, please edit if you could confirm the bit values to be correct/if you know more bit values. Default values will apply if bit values are unchecked. Defaults: 100% HP, 100% SP, 100% EP, 0 resources, 0 hangar count.

"ISOM" Section

Not required (vanilla, hybrid, broodwar)
This section is required to place isometric terrain on the map. It provides data about the nature of the isometrical "diamonds" (the editing mode of StarEdit).

• [ (width / 2 + 1) * (height + 1) * 4 ] 2 byte integers: 4 integers for each map rectangle tile (plus one extra tile to the right and bottom of the map), as per the RECT structure. Each rectangle border (left, top, right, bottom) is assigned an "ISOM value." These form the "diamond" pattern of the map, and each rectangle thus gets two ISOM values associated with it. StarEdit somehow hashes these (the exact algorithm is unknown) and thus produces the tile index of the rectangle (which it stores in TILE for reasons of efficiency). The index of the rectangle's right tile is that of its left tile + 16.

This section is the only truly unknown section of the .chk format. If you're an ex-Blizzard employee or SI, please edit this section.
If you have additional research, post on the forums about it and/or edit this section.

"TILE" Section

Not required (vanilla, hybrid, broodwar)
This section will only be different from the MTXM section in tiles where doodads are present.

• (width * height) 2 byte integers: 1 integer for each map tile. Moves horizontally across the map.

The values in TILE are normally directly generated from the ISOM section (see "'ISOM' section" above), and thus do not match that of MTXM on doodad tiles.

"DD2 " Section

Not required by StarCraft
This section contains the doodad map of the level. There are several parts to doodads. The graphical portion is stored in the ?MTXM? section. The second part of the doodad is stored in this section. This section seems to be only used by the map editor.

Each doodad in the map gets the following structure

• 2 byte integer: Number of the doodad. Size of the doodad is dependent on this. Doodads are different for each tileset.
• 2 byte integer: X coordinate of the doodad unit
• 2 byte integer: Y coordinate of the doodad unit
• 1 byte: Player number that owns the doodad
• 1 byte: Enabled flag
  • 00 - Doodad is enabled (trap can attack, door is closed, etc)
  • 01 - Doodad is disabled

"THG2" Section

Note: Required for All game types, all versions
The map editor only writes to this section. Starcraft uses this section.

Certain doodads with sprites get the following structure.

• 2 byte integer: Unit number of the doodad
• 2 byte integer: X coordinate of the doodad unit
• 2 byte integer: Y coordinate of the doodad unit
• 1 byte: Player number that owns the doodad
• 1 byte: Unused
• 2 bytes: Flags
  • Bit 0-11 - Unused
  • Bit 12 - Draw as sprite (Determines if it is a sprite or a unit)
  • Bit 13 - Unused
  • Bit 14 - Unused
  • Bit 15 - Disabled (Only valid if Draw as sprite is unchecked, disables the unit)

"MASK" Section

Note: Not required for Melee game type.
This section contains the data on fog of war for each player. This is whether at the start of the game that levels of black space that is available.

• (Variable) bytes: One byte for each map tile. The bits indicate for each player the fog of war.
  • Bit 0 - Player 1's Fog of War. If on, the tile is covered with fog. if off, the tile is visible.
  • Bit 1 - Player 2's Fog of War. If on, the tile is covered with fog. if off, the tile is visible.
  • Bit 2 - Player 3's Fog of War. If on, the tile is covered with fog. if off, the tile is visible.
  • Bit 3 - Player 4's Fog of War. If on, the tile is covered with fog. if off, the tile is visible.
  • Bit 4 - Player 5's Fog of War. If on, the tile is covered with fog. if off, the tile is visible.
  • Bit 5 - Player 6's Fog of War. If on, the tile is covered with fog. if off, the tile is visible.
  • Bit 6 - Player 7's Fog of War. If on, the tile is covered with fog. if off, the tile is visible.
  • Bit 7 - Player 8's Fog of War. If on, the tile is covered with fog. if off, the tile is visible.

Note: Any size greator than width*height will be ignored. Any size less will default missing tiles to 0xFF

"STR " Section

Note: Required for Melee game type
This section contains all the strings in the map.
Note: This section can contain more then 1024 strings and will work in Starcraft

• 2 byte integer: Number of strings in the section
• (# of strings) 2 byte integers: 1 integer for each string specifying the offset (the spot where the string starts in the section from the start of it).
• Strings: After the offsets, this is where every string in the map goes, one after another. Each one is terminated by a null character.

"UPRP" Section

Note: This section is not required for melee.
This section is used whenever the create units with properties trigger is used. Since a slot has to be assigned to the action, this is where each slot is designated.

There are 64 of the following structures regardless of how many are used and it cannot exceed 64.

• 2 bytes: Flag of which special properties can be applied to unit, and are valid.
  • Bit 0 - Cloak bit is valid
  • Bit 1 - Burrowed bit is valid
  • Bit 2 - In transit bit is valid
  • Bit 3 - Hallucinated bit is valid
  • Bit 4 - Invincible bit is valid
  • Bit 5-15 - Unknown/unused

• 2 bytes: Which elements of the unit data are valid, which properties can be changed by the map maker.
  • Bit 0 - Owner player is valid (unit is not neutral)
  • Bit 1 - HP is valid
  • Bit 2 - SP is valid
  • Bit 3 - Energy is valid
  • Bit 4 - Resource amount is valid (unit is a resource)
  • Bit 5 - Amount in hanger is valid
  • Bit 6 - Unknown/unused

• 1 byte: Player number that owns unit. Will always be NULL in this section (0)
• 1 byte: Hit point % (1-100)
• 1 byte: Shield point % (1-100)
• 1 byte: Energy point % (1-100)
• 4 byte long: Resource amount (for resources only)
• 2 byte integer: # of units in hangar
• 2 bytes: Flags
  • Bit 0 - Unit is cloaked
  • Bit 1 - Unit is burrowed
  • Bit 2 - Building is in transit
  • Bit 3 - Unit is hallucinated
  • Bit 4 - Unit is invincible
  • Bit 5-15 - Unknown/unused

• 4 bytes: Unknown/unused. Padding?

"UPUS" Section

Note: This section is not required for melee.
This section goes along with the "UPRP" section. This section just indicates which of the 64 unit properties slot is used.

• 64 bytes: 1 byte for each trigger unit properties slot
  • 00 - Properties slot is unused
  • 01 - Properties slot is used

"MRGN" Section

Note: This section is required for all game types, all versions.
This section contains all the locations that the map uses. In a scenario that is not Brood War, this section contains 64 locations. In a Brood War map, this section will expand to contain 255 locations. This section can be a size of 0 in melee.

Each location gets one of the following location entries. The 'Anywhere' location, is ALWAYS location 64.

• 4 byte long: Starting X coordinate of location (32 pt grid)
• 4 byte long: Starting Y coordinate of location (32 pt grid)
• 4 byte long: Ending X coordinate of location (32 pt grid)
• 4 byte long: Ending Y coordinate of location (32 pt grid)
• 2 byte integer: String number of the name of this location
• 2 bytes: Location elevation flags. If an elevation is disabled in the location, it's bit will be on (1)
  • Bit 0 - Low elevation
  • Bit 1 - Medium elevation
  • Bit 2 - High elevation
  • Bit 3 - Low air
  • Bit 4 - Medium air
  • Bit 5 - High air
  • Bit 6-15 - Unused

"TRIG" Section

NOTE: This section is required for the UMS game type. This section may be split.
This section contains all the triggers in the map. This along with MBRF is the most complicated section in the entire scenario.chk file. There is too much data packed into too little of a space. Refer to the appendix at the bottom of this page for more information.

For easy reference, since each trigger contains 2400 bytes, the amount of triggers can be gotten by taking the section length and dividing by 2400.

Every single trigger in the map will have the following format:

16 Conditions
Every trigger has 16 of the following format, even if only one condition is used. See the appendix for information on which items are used for what conditions.

• 4 byte long: Location number for the condition (1 based)
• 4 byte long: Group (0 based) that the condition applies to
• 4 byte long: Qualified number (how many/resource amount)
• 2 byte integer: Unit ID condition applies to
• 1 byte: Comparison type/switch state
• 1 byte: Condition byte (see the appendix)
• 1 byte: Resource type/score type/switch number
• 1 byte: Flags
  • Bit 0 - Unknown/unused
  • Bit 1 - Enabled flag. If on, the trigger action/condition is disabled/ignored
  • Bit 2 - Always display flag.
  • Bit 3 - Unit properties is used. Unnecessary (Note: This is uses in *.trg files).
  • Bit 4 - Unit type is used. May not be necessary?
  • Bit 5 - If on, the unit ID is used. Unnecessary.
  • Bit 6-7 - Unknown/unused

• 2 bytes: Used internally by starcraft (number of which condition to process next, and maybe more?)

64 Actions
Immediately following the 16 conditions, there are 64 actions. There will always be 64 of the following structure, even if some of them are unused.

• 4 byte long: 'Source' or only location (#1 based)
• 4 byte long: String number for trigger text
• 4 byte long: String number of. WAV file
• 4 byte long: Seconds/milliseconds of time
• 4 byte long: First, or only group/player affected.
• 4 byte long: Second group affected, destination location (1-based), CUWP #, number, AI script, switch
• 2 byte integer: Unit/score/resource type/alliance status
• 1 byte: Action byte. See appendix.
• 1 byte: Number of units/switch action/unit order/modify type. 0 specifies all units.
• 1 byte: Flags
  • Bit 0 - Unknown/unused
  • Bit 1 - Enabled flag. If on, the trigger action/condition is disabled
  • Bit 2 - Always display flag.
  • Bit 3 - Unit properties is used. Staredit uses this for *.trg files.
  • Bit 4 - Unit type is used
  • Bit 5 - If on, the unit ID is used. Unnecessary.
  • Bit 6-7 - Unknown/unused

• 3 bytes: Used internally by starcraft (number of which action to process next, and maybe more?)

Player Execution
Following the 16 conditions and 64 actions, every trigger also has this structure

• 4 bytes: Used internally by starcraft (unknown usage. may be used to check if the trigger is "finished", ie no preserve trigger and the trigger has already run)
• 28 bytes: 1 byte for each player in the players/groups list (except for the last one) (see appendix).
  • 00 - Trigger is not executed for player
  • 01 - Trigger is executed for player

"MBRF" Section

This section contains all of the mission briefings shown by the players.

This section has the exact same format as the "TRIG" section, except for the conditions. In this section the 16 conditions are still there, they are all null except for the very first condition, which only has a condition byte of 13. See appendix for the action bytes for the mission briefings.

"SPRP" Section

This section decides which strings are the scenario properties.

• 2 byte integer: String number of the scenario name
• 2 byte integer: String number of the scenarios description.

Note: A string index of 0 for the map name will default it to its file name.

"FORC" Section

Note: Required for Melee game type (size may be 0), full size required for UMS maps
This section specifies the forces and the information about them.

• 8 bytes: 1 byte for each active player, specifying which of the 4 forces (0-based) that the player's on.
• (4) 2 byte integers: 1 integer for each force, string number of the name of the force
• 4 bytes: 1 byte for each force specifying the properties:
  • Bit 0 - Random start location
  • Bit 1 - Allies
  • Bit 2 - Allied victory
  • Bit 3 - Shared vision
  • Bit 4-7 - Unknown/unused

"WAV " Section

Not required by StarCraft
There are 1024 wav entires regardless of how many are actually used.
Note: This section is not required and is often left out.

• 512 longs: 1 long for each WAV. Indicates the string number of the path to the wav file in the MPQ. If the entry is not used, it will be 0.

"UNIS" Section

Note: This section is overridden with "UNIx" when the scenario is Brood War. Not required for melee.
This section contains the unit settings for the level.

• 228 bytes: 1 byte for each unit, in order of Unit ID
  • 00 - Unit does not use default settings
  • 01 - Unit does use default settings
• (228) 4 byte integers: Hit points for unit*256
  
• (228) 2 byte integers: Shield points, in order of Unit ID
• 228 bytes: Armor points, in order of Unit ID
• (228) 2 byte integers: Build time (1/60 seconds), in order of Unit ID
• (228) 2 byte integers: Mineral cost, in order of Unit ID
• (228) 2 byte integers: Gas cost, in order of Unit ID
• (228) 2 byte integers: String number, in order of Unit ID
• (100) 2 byte integers: Base weapon damage the weapon does, in weapon ID order (appendix)
• (100) 2 byte integers: Upgrade bonus weapon damage, in weapon ID order (appendix)

"UPGS" Section

Note: This section is overridden with "UPGx" when the scenario is Brood War. Not required for melee.
This section contains upgrade settings.

• 46 bytes: 1 byte per each upgrade, in order of upgrade id.
  • 00 - Upgrade uses custom settings
  • 01 - Upgrade uses default settings

• (46) 2 byte integers: 1 integer per upgrade, base mineral cost for each upgrade, in order of upgrade id.
• (46) 2 byte integers: 1 integer per upgrade, mineral cost factor for each upgrade, in order of upgrade id.
• (46) 2 byte integers: 1 integer per upgrade, base gas cost for each upgrade, in order of upgrade id.
• (46) 2 byte integers: 1 integer per upgrade, gas cost factor for each upgrade, in order of upgrade id.
• (46) 2 byte integers: 1 integer per upgrade, base time for each upgrade, in order of upgrade id.
• (46) 2 byte integers: 1 integer per upgrade, gas time factor for each upgrade, in order of upgrade id.

"TECS" Section

Note: This section is overridden with "TECx" when the scenario is Brood War. Not required for melee.
This section contains technology/special abilities settings

• 24 bytes: 1 byte per each technology, specifies if the tech overrides the default settings. In order of technology id (appendix)
  • 00 - Technology uses custom settings
  • 01 - Technology uses default settings

• (24) 2 byte integers: Mineral cost to develop technology. In order of technology id (appendix).
• (24) 2 byte integers: Gas cost to develop technology. In order of technology id (appendix).
• (24) 2 byte integers: Time required to develop technology. In order of technology id (appendix).
• (24) 2 byte integers: Energy cost to cast technology/special ability. In order of technology id (appendix).

"SWNM" Section

Not required by StarCraft
This section contains the strings used for each switch. There are 256 switches, and can't be any more or any less.

• (256) 4 byte longs: One long for each switch, specifies the string number for the name of each switch.

"COLR" Section

Note: Required for Melee game type (only on Brood War)
Note: This section only has effect on Brood War
This section indicates what color each player is.

• 8 bytes: 1 byte for each player, indicates the color of the player
  • 00 - Red
  • 01 - Blue
  • 02 - Teal
  • 03 - Purple
  • 04 - Orange
  • 05 - Brown
  • 06 - White
  • 07 - Yellow
  • 08 - Green
  • 09 - Pale yellow
  • 10 - Tan
  • 11 - Neutral color
  • 12 - Pale green
  • 13 - Blueish gray
  • 14 - Pale yellow
  • 15 - Cyan
  • 17 - Black

Note: Other values can be used but may have different results depending on the tileset. Any color value above 11 is an overflow.

"PUPx" Section

Note: This section overrides the "UPGR" when the scenario is Brood War.
This section is identical to UPGR section except it uses the Brood War set of 61 upgrades instead of the original 46

"PTEx" Section

Note: This section overrides the "PTEC" when the scenario is Brood War.
This section is identical to PTEC section except it uses the Brood War set of 44 technologies instead of the original 24

"UNIx" Section

Note: This section overrides the "UNIS" when the scenario is Brood War.
This section is indentical to UNIS section except it uses the Brood War set of 130 weapons instead of the original 100

"UPGx" Section

Note: This section overrides the "UPGS" when the scenario is Brood War.
This section is pretty much the same as UPGS except for two differences:

• This section uses the Brood War set of 61 upgrades instead of the original 46
• After the first 61 bytes, there is a single 0 before the next set. May not matter?

"TECx" Section

Note: This section overrides the "TECS" when the scenario is Brood War.
This section is indentical to UNIS section except it uses the Brood War set of 44 technologies instead of the original 24

Appendix

A set of references and IDs that should help you easier in the trigger section and the technology/player ids, etc:

Trigger Conditions List

Code

Trigger Actions List

Code

Mission Briefing Actions List

Code

Switch States

Code

Numeric Comparisons

Code

Score Types

Code

Resource Types

Code

Alliance Statuses

Code

Unit Orders

Code

Action States

Code

Number Modifiers

Code

Trigger Unit Types

Code

List of Players/Group IDs

Code

List of Technology IDs

Code

List of Unit Weapon IDs

Code

Complete Modifier List

Code