Inside W3M files (w3e, w3i, doo,...)

UPDATE: LATEST VERSION -->HERE<--
use that link instead of the content below if you plan to use these info to code a program or hack your maps. The content below is just here in case you don't need the latest changes and you don't want to look on another page. ;p
//EDIT by Pitzer: I took the freedom to change the link to a more up to date version I compiled.


Last update (old forum version): 15/07/2002

You'll find here a lot about the formats of all these files packed in the w3m.

OK Let's go! :D

1) Things you need to know first to mod a map!

1a) You environment
You'll need Warcraft III Retail installed let's say in "c:\war3\".
I'll talk about files of Warcraft 3 Retail 1.01 here, some files format can vary depending which

version you're using, you may have to figure out some differences in the file formats.
If your installation is clean, you should have these files:
(of course, there are other files in there but I'll uses these for exemples)
in your "c:\war3\":
- war3.mpq
and in your "c:\war3\maps\":
- (4)Lost Temple.w3m
(and many other w3m...)
"W3M" map files can be opened with a MPQ editor that supports Warcraft 3.
You'll need one. I suggest WinMPQ, you can get it here:
http://shadowflare.ancillaediting.ne...ad.html#WinMPQ
Read the documentation and installation notes.
You can also use MPQView and do the following:
- get MPQView there:
http://war3pub.net/upload/index.php?...mpqview11b.zip
- then put the storm.dll that comes with War3 Retail in your MPQView directory.
- then create a text file called "list.txt" that contains the single line :
- run MPQView and set the "data file" to your "list.txt".
- open the mpq/w3m you want to read. You should see only one file called (listfile).
- extract this file somewhere using "save" and set this new file as your "data file" for MPQView.
- then you're supposed to have all the files displayed.
If you want to play with the files, you'll also need a hexadecimal editor.
My favorite one is HexWorkshop (http://www.bpsoft.com/).

1b) Warcraft 3 Files
- MPQ Files
MPQ are like "zip" or "rar" files as they contain a directory structure with compressed files.
I'll not talk about the MPQ format here if you want to know more about it I suggest you go there:
Inside MoPaQ
When it's looking for a file, Warcraft III looks first in the "real" directories (the one you see in

Windows Explorer), then in the last patch mpq (War3Patch.mpq) and finally in the main mpq

(War3.mpq).
It means that you don't need to modify official MPQs (DON'T!), you just need to use the same

directory/file structure.
Example:
You have a file called "UI\MiscData.txt" in both "War3Patch.mpq" and "War3.mpq". Warcraft will use

the one in "War3Patch.mpq". If you want to modify it, just create in your "c:\war3\" diectory a

"UI" directory and extract there the file "MiscData.txt" of your "War3Patch.mpq" (you'll have:

"c:\war3\UI\MiscData.txt").
You can now modify it and next time you'll start War3, it'll use it instead.

Warning!
*In some cases, if you play with others, everybody will need to have the same modified files or

you'll get an error.
*Some files have a "special" format and if you modify them, you could "falsify" this format.
In some cases it will work, in some others it won't. Be aware of that 'cause War3 will try to find

a "standard file" instead (the ones of the MPQs instead of yours and you'll think it didn't try your

stuff).
*Some files outside both War3.mpq and War3Patch.mpq will not be used by Warcraft 3. These are

exceptions.

- Map files (W3M Files)
To edit a map, you'll have to unpack the files of the "w3m" somewhere, then modify them and finally

put them back in a "w3m" file (usually a new one).
Since the retail, W3M are a little bit different from simple MPQ files.
I'll talk more about W3M files in the "W3M Files Format" section and the other files inside W3Ms in

the following sections.


1c) Warcraft 3 Data Format
Blizzard uses several way to store data in its files. However they often use generic types.
-Integers
Intergers are stored using 4 bytes in "Little Endian" order. It means that the first byte read is

the lowest byte.
They are just like the C++ "int" (signed) type.
Size: 4 bytes
Example: 1234 decimal = [00 00 04 D2]h will be stored in this order: [D2 04 00 00]h

