MPQ File Internal Details

Back to lessons

MPQ File Internal Details

This is a guide on what each of the files in the map archive are and other information about them. It's expected that you know about the MPQ format for this guide.

Hex Header:

The first 512 hex digits of a map are the header. Most noteably, this contains the map's name which will appear in the lobby. Note that there is ANOTHER name for the map as well, which will appear in other places. This can either be located in the scripts or the strings file.

war3map.j - Scripts:

Type: plain text (JASS)

Required: yes

The most important file in WC3. When you program a map in any language, it all eventually gets converted into JASS and placed in the war3map.j. Even things you didn't code, like map config, gets put in here. This is easily accessible in the MPQ archive and is in plaintext, and can be edited and re-imported whenever wanted. There are some interesting details about this:

1) globals

At the very top of the file is globals. These store all your variables, as well as lots of variables that you didn't make, like every trigger in your map. Custom defined variables from GUI will be called udg_variableName. Others, like triggers, have their own heuristic (like gg_trg_triggerName). Note that if the map is obfuscated, the variable names will be changed randomly and not follow their naming conventions anymore.

2) endglobals

When the globals ends (the endglobals keyword), this is where every function and trigger in your map goes. It is in order, unless the map has been obfuscated.

3) function Main is called when the map begins

This is where all your code for initializing the map goes (as well as a lot of code you didn't write in initialization) If you wrote a GUI map, there will be an additional function called InitCustomTriggers to initialize your triggers.

4) Anything below function main

There's lots of stuff you don't need to care about below function main. Generally it's initializing the map name and description and stuff like that. These probably will be somewhere else in an obfuscated map.

One more interesting detail: this can be moved to scripts/war3map.j in the MPQ and will function correctly.

war3map.wts - Strings:

Type: plain text (custom format)

Required: yes, if wts strings are used. If not, maybe?

If you've programmed java, you probably know about the String pool and String interning. If not, these details are relevant so let me explain them quick. A String is the object that stores words, like "hello world!". Strings are immutable, meaning they may not be changed, only created. So if we generate two strnigs that both say "hello world!" it is a complete waste of memory since they are the same. We should have reused them. Java takes care of this by storing them in a string pool and reusing them.

Warcraft 3 does something similar. The wts file.

Let's say you display the message "Hello!" to all players in WC3. When you compile this map and look at the source code, you might be interested to see that it may no longer display "Hello!". Instead, it displays something like TRIGSTR_136. The reason for this is that the string was placed in the war3map.wts file. If you care to look, you'll find something like:

STRING 136
{
Hello!
}


It is unknown when the editor decides to move strings to the wts file. It is not all the time.

war3map.w3u - Units:

Type: not plaintext (custom format)

Required: yes, if not widgetized

Stores every unit in the game. Can be read and written by World Editor.

war3map.w3t - Items:

Type: not plaintext (custom format)

Required: yes, if not widgetized

Stores every item in the game. Can be read and written by World Editor.

war3map.w3b - Destructibles:

Type: not plaintext (custom format)

Required: yes, if not widgetized

Stores every destructible in the game. Can be read and written by World Editor. I guess every other letter was taken so they had to use B.

war3map.w3d - Doodads:

Type: not plaintext (custom format)

Required: yes, if not widgetized

Stores every doodad in the game. Can be read and written by World Editor.

war3map.w3a - Abilities:

Type: not plaintext (custom format)

Required: yes, if not widgetized

Stores every ability in the game. Can be read and written by World Editor.

war3map.w3h - Buffs:

Type: not plaintext (custom format)

Required: yes, if not widgetized

Stores every buff in the game. Can be read and written by World Editor. w3h makes perfect sense for buffs because everyone knows that H stands for... buff?

war3map.w3q - Upgrades:

Type: not plaintext (custom format)

Required: yes, if not widgetized

Stores every upgrade in the game. Can be read and written by World Editor. I'm pretty sure they're messing with us now, with the name .w3q.

war3mapSkin.txt - Interface:

Type: plaintext (key/value pairs)

Required: no

This file stores a custom Game Interface. Only edited values are stored here. This is plaintext so it's super easy to edit.

war3mapMisc.txt - Gameplay Constants:

Type: plaintext (key/value pairs)

Required: no

This file stores a custom Gameplay Constants. Only edited values are stored here. This is plaintext as well.

war3map.doo - Preplaced Things:

Type: not plaintext (custom format)

Required: no

War3map.doo stores all preplaced units, items, etc.. Preplaced means that it was placed in the object editor and not created in code. Note that this file is NOT necessary in any way. You can create all your preplaced data in code (which is exactly what map optimizer does).

war3map.wtg - Trigger Editor GUI Data:

Type: not plaintext (custom format)

Required: no

Stores all GUI triggers and variables created in the world editor. This is world-editor-only data and can safely be deleted. This file format is not trivial to read, though specs have been released by Ralle.

war3map.w3i - Player Slot Data:

Type: not plaintext (custom format)

Required: yes but can be corrupt

Stores player data. This is an interesting file because it can be corrupted by map protectors which makes the map unable to open in World Editor but playable in WC3. To reverse this, it is possible to import a new w3i.

war3map.mmp - Minimap Data:

Type: not plaintext (custom format)

Required: yes

Stores what your minimap will look like ingame.

war3map.shd - Shadow Mapping:

Type: not plaintext (custom format)

Required: yes

Stores where your shadows will go ingame. Presumably they created this file so they don't have to calculate it ingame every time which would increase loading times.

war3map.w3e - Environment:

Type: not plaintext (custom format)

Required: yes

Stores data about tileset.

war3map.wpm - Pathmap:

Type: not plaintext (custom format)

Required: yes

I have no idea what this is.

Back to lessons