-Short Integers
Short Integers are stored using 2 bytes in "Little Endian" order.
They are close to the C++ signed short but their range is from -16384 to 16383. It means the

highest bytes is free of use for a flag for example.
Size: 2bytes

-Floats
Floats are using the standard IEEE 32bit float format. They are stored using 4 bytes and the

"Little Endian" order.
They are just like the C++ "float" type.
Size: 4 bytes
Example: 7654.32 decimal, this number can't be stored using this format so the system will take the

closest value that can be represented using binary digits. The closest one is: 7654.319824 decimal =

[45 EF 32 8F]h and will be stored as [8F 32 EF 45]h

-Chars and Array of Chars
They are just stored like standard chars (1 char = 1 byte) and array of chars (no null terminating

char needed).
Size (chars): 1 byte
Size (array of chars): usually 4 bytes

-Trigger Strings and Strings
Strings are just arrays of chars terminated with a null char (C++ '\0'). However Blizzard sometimes

use special control codes to change the displayed color for the string. These codes are like

"|c00BBGGRR" where "BB", "GG" and "RR" are hexadecimal values (using 2 digits each) for the blue,

the green and the red values.
If a string starts with "TRIGSTR_" followed by 3 numbers and a null char, it's a trigger string. A

trigger string is kept in memory as is and is only changed when Warcraft needs to display it.

Instead of just writing "TRIGSTR_000" on the user screen, War3 will look in its trigger string

database created when the map was loaded and display the corresponding trigger string instead.
Example: your got the string "blah |c000080FFblah", War3 will display "blah blah" but the second

blah will be orange (blue=00 + green=80 + red=FF ==> orange)
Example2: you got "TRIGSTR_025" and trigger string 25 is defined (in the .wts file) as "blah

|c000080FFblah", it'll display the same result as the previous example.
Size (string): vary. String length + 1 (null terminating char)
Size (Trigger string): 12 bytes

-Flags
Flags are boolean values (true or false, 1 or 0). They can be stored using 4 bytes. Each bit is a

flag (4 bytes = 32 bit = 32 flags). Blizzard uses integers to store its flags.
Size: usually 4 bytes

-Custom Types
Sometimes, an integer and one or several flags can share bytes. This is the case in the W3E file

format: the water level and 2 flags are using the same group of 4 bytes. How? the 2 highest bit are

used for the flags, the rest is reserved for the water level (the value range is just smaller).
Sometimes a byte can contain two or more different data.

-Structures:
Warcraft 3 also uses structured types of various size.


2) W3M Files Format
A W3M file is a Warcraft III Map file (AKA Warcraft III Scenario in the World Editor). It's just a

MPQ (using a "new" compression format) with a 512bytes header.
Here is the header format (fixed size = 512 bytes):
char[4]: file ID (should be "HM3W")
int: unknown
string: map name
int: map flags (these are exactly the same as the ones in the W3I file)
0x0001: 1=hide minimap in preview screens
0x0002: 1=modify ally priorities
0x0004: 1=melee map
0x0008: 1=playable map size was large and has never been reduced to medium
0x0010: 1=masked area are partially visible
0x0020: 1=fixed player setting for custom forces
0x0040: 1=use custom forces
0x0080: 1=use custom techtree
0x0100: 1=use custom abilities
0x0200: 1=use custom upgrades
0x0400: 1=map properties menu opened at least once since map creation
0x0800: 1=show water waves on cliff shores
0x1000: 1=show water waves on rolling shores
int: max number of players
followed by 00 bytes until the 512 bytes of the header are filled.

The MPQ part can contain the following files:
(listfile)
(signature)
(attributes)
war3map.w3e
war3map.w3i
war3map.wtg
war3map.wct
war3map.wts
war3map.j
war3map.shd
war3mapMap.blp
war3mapMap.b00
war3mapPreview.tga
war3map.mmp
war3mapPath.tga
war3map.wpm
war3map.doo
war3mapUnits.doo
war3map.w3r
war3map.w3c
war3map.w3u
war3map.w3s
war3map.imp
war3mapImported\*.* (wave files, and other kind of files saved by the world editor)
We'll see now what these files stand for.


3) "war3map.j" The JASS2 Script
This is the main map script file. It's a text file and you can open it with notepad.
The language used is called JASS2 and has been developped by Blizzard.
The script file is loaded when you create a game; War3 runs the function called "function main".


4) "war3map.w3e" The environment
This is the tileset file. It contains all the data about the tilesets of the map.
Let's say the map is divided into squares called "tiles". Each tile has 4 corners. In 3D, we define

surfaces using points and in this case tiles are defined by their corners. I call one tile corner a

"tilepoint".
So if you want a 256x256 map, you'll have 257x257 tilepoints. That's also why a tile texture is

defined by each of its four tilepoints. A tile can be half dirt, one quarter grass and one quarter

rock for example.
The first tilepoint defined in the file stands for the lower left corner of the map when looking

from the top, then it goes line by line (horizontal).
Tilesets are the group of textures used for the ground.
Here is the file format:

Header:
char[4]: file ID = "W3E!"
int: w3e format version [0B 00 00 00]h = version 11
char: main tileset [TS]
-TS Meaning-
- A Ashenvale
- B Barrens
- F Lordaeron Fall
- L Lordaeron Summer
- N Northrend
- V Village
- W Lordaeron Winter
- X City Dalaran
- Y City Lordaeron
int: custom tilesets flag (1 = using cutom, 0 = not using custom tilesets)
int: number 'a' of ground tilesets used (Little Endian) (note: should not be greater than 16 because

of tilesets indexing in tilepoints definition)
char[4]['a']: ground tilesets IDs (tilesets table)
Example: "Ldrt" stands for Lordaeron Dirt
(refer to the files "TerrainArt\Terrain.slk" located in your war3.mpq for more details)
int: number 'b' of cliff tilesets used (Little Endian) (note: should not be greater than 16 because

of tilesets indexing in tilepoints definition)
char[4]['b']: cliff tilesets IDs (cliff tilesets table)
Example: "CLdi" stands for Lordaeron Cliff Dirt
(refer to the files "TerrainArt\CliffTypes.slk" located in your war3.mpq for more details)
int: width of the map + 1 = Mx
int: height of the map + 1 = My
Example: if your map is 160x128, Mx=A1h and My=81h
float: center offeset of the map X
float: center offeset of the map Y
These 2 offsets are used in the scripts files, doodads and more.
The orginal (0,0) coordinate is at the bottom left of the map (looking from the top) and it's easier

to work with (0,0) in the middle of the map so usually, these offsets are :
-1*(Mx-1)*128/2 and -1*(My-1)*128/2
where:
(Mx-1) and (My-1) are the width and the height of the map
128 is supposed to be the size of tile on the map
/2 because we don't want the length but the middle.
-1* because we're "translating" the center of the map, not giving it's new coordinates

Data:
Each tilepoint is defined by a block of 7 bytes.
The number of blocks is equal to Mx*My.
short: ground height
C000h: minimum height (-16384)
2000h: normal height (ground level 0)
3FFFh: maximum height (+16383)
short: water level + map edge boundary flag*(see notes)
4bit: flags*(see notes)
4bit: ground texture type (grass, dirt, rocks,...)
1byte: texture details (rocks, holes, bones,...)
4bit: cliff texture type
4bit: layer height

*flags notes:
Flags values:
0x4000 --> boundary flag 1 (shadow generated by the world editor on the edge of the map)
0x0010 --> ramp flag (used to set a ramp between two layers)
0x0020 --> blight flag (ground will look like Undead's ground)
0x0040 --> water flag (enable water)
0x0080 --> boundary flag 2 (used on "camera bounds" area. Usually set by the World Editor "boundary"

tool.)

Water level:
Water level is stored just like ground height. The highest bit (bit 15) is used for the boundary

flag 1.

Tilepoint data example:
51 21 00 62 56 84 13
51 21 --(little endian)--> 0x2151 --(hex-->dec)--> height = 8529
00 62 --(little endian)--> 0x6200
--(extract boundary flag)--> (0x6200 & 0xC000) = 0x4000 boundary flag set
--(extract water data)--> (0x6200 & 0x3FFF) = 0x2200 --(hex-->dec)--> water level = 8704
56 --> 5 sets both water flag and ramp flag, 6 means tilepoint is using ground type #6 in the

tilesets table
84 --> means tilepoint is using detail texture #132 (=0x084)
13 --> 1 means cliff type #1 (cliff tilesets table), 3 means tilepoint on layer "3"
The tilepoint "final height" you see on the WE is given by:
(ground_height - 0x2000 + (layer - 2)*0x0200)/4
where "0x2000" is the "ground zero" level, 2 the "layer zero" level and "0x0200" the layer height.
= (0x2151 - 0x2000 + 1*0x0200)/4
= (8529 - 8192 + 512)/4
= 212,25

The tilepoint "water level" you see on the WE is given by:
(water_level - 0x2000)/4 - 89.6
where "0x2000" is the "ground zero" level, -89.6 is the water zero level (given by the water.slk

file: height=-0,7 --> water_zero_level = -0,7*128)
= 8704/4 - 89,6
= 38,4

In this case, water flag is set and water level is below the ground level so we will not see the

water. This is just an example and I don't think you can find such a tilepoint on a map. It was just

here for demonstration purpose.


5) "war3map.shd" The Shadow Map File
This file has no header, only raw data.
Size of the file = 16*map_width*map_height
1byte can have 2 values:
00h = no shadow
FFh = shadow
Each byte set the shadow status of 1/16 of a tileset.
It means that each tileset is divided in 16 parts (4*4).

6) "war3mapPath.tga" The Image Path file and/or "war3map.wpm" The Path Map File
Only one of these two file is used for pathing. Old War3 beta versions (<=1.21) use the

"war3mapPath.tga".
Since beta 1.30, Warcraft 3 uses a new file format instead: "war3map.wpm".
6a) "war3mapPath.tga" The Image Path file
It's an standard 32bits RGB TGA file with no compression and a black alpha channel.
The TGA format is really important because if Warcraft III doesn't recognise the file format, it'll

do weird things on the tilesets (like put blight everywhere)! Don't forget the alpha channel!
Each tile of the map is divided in 16 pixels (4*4 like in the shadow file), so the TGA width is

4*map_width and its height is 4*map_height and each pixel on the TGA affects a particular part of a

tileset on the map.
The color of a pixel sets the rules for that part.
The top left corner of the image is the upper left corner on the map.

Header format (18 bytes):
byte: ID Length = 0
byte: Color Map Type = 0
byte: Image Type = 2 (uncompressed RGB)
-- Color Map Specification (5 bytes) --
byte[2]: First Entry Index = 0
byte[2]: Color Map Length = 0
byte: Color Map Entry Size = 0
-- Image Spec (10 bytes) --
byte[2]: X origin = 0
byte[2]: Y origin = 0
byte[2]: image width (little endian)
byte[2]: image height (little endian)
byte: Pixel depth = 32 (=0x20)
byte: Image Descriptor = 0x28 (0x20=image starts from top left, 0x08=8bit for alpha chanel)
Example (where "XX XX" is a width and "YY YY" a height):
00 00 02 00 00 00 00 00 00 00 00 00 XX XX YY YY 20 28

Data:
One pixel is defined by 4 bytes:
BB GG RR AA
Where:
BB is the blue value (0 or 255)
GG is the green value (0 or 255)
RR is the red value (0 or 255)
AA is the alpha chanel value (set to 0)
There are 4*4 pixels for 1 tileset.
The TGA width is map_width*4.
The TGA height is map_height*4.

Here is the color code:
Colour: Rules:
White no build, no walk, no fly
Red build ok, no walk, fly ok
Yellow build ok, no walk, no fly
Green build ok, walk ok, no fly
Cyan no build, walk ok, no fly
Blue no build, walk ok, fly ok
Magenta no build, no walk, fly ok
Black build ok, fly ok, walk ok
To sum up, when red is set it means "no walk", when green is set "no fly" and when blue is set "no

build".
The alpha channel is used to set where blight is (black = normal, white = blight).


6b) "war3map.wpm" The Path Map File
Header:
char[4]: file ID = 'MP3W'
int: file version = 0
int: path map width (=map_width*4)
int: path map height (=map_height*4)

Data:
Each byte of the data part is a part of a tileset exactly like for the TGA.
Data size: (map_height*4)*(map_with*4) bytes
Flags table:
0x01: 0 (unused)
0x02: 1=no walk, 0=walk ok
0x04: 1=no fly, 0=fly ok
0x08: 1=no build, 0=build ok
0x10: 0 (unused)
0x20: 1=blight, 0=normal
0x40: 1=no water, 0=water
0x80: 1=unknown, 0=normal

Exmaple:
value: use:
00 bridge doodad
08 shallow water
0A deep water
40 normal ground
48 water ramp, unbuildable grounds, unbuildable parts of doodads
CA cliff edges, solid parts of doodads (no build and no walk)
CE edges of the map (boundaries)


7) "war3map.doo" The doodad file for trees
The file contains the trees definitions and positions.
Here is the Format:
Header:
char[4]: file ID = "W3do"
int: file version = 7
int: unknown (often set to [09 00 00 00]h)
int: number of trees defined
Data
Each tree is defined by a block of 42 bytes organized like this:
char[4]: Tree ID (can be found in the file "Units\DestructableData.slk")
int: Variation (little endian)
float: Tree X coordinate on the map
float: Tree Y coordinate on the map
float: Tree Z coordinate on the map
float: Tree angle (radian angle value)(degree = radian*180/pi)
float: Tree X scale
float: Tree Y scale
float: Tree Z scale
byte: Tree flags*
byte: Tree life (integer stored in %, 100% is 0x64, 170% is 0xAA for example)
int: Tree ID number in the World Editor (little endian) (each tree has a different one)

*flags:
0= invisible and non-solid tree
1= visible but non-solid tree
2= normal tree (visible and solid)

To sum up how it looks:
tt tt tt tt vv vv vv vv xx xx xx xx yy yy yy yy zz zz zz zz aa aa aa aa xs xs xs xs ys ys ys ys zs

zs zs zs ff ll dd dd dd dd
where:
tt: type
vv: variation
xx: x coordinate
yy: y coordinate
zz: z coordinates
aa: rotation angle
xs: x scale
ys: y scale
zs: z scale
ff:unknown
ll: life
dd: doodad number in the editor

Example (this is the second tree of Legend):
4C 54 6C 74 08 00 00 00 00 00 74 45 00 00 70 44 00 10 24 44 E5 CB 96 40 98 85 98 3F 98 85

98 3F 98 85 98 3F 02 64 8D 01 00 00
4C 54 6C 74 --> LTlt (tree type)
08 00 00 00 --> 00000008 = variation #8 (changes the shape of the tree)
00 00 74 45 --> X=3904.
00 00 70 44 --> Y=960.
00 10 24 44 --> Z=656.25
E5 CB 96 40 --> Angle (float value=4.7123895, angle=270°)
98 85 98 3F --> X_Scale=1.191577
98 85 98 3F --> Y_Scale=1.191577
98 85 98 3F --> Z_Scale=1.191577
02 --> tree is solid and selectable
64 --> life=100% of default tree life
8D 01 00 00 --> 0000018D=397, tree number 397

After the last tree definition, there are 8 bytes set to 00h. These last 8 bytes set to 0 indicate

that there are no more trees in the file so these 8 bytes are REQUIERED!


8) "war3mapUnits.doo" The doodad file for items and such
The file contains the doodad units definitions and positions.
Here is the Format:
Header:
char[4]: file ID = "W3do"
int: file version = 7
int: unknown (often set to [09 00 00 00]h)
int: number of doodad units defined
Data
Each doodad is defined by a block of bytes (vraiable length) organized like this:
char[4]: type ID
int: variation
float: coordinate X
float: coordinate Y
float: coordinate Z
float: rotation angle
float: scale X
float: scale Y
float: scale Z
byte: flags*
int: player number (owner) (player1 = 0, 16=neutral passive)
byte: unknown
byte: unknown
int: hit points (-1 = use default)
int: unknown (usually -1)
int: number "s" of dropped item sets
"s" times dropped item sets structures:
int: number "d" of dropable items
"d" times dropable items structures:
char[4]: item ID ([00 00 00 00]h = none)
if item ID starts with "YYI" followed by a number "num", then random item of level = num
int: % chance to be dropped
int: gold amount (default = 12500)
float: unknown (often set to -1)
int: unknown (often set to 1)
int: unknown
int: unknown
int: random Unit
0 = Any neutral passive building
1 = random unit from random group
2 = random unit from custom table
int: random unit type any neutral passive building of level
int: custom color (-1 = none, 0 = red, 1=blue,...)
int: Waygate: active destination number (-1 = none)
int: creation number
*flags: may be similar to the war3map.doo flags

9) "war3map.w3i" The info file
It contains some of the info displayed when you start a game.

Format:
int: file format version = 18
int: number of saves (map version)
int: editor version (little endian)
String: map name
String: map author
String: map description
String: players recommended
float[8]: "Camera Bounds" as defined in the JASS file
int[4]: camera bounds complements* (see note 1) (ints A, B, C and D)
int: map playable area width E* (see note 1)
int: map playable area height F* (see note 1)
*note 1:
map width = A + E + B
map height = C + F + D
int: flags
0x0001: 1=hide minimap in preview screens
0x0002: 1=modify ally priorities
0x0004: 1=melee map
0x0008: 1=playable map size was large and has never been reduced to medium (?)
0x0010: 1=masked area are partially visible
0x0020: 1=fixed player setting for custom forces
0x0040: 1=use custom forces
0x0080: 1=use custom techtree
0x0100: 1=use custom abilities
0x0200: 1=use custom upgrades
0x0400: 1=map properties menu opened at least once since map creation (?)
0x0800: 1=show water waves on cliff shores
0x1000: 1=show water waves on rolling shores
char: map main ground type
Example: 'A'= Ashenvale, 'X' = City Dalaran
int: Campaign background number (-1 = none)
String: Map loading screen text
String: Map loading screen title
String: Map loading screen subtitle
int: Map loading screen number (-1 = none)
String: Prologue screen text
String: Prologue screen title
String: Prologue screen subtitle
int: max number "MAXPL" of players
Then, there is MAXPL times a player data like described below.
int: max number "MAXFC" of forces
int: Foces Flags
0x00000001: allied (force 1)
0x00000002: allied victory
0x00000004: share vision
0x00000010: share unit control
0x00000020: share advanced unit control
int: unknown (usually -1)
Then, there is MAXFC times a force data like described below.
int: if 0 it means that we reach the end of the w3i
if it's non-zero, the following bytes define special settings for the map (techtree, upgrades,

...)

Players data format:
int: unknown
int: player type
1=Human, 2=Computer, 3=Neutral, 4=Rescuable
int: player race
1=Human, 2=Orc, 3=Undead, 4=Night Elf
int: 00000001 = fixed start position
String: Player name
float: Starting coordinate X
float: Starting coordinate Y
int: ally low priorities flags (bit "x"=1 --> set for player "x")
int: ally high priorities flags (bit "x"=1 --> set for player "x")

Forces data format:
String: Force name
int: unknown
int: unknown


10) "war3map.wts" The trigger string data file
Open it with notepad and you'll figure out how it works.
Each trigger string is defined by a number and a value for this number.
When Warcraft meets a "TRIGSTR_xxx" (where "xxx" is a number), it will look in the trigger string

table to find the corresponding string and replace the trigger string by that value.
Example:
in the .WTS file you have:

STRING 0
{
Blah blah blah...
}

Then either in the .J, or in the .W3I, Warcraft finds a TRIGSTR_000, it'll look in the table for

trigger string number 0 and it'll find that the value to use is "Blah blah blah" instead of

"TRIGSTR_000".
Here "STRING" is followed by the trigger string number which is supposed to be different for each

trigger string, then "{" indicates the begining of the string value, "Blah blah blah..." is the

value and "}" indicates the end of the trigger string definition. The value can contain several

lines and special color control codes (like |c00BBGGRR).


11) "war3mapMap.blp" the minimap image
The BLP file contain the JPEG header and the JPEG raw data separated.
BLP stands for "Blip" file which I guess is a "BLIzzard Picture".
Header:
char[4]: file ID ("BLP1")
int: unknown
int: unknown
int: image width
int: image height
int: unknown
int: unknown
int: data offset (from the begining of the file)
int[15]: unknown
int: header size "h" (usually 0x00000270)
byte[h]: header
followed by 0 bytes until the begining of the jpeg data.
address=data offset: raw jpeg data till the end of the file


12) "war3map.mmp" The menu minimap
Header:
int: unknown (usually 0)
int: number of datasets
Data:
The size of a dataset is 16 bytes.
int: icon type
- Icons Types:
- 00: gold mine
- 01: house
- 02: player start (cross)
int: X coordinate of the icon on the map
int: Y coordinate of the icon on the map
- Map Coordinates:
- top left: 10h, 10h
- center: 80h, 80h
- bottom right: F0h, F0h
byte[4]: player icon color
- Player Colors (BB GG RR AA = blue, green, red, alpha channel):
- 03 03 FF FF : red
- FF 42 00 FF : blue
- B9 E6 1C FF : cyan
- 81 00 54 FF : purple
- 00 FC FF FF : yellow
- 0E 8A FE FF : orange
- 00 C0 20 FF : green
- B0 5B E5 FF : pink
- 97 96 95 FF : light gray
- F1 BF 7E FF : light blue
- 46 62 10 FF : aqua
- 04 2A 49 FF : brow
- FF FF FF FF : none

13) "war3map.w3u" The custom units file
Most of the W3U File specifications is from BlacKDicK.
W3u files have a initial long and then comes two tables. Both look the same.
First table is original units table (Original Blizzard Units).
Second table is user-created units table (Units created by the map designer).

Header:
int: W3U Version = 1
"x" bytes: Original Units table*
"y" bytes: User-created units table*

Data:
*Table definition:
int: number "n" of units on this table.
If 0 on original table, then skip default unit table. This is the number of following units.
Even if we don't have any changes on original table, this value must be there.
"n" times a unit definition structure*.

*Unit definition structure:
char[4]: original unit ID (get the IDs from "Units\UnitData.slk" of war3.mpq)
char[4]: new unit ID. If it is on original table, this is 0, since it isn't used.
int: number "m" of modifications for this unit
"m" times a modification structure*

*Modification structure:
char[4] modification ID code (get the IDs from "Units\UnitMetaData.slk" of war3.mpq)
int: variable type* "t" (0=int, 1=real, 2=unreal, 3=String,...)
"t" type: value (length depends on the type "t" specified before)
int: end of unit definition (usually 0)

*Variable types:
0=int
1=real
2=unreal
3=string
4=bool
5=char
6=unitList
7=itemList
8=regenType
9=attackType
10=weaponType
11=targetType
12=moveType
13=defenseType
14=pathingTexture
15=upgradeList
16=stringList
17=abilityList
18=heroAbilityList
19=missileArt
20=attributeType
21=attackBits

15) "war3map.wtg" The triggers names file
Header:
char[4]: file ID (WTG!)
int: wtg file format version = 4
int: number "n"

Data:
triggers names blocks*
int[2]: end of data (8 bytes set to 0)

*Triggers names block format:
int: number "m"
String: trigger name


15) "war3map.w3c" The cinematic file
Header:
int: file ID = 0
int: file version = 18

Data Block Fromat:
float:
float:
float: (often 0)
float:
float:
float:
float: (often 0)
float:
float:
float:
String: Cinematic name


Data:


16) "war3map.w3r" The triggers regions file
Header:
int:
int:

Data:
float:
float:
float:
float:
String:
int:
int:
byte[5]: (often 00 FF 80 80 FF)

17) "war3map.w3s" The sounds definition file
Header:
int: file format version = 1
int: number "n" of sounds defined

Data:
"n" times a sound definition structure*

*Sound definition structure:
String:
String: sound file
String: EAX flags
int[17]:


18) "war3map.wct"
int: unknown
int: number "n" of ints
ints[n]: unknown


18) The others files
war3map.imp = ? (imports?)
war3mapImported\*.* = files imported and saved by the world editor (sounds)
(signature) = signature of the w3m file
(listfile) = list of files stored in the w3m file
(attributes) = attributes of files in the w3m file

I just updated the main posts and added all the new stuff I just found in the retail. Hardcore moders, enjoy it!
;)

Where does ramp flag (used to set a ramp between two layers) use in W3e file?
Explain little more specific usage

The ramp flags are used to make a ramp between to layers.
The W3E format can use up to 16 layers (only 15 are supported by war3 though). Layer level 0 is the really bottom one, layer 15 is the really top one. Neighbour tiles located on two different layers are always separted by a cliff but sometimes when the two layers are neighbouring, you can set a ramp between them instead of a cliff. However a ramp will exists only if the separation between the two layers il like a "straight line".

Form example, you got such a separation between layer 3 and 4:
(see from the top)

33333444
33334444
33333444
33333444
33333444
33344444
33334444

The only place where you can set a ramp is the "R" zone:

33333444
33334444
3333RR44
3333RR44
3333RR44
33344444
33334444

Of course, you will see no difference if you set a ramp in a flat area on the same layer. It'll also change nothing between 2 non-neighbour layers like 3 and 5.

In the beta, there was a way to crash the wolrd editor when settings ramp flags where it wasn't possible but now the retail WE works just fine.

Thank reply.
If is broad way that explain, speak sloping road in war3editor?

Sloping roads... hmm I don't want you to mix up everything.
I just want to make sure you get it.
You can set on the same layer, the ground hieght and make a slope road but it'll not link two layers together. I mean, you got a cliff, you raise the ground to make it reach the top of the cliff but you'll still have a cliff and utnits wont walk through. A ramp flag just says "remove the cliff here between the two layers and allow units to walk from one to the other and to make it look good, make a sloping road".

Cut of the ground:
(Layer 2 | Layer 3)

Raised ground:

______/][¨¨¨
.......... ^---- here you still got a cliff

Ramp flag set:

______/¨¨¨¨
......... ^---- here you don't have a cliff anymore

Note: you don't need to raise the ground before making a ramp. Don't!

Thanks to reply really.
Ask many helps.

Wow, great job! :)
I still have a question; what's the use of the shadow file?

The shd (shadow file) is the pre-calculated shadows you see on the ground. For example, if you make an empty flat map with just a big doodad in the middle, that doodad will cast a little shadow on the ground. Instead of computing shadows in real time (ie. during the game), when you create your map you can save it and compute shadows (if you don't, you wont have doodads or hills/cliffs shadows as War3 doesn't compute them in real time). That will generate the shd file which is a record of where shadows are placed.
So it's possible to edit this file and make fake shadows for example, like a shadow of a big skull in the middle of the map.
Note: shadows are a little different from map boundaries which are darker.

Merci ;)

(I'm trying to make a random map generator... :) )

I found that the unknown int, in the w3i file:

Players data format:
int: unknown

This int shouldn't be 0 everytime; puting 0 to each player data means "there is only one player in the map". I tried to put 0 for the first player, then 1 for the second, then 2, then 3; it worked, so maybe it is some index for the players.

It needs more tests but be warned if you change the file, this unknown int is quite important actually...

Good work! I understood the most things and I also knew some things before. Anyway there are two things, I think, that are wrong:
1) The link for Inside MoPaQ is wrong. a) Because CampaignCreations changed to www.campaign creations.org (without the space, this is just because of link censoration). b) This is the new location for it: http://shadowflare.ancillaediting.ne...opaq/index.htm

2) You said that Warcraft III uses files from folder by default. I say that it only uses files from folders if the registry key "Allow Local Files" in HKEY_CURRENT_USER\Software\Blizzard Entertainment\Warcraft III\ is set to 1 (it is a DWORD value). You can do this easilier by downloading my tool War3Config (and using it...).

In addition I just want to say that this thread should be set to "Important".

Actually it works here:
http://www.campaign creations.org/st..._the_storm_api
... without the space