[Compendium] Model Editing

[A_Snake01]

Model Changing

Sections:

1.0 What is Model Changing?
1.1 - Why Model Change?
1.2 - Burning Crusade
1.3 - Model Changing for Advantages

2.0 File types
2.1 -MPQ Files
2.2 -M2
2.3 -BLP
2.4 -DBC
2.5 -XML
2.6 -TTF
2.7 -WDL
2.8 -WDT
2.9 -ADT
2.10 -MP3
2.11 -WAV
2.12 -WMO
2.13 -WLW
2.14 -MDX


3.0 Progams
3.1 -MyWarCraftStudio
3.2 -WoW Model Viewer
3.3-5 -Converters
3.6 -WoW Map Viewer

4.0 Methods and Techniques
4.1 -The Basics
4.2 -DBC Editing
4.3 -Creatures
4.4 -Instance Switching
4.5 -Race Conversions
4.6 -Making Custom Things
4.7 - My helmet size is off after a race swap!

5.0 Errors
5.1. -Green models
5.2 -Non Loading models
5.3 -DBC Error
5.4 -I run right through my Camp Fire edit!

6.0 Theory Crafting
6.1 -Why it works

7.0 Sources
------

I am writing this because I've gotten very tired of seeing multiple posts asking if X is possible. I see them a lot and thought, why not just write a guide, a compendium of sorts. And so here it is. This is what I hope people use as a dictionary.

Think of this guide, document, whatever you want to call it as a Game. I will tell you the basics of what you need to know, but I will leave some of the better things hidden or left out entirely. I cover a lot here, but there are more things than just this. I want this, however, to be read as an FAQ of sorts.
-----

1.0
What is Model Changing?

Model changing is the act of going into the files of Warcraft and examining, switching, editing the files within them to appear and function as if it were something else. The thing with model changing it that it is all client side. None of it can be seen by anyone else, unless they are running the same change you are, which is unlikely. Model changing is much more than simply changing models. Many a time it can be, but you can do much more than that.

Model Changing is also a gift. There are many people who, like me, consider this to be fantastic. Warcraft would have grown boring a long time ago if not for this. Raiding, fun for a while, but ultimately boring. PvP? Totally Pointless. I can go in and demolish players in a static area with permanently set objectives, or conversely I can get demolished by an honor farming group. Yeah, that's fun. I myself prefer the spontaneity of world pvp, which is scarce, if it still exists. Model Changing puts life into the game for me, and others.

1.1
Why Model Change?

Remember, there is no limit to what you can do with this. Make your mediocre no name gear into awesome Naxxramas gear. You can turn those ugly gnomes into awesome Orcs. You can make that hunter pet you have look like a really cool demon. These are just some incredibly basic things that come to me off the top of my head, you can do so much more than what is listed just here. You can do near everything and anything.

1.2
Burning Crusade - complimented, ignore this section.

Please take note. The Burning Crusade, the expansion to World of Warcraft implements a new file structure into all their models.

Quoted from Linhuye himself: "M2 format changes. Bone structure has been revised. Rotating four yuan a few bytes of data being compressed into eight int16 * 4, reducing the number of failures four yuan."
This means that you cannot use any model file from either version in the other.

This means that when The Burning Crusade comes out in January, your current edits will be non functioning. I recommend copying any treepaths of your files and saving them in a secure area. You can use those to find your files, without manually going through all the thousands of files to get your previous ones.

1.3
Model Changing for Advantages

Model changing is fun. It's amazing, and it's awesome. It can be done to do anything, anything at all: this leads to the human nature of trying to find advantages in it. Model changing can be used to gain advantages in PvP and PvE pretty easily. I must stress this; do not do this. I've seen people get banned over Model Changing because they were getting pvp advantages, stuff like getting under the terrain, making certain models more visible, etc.

Doing this will increase the chance of your bannination and the chance of getting this nerfed. Model changing has already been nerfed, twice, in fact. I don't want them to do it a third time. Please, don't use it as a hack, use it as an exploration method.

2.0
File Types
Preface: Of course, the idea of model changing is to turn File X into file Y. But you have to take into account what the actual type of the file is. You cannot ever load one file of one type as a file of another type. That is to say, you can not load a building file, where normally a creature would be. Aside from the awkwardness of having a walking, talking, and possibly deadly House, it just won't work. You can't load it in place of another.(Read: Burning Crusade)

All the files from the Warcraft game are all pakced into multiple MPQ files. MPQ files function as .Rar or .Zip files. They are a huge folder that contain other folders and files. Warcraft unpacks them during game-play and uses the files within.

2.1
Mo'PaQ(MPQ) files have an ability to store multiple files of the exact name. This is for internalization, but it's handy none the less.

2.2
M2:
M2 is the file type used for Models. All characters, creatures and items are model files. Usually they have no collision and serve for visual purposes. The exception with the collision happens with Trees, bridges and rocks. Anything that is not a building or cave is usually an M2 file.

Everything in the Creatures folder, Character Folder, Cameras Folder, Item and Environments are m2s. Also, Spells are M2s as well. Anything with that functions as a visual aspect is a model file.This also goes for Skyboxes.

Alone, an M2 is about as detailed as an N64 model. But with a texture...

2.3
BLP:
BLP files are texture files. They are always in the traditional UV Mapped, square box style. Each part of the texture file is assigned to a certain part of an M2 file. Textures offer a huge amount of reusable content. You can take a regular model that you've seen in different places, and add a new texture to it. It's effectively a new beast. This technique is employed a great deal throughout warcraft. Desieased wolves, different colored Elementals, and most notably yet probably least realized is Character textures. There are a few hundred different textures applied to each race. Not at a time, but in general. You can make your Human character white or black and anywhere in between because it's applied a new texture to it.

Everything has a texture. Without it, the object would appear as a matte white nothing. There would be no shading or detailing without a texture. When a texture is applied to a model, the model looks like it gains proper shading, coloring and all that. This is not the case. It's actually a very well done illusion. The Shading is all contained on the texture map.

2.4
DBC:
DBC files are Database Cache files. They contain everything the client does and sees. One would think that the WoW servers actually control most of Warcraft, but this is not the case. The server really only controls Rolls(Which is why you can't make roll hacks - stop asking.), Loot drops and creature spawns/pathing. Everything else is client side.

DBC files control everything from the amount of textures a model has, what the classes are called( you can edit it to be anything[Read: Warlock to Elementalist in my pitiful overhaul. :P]), what area names appear as, factions etc. Everything that has text or models can be controlled through the DB Files.

2.5
XML:
Not much to say here, these are used for interface files. This is where Blizzard and Add on developers write UI scripts. LUA too. Anything that pops up from the UI comes from here. The character screen, Group UI, Raid UI, Auction House, Bank, Talents etc, it's all XML/LUA.

2.6
TTF:
These are Font Files. The text you see in game is from a TTF file. The way "World of Warcraft" appears in it's cool, fancy text is from a TTF files. It's probably possible to decompile them and get the font to write with.

2.7
WDT:
Taken directly from WoWDev.org

 WDT files specify exactly which map tiles are present in a world, if any, and can also reference a "global" WMO. They have a chunked file structure

WDT, as well as ADT, WMO, M2 and WDL files follow a chunked structure similar to IFF, consisting of chunks of the following format:

Offset 	
Type 	
Description
0x0 	char[4] 	Chunk identifier - in reverse character order
0x4 	uint32 	Chunk size
0x8 	[size] bytes 	Chunk data

The initial chunk in all of these files is an MVER chunk, specifying the version of the map files in a 32-bit integer. This version is always 0x12. (I am assuming, for version 1.2 of the file format?)

All files use Intel (little-endian) byte order.

Mphd Chunk

Header chunk. Contains 8 32-bit integers. The first integer is 1 for maps without any terrain, 0 otherwise. The rest are always 0.
MAIN chunk

Map tile table. contains 64x64 = 4096 records of 8 bytes each. Each record can be considered a 64-bit integer: 1 if a tile is present, 0 otherwise.
MWMO, MODF chunks

For worlds with terrain, the MWMO chunk is empty and there is no MODF chunk. For a global-WMO-only world, these chunks specify an object in the same format as it is already done in ADT files.

2.8

WDL:
WDL files preform a multiple number of functions. They can draw Hightmaps for Wow. Anyone familar with wowMapViewer would know what a Hightmap is. They draw low resolution terrain in the background. Ever been walking along, and look toward the horizon to see spikes of terrain? Turn the camera and the spikes change shape, often to reveal more. This is controlled though WDL files. They also determine what files are loaded for the Minimap, and it's been said, yet not proven to my knowledge, that they control the pathing of NPCS. In which case my statement earlier about what the server controls is wrong. But until I see proof of this or someone can confirm it for me, I will stand by it.

WDL Files are chunked, but it's less iteresting.

2.9
ADT:
ADT files contain map and terrain information. The way the terrain is formed, the tileset, the objects that would load are all contained in ADT format. They are chunked as well.
The following code is about the chunked file structure. The information contained could be of use for developers.

 ADT
From Wowmapview
Table of contents
1 ADT Files

1.1 MHDR chunk
1.2 MCIN chunk
1.3 MTEX chunk
1.4 MMDX chunk
1.5 MMID chunk
1.6 MWMO chunk
1.7 MWID chunk
1.8 MDDF chunk
1.9 MODF chunk
2 MCNK chunks

2.1 MCVT sub-chunk
2.2 MCNR sub-chunk
2.3 MCLY sub-chunk
2.4 MCRF sub-chunk
2.5 MCSH sub-chunk
2.6 MCAL sub-chunk
2.7 MCLQ sub-chunk
2.8 MCSE sub-chunk
[edit]
ADT Files

ADT files contain terrain and object information for map tiles. They have a chunked structure just like the WDT files.

A map tile is split up into 16x16 = 256 map chunks. (not the same as file chunks, although each map chunk will have its own file chunk ) So there will be a few initial data chunks to specify textures, objects, models, etc. followed by 256 MCNK (mapchunk) chunks Each MCNK chunk has a small header of its own, and additional chunks within its data block, following the same id-size-data format.
[edit]
MHDR chunk

struct SMAreaHeader // 03-29-2005 By ObscuR
{
/*000h*/ UINT32 pad;
/*004h*/ UINT32 offsInfo;
/*008h*/ UINT32 offsTex;
/*00Ch*/ UINT32 offsModels;
/*010h*/ UINT32 offsModelsIds;
/*014h*/ UINT32 offsMapObejcts;
/*018h*/ UINT32 offsMapObejctsIds;
/*01Ch*/ UINT32 offsDoodsDef;
/*020h*/ UINT32 offsObjectsDef;
/*024h*/ UINT32 pad1;
/*028h*/ UINT32 pad2;
/*02Ch*/ UINT32 pad3;
/*030h*/ UINT32 pad4;
/*034h*/ UINT32 pad5;
/*038h*/ UINT32 pad6;
/*03Ch*/ UINT32 pad7;
/*040h*/
};

Header chunk. Contains offsets (relative to 0x14) for some other chunks that appear in the file. Since the file follows a well-defined structure, this is redundant information.
[edit]
MCIN chunk

Index for MCNK chunks. Contains 256 records of 16 bytes, which have the following format:
Offset Type Description
0x0 uint32 MCNK chunk absolute offset
0x4 uint32 MCNK size in bytes
0x8 8 bytes 0


struct SMChunkInfo // 03-29-2005 By ObscuR
{
/*000h*/ UINT32 offset;
/*004h*/ UINT32 size;
/*008h*/ UINT32 flags;
/*00Ch*/ UINT32 asyncId;;
/*010h*/
};

This is also redundant information but kind of convenient.
[edit]
MTEX chunk

List of textures used by the terrain in this map tile. A contiguous block of zero-terminated strings, that are complete filenames with paths. The textures will later be identified by their position in this list.
[edit]
MMDX chunk

List of filenames for M2 models that appear in this map tile. A contiguous block of zero-terminated strings.
[edit]
MMID chunk

Lists the relative offsets of string beginnings in the above MMDX chunk. (sort of redundant) One 32-bit integer per offset.
[edit]
MWMO chunk

List of filenames for WMOs (world map objects) that appear in this map tile. A contiguous block of zero-terminated strings.
[edit]
MWID chunk

Lists the relative offsets of string beginnings in the above MWID chunk. (again, redundant) One 32-bit integer per offset.
[edit]
MDDF chunk

Placement information for doodads (M2 models). 36 bytes per model instance.
Offset Type Description
0x00 uint32 ID (index in the MMDX list)
0x04 uint32 unique identifier for this instance
0x08 3 floats Position (X,Y,Z)
0x14 3 floats Orientation (A,B,C)
0x20 uint32 scale factor * 1024


struct SMDoodadDef // 03-31-2005 By ObscuR
{
/*000h*/ UINT32 nameId;
/*004h*/ UINT32 uniqueId;
/*008h*/ float pos[3];
/*00Ch*/
/*010h*/
/*014h*/ float rot[3];
/*018h*/
/*01Ch*/
/*020h*/ UINT16 flags;
/*022h*/ UINT16 scale;
/*024h*/
};

The instance information specifies the actual M2 model to use, its absolute position and orientation within the world. The orientation is defined by rotations (in degrees) about the 3 axes as such (this order of operations is for OpenGL, so the transformations "actually" happen in reverse):

1. Rotate around the Y axis by B-90
2. Rotate around the Z axis by -A
3. Rotate around the X axis by C

Finally the scale factor is given by an integer, multiplied by 1024. So the model needs to be scaled by scale/1024. I wonder why they didn't just use a float.
[edit]
MODF chunk

Placement information for WMOs. 64 bytes per wmo instance.


Offset Type Description
0x00 uint32 ID (index in the MWMO list)
0x04 uint32 unique identifier for this instance
0x08 3 floats Position (X,Y,Z)
0x14 3 floats Orientation (A,B,C)
0x20 3 floats Position 2 - ?
0x2C 3 floats Position 3 - ?
0x38 uint16 unknown (always 0?)
0x3A uint16 Doodad set index
0x3C uint32 Name set


struct SMMapObjDef // 03-29-2005 By ObscuR
{
/*000h*/ UINT32 nameId;
/*004h*/ UINT32 uniqueId;
/*008h*/ float pos[3];
/*00Ch*/
/*010h*/
/*014h*/ float rot[3];
/*018h*/
/*01Ch*/
/*020h*/ float extents[6];
/*024h*/
/*028h*/
/*02Ch*/
/*030h*/
/*034h*/
/*038h*/ UINT32 flags;
/*03Ch*/ UINT16 doodadSet;
/*03Eh*/ UINT16 nameSet;
/*040h*/
};

The positioning and orientation is done the same way as in the MDDF chunk. There is no scaling. Two additional positions and two integers are also given. They might or might not be used for lighting...?

The unique identifier is important for WMOs, because multiple map tiles might want to draw the same WMO. This identifier is used to ensure that each specific instance can only be drawn once. (a unique identifier is required because the model name is not usable for this purpose, since it is possible to have more than one instance of the same WMO, like some bridges in Darkshore)
[edit]
MCNK chunks

After the above mentioned chunks come 256 individual MCNK chunks, row by row, starting from top-left (northwest). The MCNK chunks have a large block of data that starts with a header, and then has sub-chunks of its own.

Each map chunk has 9x9 vertices, and in between them 8x8 additional vertices, several texture layers, normal vectors, a shadow map, etc.

The MCNK header is 128 bytes large. I will only list the known fields in the header.


Offset Type Description
0x3C uint32 holes in terrain
0x68 float Z' base coordinate
0x6C float X' base coordinate
0x70 float Y base coordinate


struct SMChunk // 03-29-2005 By ObscuR
{
enum
{
FLAG_SHADOW,
FLAG_IMPASS,
FLAG_LQ_RIVER,
FLAG_LQ_OCEAN,
FLAG_LQ_MAGMA,
};
/*000h*/ UINT32 flags;
/*004h*/ UINT32 IndexX;
/*008h*/ UINT32 IndexY;
/*00Ch*/ UINT32 nLayers;
/*010h*/ UINT32 nDoodadRefs;
/*014h*/ UINT32 offsHeight;
/*018h*/ UINT32 offsNormal;
/*01Ch*/ UINT32 offsLayer;
/*020h*/ UINT32 offsRefs;
/*024h*/ UINT32 offsAlpha;
/*028h*/ UINT32 sizeAlpha;
/*02Ch*/ UINT32 offsShadow;
/*030h*/ UINT32 sizeShadow;
/*034h*/ UINT32 areaid;
/*038h*/ UINT32 nMapObjRefs;
/*03Ch*/ UINT32 holes;
/*040h*/ UINT16 unk1;
/*040h*/ UINT16 unk2;
/*044h*/ UINT32 unk3;
/*048h*/ UINT32 unk4;
/*04Ch*/ UINT32 unk5;
/*050h*/ UINT32 predTex;
/*054h*/ UINT32 noEffectDoodad;
/*058h*/ UINT32 offsSndEmitters;
/*05Ch*/ UINT32 nSndEmitters;
/*060h*/ UINT32 offsLiquid;
/*064h*/ UINT32 sizeLiquid;
/*068h*/ float pos[3];
/*06Ch*/
/*070h*/
/*074h*/ UINT32 textureId;
/*078h*/ UINT32 props;
/*07Ch*/ UINT32 effectId;
/*080h*/
};


The X' and Z' coordinates specify the top left corner of the map chunk, but they are in an alternate coordinate system! (yay for consistency!) This one has its 0,0 point in the middle of the world, and has the axes' directions reversed.

X = 32*533.3333 - X'

Z = 32*533.3333 - Z'

The Y base coordinate acts as a 'zero point' for the height values in the upcoming height map - that is, all height values are added to this Y height.

About the holes in the terrain: This is a bitmapped field, the least significant 16 bits are used row-wise in the following arrangement with a 1 bit meaning that the map chunk has a hole in that part of its area:
0x1 0x2 0x4 0x8
0x10 0x20 0x40 0x80
0x100 0x200 0x400 0x800
0x1000 0x2000 0x4000 0x8000

With this I've been able to fix some holes, the most obvious one being the Gates of Ironforge but there are some glitches for some other holes like the Lakeshire Inn - maybe this would require the more detailed height maps or for me to use a less cheap way to omit the hole triangles.
[edit]
MCVT sub-chunk

These are the actual height values for the 9x9+8x8 vertices. 145 floats in the following order/arrangement:.


1 2 3 4 5 6 7 8 9
10 11 12 13 14 15 16 17
18 19 20 21 22 23 24 25 26

. . . . . . . .


WoWmapview currently only uses the "outer" 9x9 vertices, since I couldn't figure out a way to stripify the more detailed geometry.

*
o

Inner 8 vertices are only rendered in WoW when its using the up-close LoD. Otherwise, it only renders the outer 9. -Eric

*
o


+ + + + [guest] : try this one: ( stripsize is now : 16*18 + 7*2 + 8*2 )

void stripify(V *in, V *out)
{
for (int row=0; row<8; row++) {
V *thisrow = &in[row*9*2];
V *nextrow = &in[row*9*2 + 9];
V *overrow = &in[(row+1)*9*2];
if (row>0) *out++ = thisrow[0];// jump end
for (int col=0; col<8; col++) {
*out++ = thisrow[col];
*out++ = nextrow[col];
}
*out++ = thisrow[8];
*out++ = overrow[8];
*out++ = overrow[8];// jump start
*out++ = thisrow[0];// jump end
*out++ = thisrow[0];
for (int col=0; col<8; col++) {
*out++ = overrow[col];
*out++ = nextrow[col];
}
if (row<8) *out++ = overrow[8];
if (row<7) *out++ = overrow[8];// jump start
}
}

+ + + +

- will do, thanks - Z.
[edit]
MCNR sub-chunk

Normal vectors for each vertex, encoded as 3 signed bytes per normal, in the same order as specified above.

The size field of this chunk is wrong! Actually, it isn't wrong, but there are a few junk (unknown?) bytes between the MCNR chunk's end and the next chunk. The size of the MCNR chunk should be adjusted to 0x1C0 bytes instead of 0x1B3 bytes.

Normals are stored in X,Z,Y order, with 127 being 1.0 and -127 being -1.0. The vectors are normalized.
[edit]
MCLY sub-chunk

Texture layer definitions for this map chunk. 16 bytes per layer, up to 4 layers.


Offset Type Description
0x0 uint32 texture ID (offset into MTEX list)
0x4 uint32 flags
0x8 uint32 offset to alpha map
0xC uint32 detail texture ID


Flag Description
0x80 ?
0x100 Use alpha map - set for every layer after the first


The flags 0x1E0 are often used for Lava textures that might be animated in the Searing Gorge. Not sure about the individual flags. The detail texture ID refers to the first column in GroundEffectTexture.dbc.


struct SMLayer // 03-29-2005 By ObscuR
{
/*000h*/ UINT32 textureId;
/*004h*/ UINT32 props;
/*008h*/ UINT32 offsAlpha;
/*00Ch*/ UINT32 effectId;;
/*010h*/
};



The size of this chunk will determine the number of textures used for this map chunk. Every texture layer other than the first will have an alpha map to specify blending amounts. The first layer is rendered with full opacity.
[edit]
MCRF sub-chunk

Unknown. List of integers.
[edit]
MCSH sub-chunk

Shadow map for static shadows on the terrain.

Thanks to Sylvain, the shadow maps work as follows: the shadows are stored per bit, not byte as 0 or 1 (off or on) so we have 8 bytes (which equates to 64 values) X 64 bytes (64 values in this case) which ends up as a square 64x64 shadowmap with either white or black. -Eric

Note that the shadow values come LSB first. - Z.
[edit]
MCAL sub-chunk

Alpha maps for additional texture layers. For every layer, a 32x64 array of alpha values. Can be used as a secondary texture with the modulation op to control the blending of the texture layers. For video cards with 2 texture units, this requires one pass per layer. (For 4 or more texture units, maybe this could be done faster using register combiners? Pixel shaders maybe?)

The size field of this chunk might be wrong for map chunks with zero texture layers. There are a couple of these in some of the development maps.

Similar to the shadow maps, the 32x64 bytes is really a 64x64 alpha map. There are 2 alpha values per byte, first 4 bits and second 4 bits. -Eric

Funny how this happened to work for the wrong sizes, too, because the upper 4 bits became the most significant in the alpha map, and the lower 4 appeared as noise. I sure didn't notice the difference It's fixed now of course. - Z.
[edit]
MCLQ sub-chunk

Water levels for this map chunk

The size field of this chunk is wrong! It's always 0. If there is really no data, an empty MCSE chunk will follow right after the size field.

Currently I'm only using the first float for a static water level per chunk, however, there is more data that needs to be figured out and for non-horizontal rivers or waterfalls it should be used properly.

Note by ObscuR :
The first float is the water altitude, second is the base magma heigth ,and the rest of data is the magma heigth map (8*8)


My second look at this chunk:

The size of the chunk is in the mapchunk header. The type of liquid is given in the mapchunk flags, also in the header.

The first two floats specify a liquid height level. (they are identical...?), after them comes a 9x9 height map for the water with the following format per vertex:
Offset Type Description
0x00 int16 ?
0x02 int16 ?
0x04 float height value

The unknown int values might be color or transparency info, or something entirely different... Most frequently they are 0.

Followed by 8x8 bytes of flags for every liquid "tile" between the 9x9 vertex grid. The value 0x0F means do not render. (the specific flag for this seems to be 8 bu I'm not sure - but it fixes some places where there was extra "water" sticking into the rest of the scenery)

Finally, 0x54 bytes of additional data, no idea what it's used for.
[edit]
MCSE sub-chunk

Sound emitters

struct CWSoundEmitter // 04-29-2005 By ObscuR (Maybe not accurate but should look like this )
{
/*000h*/ UINT32 soundPointID;
/*004h*/ UINT32 soundNameID;
/*008h*/ float pos[3];
/*00Ch*/
/*010h*/
/*014h*/ float minDistance;
/*018h*/ float maxDistance;
/*01Ch*/ float cutoffDistance;
/*020h*/ UINT16 startTime;
/*022h*/ UINT16 endTime;
/*024h*/ UINT16 groupSilenceMin;
/*026h*/ UINT16 groupSilenceMax;
/*028h*/ UINT16 playInstancesMin;
/*02Ah*/ UINT16 playInstancesMax;
/*02Ch*/ UINT16 loopCountMin;
/*02Eh*/ UINT16 loopCountMax;
/*030h*/ UINT16 interSoundGapMin;
/*032h*/ UINT16 interSoundGapMax;
/*034h*/
};

Retrieved from "http://wowmapview.sourceforge.net/wiki/index.php/ADT"

2.10
WMO:
Wmo files are World Map(Or Model) Objects. Every single building is a WMO. Ironforge is a WMO, for one. So is Onyxia's Lair, or the Caverns of Time, Blackrock Mountain, they'll all WMOs as well. This is not to say however, that WMOs are only things like those. No, stuff like Houses or Zeppelin towers are WMOs as well. Hell, even Zeppelins and Boats are too. WMOs follow a root/Sub structure. There is one giant mother WMO which contains everything in the current area, and then there are the sub WMOs. They are broken into parts to be loaded easier. EG:

 Ironforge.WMO
Ironforge_000.wmo
Ironforge_001.wmo etc

Here is the chunk structure of WMOs.

MOHD chunk

Header for the map object. 64 bytes.
Offset 	Type 	Description
0x00 	uint32 	nTextures - number of textures (BLP Files)
0x04 	uint32 	nGroups - number of WMO groups
0x08 	uint32 	nPortals - number of portals
0x0C 	uint32 	nLights - number of lights
0x10 	uint32 	nModels - number of M2 models imported
0x14 	uint32 	nDoodads - number of doodads (M2 instances)
0x18 	uint32 	nSets - number of doodad sets
0x1C 	uint32 	ambient color?
0x20 	uint32 	WMO ID (column 2 in WMOAreaTable.dbc)
0x24 	float[3] 	Bounding box corner 1
0x30 	float[3] 	Bounding box corner 2
0x3C 	uint32 	always 0?

struct SMOHeader // 03-29-2005 By ObscuR
{
/*000h*/  UINT32 nTextures;		
/*004h*/  UINT32 nGroups;		
/*008h*/  UINT32 nPortals;		
/*00Ch*/  UINT32 nLights;		
/*010h*/  UINT32 nDoodadNames;		
/*014h*/  UINT32 nDoodadDefs;		
/*018h*/  UINT32 nDoodadSets;		
/*01Ch*/  float ambColor[6];		
/*020h*/ 
/*024h*/  	
/*028h*/  		
/*02Ch*/ 	
/*030h*/  float pos[2];		
/*034h*/  		
/*038h*/  		
/*03Ch*/   UINT32 wmoID;		
/*040h*/ 
};

[edit]
MOTX chunk

List of textures (BLP Files) used in this map object. A block of zero-padded, zero-terminated strings, that are complete filenames with paths. There will be further material information for each texture in the next chunk. The gaps between the filenames are padded with extra zeroes, but the material chunk does have some positional information for these strings.

There are nTextures entries in this chunk.
[edit]
MOMT chunk

Materials used in this map object, 64 bytes per texture (BLP file), nTextures entries.

Only the known fields are documented here.
Offset 	Type 	Description
0x00 	uint32 	Flags (?)
0x08 	uint32 	Blending: 0 for opaque, 1 for transparent
0x0C 	uint32 	Start position for the texture filename in the MOTX data block
0x18 	uint32 	End position for the texture filename in the MOTX data block
0x1C 	4 * uint8 	Looks like an RGBA color?

struct SMOMaterial // 03-29-2005 By ObscuR
{
/*000h*/  UINT32 version;		
/*004h*/  UINT32 flags;		
/*008h*/  UINT32 blendMode;		
/*00Ch*/  UINT32 diffuseNameIndex;		
/*010h*/  float sidnColor[3];		
/*014h*/  		
/*018h*/ 		
/*01Ch*/  UINT32 frameSidnColor[3];		
/*020h*/  	
/*024h*/   	
/*028h*/  UINT32 envNameIndex;
/*02Ch*/  float diffColor[3] 		
/*030h*/   		
/*034h*/  		
/*038h*/  UINT32 groundType;		
/*03Ch*/  UINT32 hMaps;		
/*040h*/ 		
}

The field that looks like a color value is green for some of the wooden textures in human buildings, so it is obviously not a texture color. So its purpose is unknown.

The flags might used to tweak alpha testing values, I'm not sure about it, but some grates and flags in IF seem to require an alpha testing threshold of 0, at other places this is greater than 0.
Flag 	Meaning
0x01 	 ?
0x04 	Two-sided (disable backface culling)
0x10 	Bright at night (unshaded) (used on windows and lamps in Stormwind, for example) -ProFeT: i think that is Unshaded becase external face of windows are flagged like this.
0x20 	 ?
0x28 	Darkned ?, the intern face of windows are flagged 0x28
0x40 	 ?
0x80 	 ?
[edit]
MOGN chunk

List of group names for the groups in this map object. A contiguous block of zero-terminated strings. The names are purely informational, they aren't used elsewhere (to my knowledge)

There are nGroups entries in this chunk.
[edit]
MOGI chunk

Group information for WMO groups, 32 bytes per group, nGroups entries.
Offset 	Type 	Description
0x00 	uint32 	Flags
0x04 	3 * float 	Bounding box corner 1
0x10 	3 * float 	Bounding box corner 2
0x1C 	int32 	name offset in MOGN chunk (or -1 for no name?)

Groups don't have placement or orientation information, because the coordinates for the vertices in the additional .WMO files are already correctly transformed relative to (0,0,0) which is the entire WMO's base position in model space.

The name offsets seem to be incorrect (or something else entirely?). The correct name offsets are in the WMO group file headers. (along with more descriptive names for some groups)

The flags for the groups seem to specify whether it is indoors/outdoors, probably to choose what kind of lighting to use. Not fully understood. "Indoors" and "Outdoors" are flags used to tell the client whether certain spells can be cast and abilities used. (Example: Entangling Roots cannot be used indoors).
Flag 	Meaning
0x8 	Outdoor (use global lights?)
0x40 	 ?
0x80 	 ?
0x2000 	Indoor (use local lights?)
0x8000 	Unknown, but frequently used
0x10000 	Used in Stormwind?
0x40000 	Show skybox if the player is "inside" the group
[edit]
MOSB chunk

Skybox. If not empty, it contains a model (M2) filename to use as a skybox. Used in: Caverns of Time, Stratholme, Dire Maul, Death (Ghost World).

The regular "stars" skybox as seen outdoors at night is hardcoded into WoW.exe.

Skyboxes are also used in-game when you die (and have the swirling green clouds around you). There is also a skybox model used in Dire Maul, which is not shaped the same way as the Stratholme and Caverns of Time skyboxes.
[edit]
MOPV chunk

Portal vertices, 4 * 3 * float per portal, nPortals entries.

Portals are (always?) rectangles that specify where doors or entrances are in a WMO. They could be used for visibility, but I currently have no idea what relations they have to each other or how they work.

this part removed because there are proper holes in the terrain

Since when "playing" WoW, you're confined to the ground, checking for passing through these portals would be enough to toggle visibility for indoors or outdoors areas, however, when randomly flying around, this is not necessarily the case.


So.... What happens when you're flying around on a gryphon, and you fly into that arch-shaped portal into Ironforge? How is that portal calculated?

    * It's all cool as long as you're inside "legal" areas, I suppose.

It's fun, you can actually map out the topology of the WMO using this and the MOPR chunk. This could be used to speed up the rendering once/if I figure out how. Here are some example topologies: Deeprun Tram Orgrimmar Stormwind Ironforge
[edit]
MOPT chunk

Portal information. 20 bytes per portal, nPortals entries.
Offset 	Type 	Description
0x00 	uint16 	Base vertex index?
0x02 	uint16 	Number of vertices (?), always 4 (?)
0x04 	3 * float 	a normal vector maybe? haven't checked.
0x10 	float 	unknown

struct SMOPortal  // 04-29-2005 By ObscuR
{
/*000h*/  UINT16 startVertex;
/*002h*/  UINT16 count;
/*004h*/  float  plane[4];
/*014h*/  
};

[edit]
MOPR chunk

Portal - group relationship? 2*nPortals entries of 8 bytes. I think this might specify the two WMO groups that a portal connects.
Offset 	Type 	Description
0x0 	uint16 	Portal index
0x2 	uint16 	WMO group index
0x4 	int16 	1 or -1
0x6 	uint16 	always 0

struct SMOPortalRef // 04-29-2005 By ObscuR
{
/*000h*/  UINT16 portalIndex;
/*000h*/  UINT16 groupIndex;
/*004h*/  UINT16 side;
/*006h*/  UINT16 filler;
/*008h*/
};

[edit]
MOVV chunk

Visible block vertices

Just a list of vertices that corresponds to the visible block list.
[edit]
MOVB chunk

Visible block list

unsigned short firstVertex;
unsigned short count;

[edit]
MOLT chunk

Lighting information. 48 bytes per light, nLights entries
Offset 	Type 	Description
0x00 	4 * uint8 	Flags or something? Mostly (0,1,1,1)
0x04 	4 * uint8 	Color (B,G,R,A)
0x08 	3 * float 	Position (X,Z,-Y)
0x14 	7 * float 	Unknown (light properties?)

enum LightType 
{
	OMNI_LGT,
	SPOT_LGT,
	DIRECT_LGT,
	AMBIENT_LGT
};

struct SMOLight // 04-29-2005 By ObscuR
{
/*000h*/  UINT8 LightType; 	
/*001h*/  UINT8 type;
/*002h*/  UINT8 useAtten;
/*003h*/  UINT8 pad;
/*004h*/  UINT8 color[4];  
/*008h*/  float position[3];
/*014h*/  float intensity;
/*018h*/  float attenStart;
/*01Ch*/  float attenEnd;
/*020h*/  float unk1;
/*024h*/  float unk2;
/*028h*/  float unk3;
/*02Ch*/  float unk4;
/*030h*/  
};

I haven't quite figured out how WoW actually does lighting, as it seems much smoother than the regular vertex lighting in my screenshots. The light paramters might be range or attenuation information, or something else entirely. Some WMO groups reference a lot of lights at once.

The WoW client (at least on my system) uses only one light, which is always directional. Attenuation is always (0, 0.7, 0.03). So I suppose for models/doodads (both are M2 files anyway) it selects an appropriate light to turn on. Global light is handled similarly. Some WMO textures (BLP files) have specular maps in the alpha channel, the pixel shader renderpath uses these. Still don't know how to determine direction/color for either the outdoor light or WMO local lights... :)
[edit]
MODS chunk

This chunk defines doodad sets. Doodads in WoW are M2 model files. There are 32 bytes per doodad set, and nSets entries. Doodad sets specify several versions of "interior decoration" for a WMO. Like, a small house might have tables and a bed laid out neatly in one set called "Set_$DefaultGlobal", and have a horrible mess of abandoned broken things in another set called "Set_Abandoned01". The names are only informative.
Offset 	Type 	Description
0x00 	20 * char 	Set name
0x14 	uint32 	index of first doodad instance in this set
0x18 	uint32 	number of doodad instances in this set
0x1C 	uint32 	unused? (always 0)

The doodad set number for every WMO instance is specified in the ADT files.
[edit]
MODN chunk

List of filenames for M2 models that appear in this map tile. A block of zero-padded, zero-terminated strings. There are nModels file names in this list.
[edit]
MODD chunk

Information for doodad instances. While WMOs and models (M2s) in a map tile are rotated along the axes, doodads within a WMO are oriented using quaternions! Hooray for consistency!

40 bytes per doodad instance, nDoodads entries.
Offset 	Type 	Description
0x00 	uint32 	Offset to the start of the model's filename in the MODN chunk.
0x04 	3 * float 	Position (X,Z,-Y)
0x10 	float 	W component of the orientation quaternion
0x14 	3 * float 	X, Y, Z components of the orientaton quaternion
0x20 	float 	Scale factor
0x24 	4 * uint8 	(B,G,R,A) color. Unknown. It is often (0,0,0,255). (something to do with lighting maybe?)

struct SMODoodadDef // 03-29-2005 By ObscuR
{
/*000h*/  UINT32 nameIndex
/*004h*/  float pos[3];
/*010h*/  float rot[4];
/*020h*/  float scale;
/*024h*/  UINT8 color[4];
/*028h*/
};

I had to do some tinkering and mirroring to orient the doodads correctly using the quaternion, see model.cpp in the WoWmapview source code for the exact transform matrix. It's probably because I'm using another coordinate system, as a lot of other coordinates in WMOs and models also have to be read as (X,Z,-Y) to work in my system. But then again, the ADT files have the "correct" order of coordinates. Weird.
[edit]
MFOG chunk

Fog information. Made up of blocks of 48 bytes.

struct SMOFog // 03-29-2005 By ObscuR
{

/*000h*/  UINT32 flags;		
/*004h*/  float pos[3];		
/*008h*/ 	
/*00Ch*/  		
/*010h*/  float start[3];		
/*014h*/  		
/*018h*/ 		
/*01Ch*/  float end[3];			
/*020h*/  	
/*024h*/   	
/*028h*/  float fogs[2];
/*02Ch*/  	
/*030h*/		
}

For enUS 1.2.x (and above), seems to be different from the preceding struct:
Offset 	Type 	Description
0x00 	uint32 	Flags
0x04 	float[3] 	Position
0x10 	float 	Smaller radius
0x14 	float 	Larger radius
0x18 	float 	Fog end
0x1C 	float 	Fog start multiplier (0..1)
0x20 	uint32 	Fog color
0x24 	float 	Unknown (almost always 222.222)
0x28 	float 	Unknown (-1 or -0.5)
0x2C 	uint32 	Color 2

Fog end: This is the distance at which all visibility ceases, and you see no objects or terrain except for the fog color.

Fog start: This is where the fog starts. Obtained by multiplying the fog end value by the fog start multiplier.
[edit]
MCVP chunk

Convex Volume Planes. Contains blocks of floating-point numbers.
[edit]
WMO group file

WMO group files contain the actual polygon soup for a particular section of the entire WMO.

Every group file has one top-level MOGP chunk, that has a 68-byte header followed by more subchunks. So it can be effectively treated as a file with a header at 0x14 and chunks starting at 0x58.
[edit]
WMO group header
Offset 	Type 	Description
0x00 	uint32 	Group name (offset into MOGN chunk)
0x04 	uint32 	Descriptive group name (offset into MOGN chunk)
0x08 	uint32 	Flags
0x0C 	float[3] 	Bounding box corner 1 (same as in MOGI)
0x18 	float[3] 	Bounding box corner 2
0x24 	uint16 	Index into the MOPR chunk
0x26 	uint16 	Number of items used from the MOPR chunk
0x28 	uint16 	Number of batches A
0x2A 	uint16 	Number of batches B
0x2C 	uint32 	Number of batches C
0x30 	uint8[4] 	Up to four indices into the WMO fog list
0x34 	uint32 	Unknown (always 15)
0x38 	uint32 	WMO group ID (column 4 in WMOAreaTable.dbc)
0x3C 	uint32 	Always 0?
0x40 	uint32 	Always 0?

The fields referenced from the MOPR chunk indicate portals leading out of the WMO group in question.

For the "Number of batches" fields, A + B + C == the total number of batches in the WMO group (in the MOBA chunk). This might be some kind of LOD thing, or just separating the batches into different types/groups...?

I removed the struct definition because it seemed to be a copy of some header from the terrain data, not WMO stuff


Flags: always contain more information than flags in MOGN. I suppose MOGN only deals with topology/culling, while flags here also include rendering info.
Flag 	Meaning
0x1 	Always set
0x4 	Has vertex colors (MOCV chunk)
0x8 	Outdoor
0x200 	Has lights (MOLR chunk)
0x800 	Has doodads (MODR chunk)
0x1000 	Has water (MLIQ chunk)
0x2000 	Indoor
0x40000 	Show skybox
[edit]
MOPY chunk

Material info for triangles, two bytes per triangle. So size of this chunk in bytes is twice the number of triangles in the WMO group.
Offset 	Type 	Description
0x00 	uint8 	Flags?
0x01 	uint8 	Material ID

struct SMOPoly // 03-29-2005 By ObscuR ( Maybe not accurate :p )
{
	enum  
	{
		F_NOCAMCOLLIDE,
		F_DETAIL,
		F_COLLISION,
		F_HINT,
		F_RENDER,
		F_COLLIDE_HIT,
	};
/*000h*/  uint8 flags;
/*001h*/  uint8 lightmapTex; 
/*002h*/  uint8 mtlId;
};
// are you sure it's 3 bytes? wowmapview uses groups of 2 :)  - Z.
// look like the lightmapTex byte is no longer present, this struct come from Alpha :) - Obs

Frequently used flags are 0x20 and 0x40, but I have no idea what they do.

Material ID specifies an index into the material table in the root WMO file's MOMT chunk. Some of the triangles have 0xFF for the material ID, I skip these. (but there might very well be a use for them?)

Triangles stored here are more-or-less pre-sorted by texture, so it's ok to draw them sequentially.
[edit]
MOVI chunk

Vertex indices for triangles. Three 16-bit integers per triangle, that are indices into the vertex list. The numbers specify the 3 vertices for each triangle, their order makes it possible to do backface culling.
[edit]
MOVT chunk

Vertices chunk. 3 floats per vertex, the coordinates are in (X,Z,-Y) order. It's likely that WMOs and models (M2s) were created in a coordinate system with the Z axis pointing up and the Y axis into the screen, whereas in OpenGL, the coordinate system used in WoWmapiew the Z axis points toward the viewer and the Y axis points up. Hence the juggling around with coordinates.
[edit]
MONR chunk

Normals. 3 floats per vertex normal, in (X,Z,-Y) order.
[edit]
MOTV chunk

Texture coordinates, 2 floats per vertex in (X,Y) order. The values range from 0.0 to 1.0. Vertices, normals and texture coordinates are in corresponding order, of course.
[edit]
MOBA chunk

struct SMOBatch // 03-29-2005 By ObscuR
{
	enum
	{
		F_RENDERED
	};
	?? lightMap;
	?? texture;
	?? bx;
	?? by;
	?? bz;
	?? tx;
	?? ty;
	?? tz;
	?? startIndex;
	?? count;
	?? minIndex;
	?? maxIndex;
	?? flags;
};


Render batches. Records of 24 bytes.

For the enUS, enGB versions, it seems to be different from the preceding struct:
Offset 	Type 	Description
0x00 	uint32 	Some color?
0x04 	uint32 	Some color?
0x08 	uint32 	Some color?
0x0C 	uint32 	Start index
0x10 	uint16 	Number of indices
0x12 	uint16 	Start vertex
0x14 	uint16 	End vertex
0x16 	uint8 	0?
0x17 	uint8 	Texture
[edit]
MOLR chunk

Light references, one 16-bit integer per light reference. This is basically a list of lights used in this WMO group, the numbers are indices into the WMO root file's MOLT table.

For some WMO groups there is a large number of lights specified here, more than what a typical video card will handle at once. I wonder how they do lighting properly. Currently, I just turn on the first GL_MAX_LIGHTS and hope for the best. :(
[edit]
MODR chunk

Doodad references, one 16-bit integer per doodad. The numbers are indices into the doodad instance table ( MODD chunk) of the WMO root file. These have to be filtered to the doodad set being used in any given WMO instance.
[edit]
MOBN chunk

Array of t_BSP_NODE.

struct t_BSP_NODE
{	
	short planetype;          // unsure
	short children[2];        // index of bsp child node(right in this array)   
	unsigned short numfaces;  // num of triangle faces
	unsigned short firstface; // index of the first triangle index(in [[WMO#MOBR_chunk | MOBR]])
	short nUnk;	          // 0
	float fDist;    
};
// The numfaces and firstface define a polygon plane.
                                         2005-4-4 by linghuye

[edit]
MOBR chunk

Triangle indices (in MOVI which define triangles) to describe polygon planes defined by MOBN BSP nodes.
[edit]
MOCV chunk

Vertex colors, 4 bytes per vertex (BGRA), for WMO groups using indoor lighting. I don't know if this is supposed to work together with, or replace, the lights referenced in MOLR. But it sure is the only way for the ground around the goblin smelting pot to turn red in the Deadmines. (but some corridors are, in turn, too dark - how the hell does lighting work anyway, are there lightmaps hidden somewhere?)

- I'm pretty sure WoW does not use lightmaps in it's WMOs...

After further inspection, this is it, actual pre-lit vertex colors for WMOs - vertex lighting is turned off. This is used if flag 0x2000 in the MOGI chunk is on for this group. This pretty much fixes indoor lighting in Ironforge and Undercity. The "light" lights are used only for M2 models (doodads and characters). (The "too dark" corridors seemed like that because I was looking at it in a window - in full screen it looks pretty much the same as in the game) Now THAT's progress!!!
[edit]
MLIQ chunk

Completely overlooked this one...

Specifies liquids inside WMOs. This is where the water from Stormwind and BFD (and probably mode) was hidden. (slime in Undercity, pool water in the Darnassus temple, some lava in IF)

This file sounds like it might link to WLQ files (World LiQuids?).

    * I wish it did, but it doesn't. In fact, nothing links to them. There's no reference to them in the entire WoW data that I know of, apart from being there in misc.mpq. Makes me wonder if they're used at all.


Chunk header:
Offset 	Type 	Description
0x00 	uint32 	number of X vertices (xverts)
0x04 	uint32 	number of Y vertices (yverts)
0x08 	uint32 	number of X tiles (xtiles = xverts-1)
0x0C 	uint32 	number of Y tiles (ytiles = yverts-1)
0x10 	float[3] 	base coordinates?
0x1C 	uint16 	material ID

The liquid data contains the vertex height map (xverts * yverts * 8 bytes) and the tile flags (xtiles * ytiles bytes) as descripbed in ADT files (MCLQ chunk). The length and width of a liquid tile is the same as on the map, that is, 1/8th of the length of a map chunk. (which is in turn 1/16th the length of a map tile).

The material ID often refers to what seems to be a "special" material in the root WMO file (special because it often has a solid color/placeholder texture, or a texture from XTextures\*) - but sometimes the material referenced seems to be not special at all, so I'm not really sure how the liquid material is obtained - such as water/slime/lava..

The rest of the files are sound files. Music and Speech are within the Sound folder.

2.11

MP3:

MP3 files are a very common file. They're music, plain and simple. Every music file you've heared is an MP3.


2.12
WAV
Wav Files are all the speech files. Nefarions "persistant arent't you?", Ragnaros's "TOO SOON", your characters /silly, it's a .wav file.

2.13
.WLW - A water based terrain file, much like adts

2.14
.MDX - the old model format. Every model is referenced as an MDX in the DBCs rather than an m2. No specific reason that I can infer.

2.15 - outdated
Burning Crusade Friends and Family Alpha Files

Alpha files can be used in todays Current Warcraft. The way you can get an Alpha file is to download them from the thread titled "I've got a present for you all" or find a downloader for it. Blizzard no longer hosts it.

2.16
Burning Crusade Beta files - outdated

Burnign Crusade Beta files cannot be used in todays Wow. Stop asking.

The files that are most commonly asked for yet happen to be beta files are as follow:
Blood Elf Mount
Any updated version of existing models
To be updated further.
____
3.0
Programs

3.1
MyWarcraftStudio
This is the bread and butter of any model changers arsenel. This too allows you to go through and examine MPQs. You can extract and rename, pack and store items into brand new custom MPQs. You can view creatures items and objects, and even characters, textures too. You cannot however, view WMO files. you can select and extract, but you cannot actually see what it looks like. Same goes for the Map files(ADT, WDT, WDL). A previous version of MWCS(.7) can view ADT files. It's quite useful and I keep a version of it around just for viewing those. it's a great program, but it's not the only tool you will need.

the newest release is .10, which can view Burning Crusade model files. However, some people(including myself) cannot get .10 to work well. It's not really important, so I just revert back to .9. You will still crash on viewing models however. So if you want to extract them, go into your MWCS folder and delete m2craft.dll, this will enable you to click and extract M2s, but you will not be able to view them. That's what Model Viewer is for, though.
Get it at http://www.cnitblog.com/Files/linghu...o_0.9.5991.rar

3.2
WoWModelViewer
This is a highly detailed viewer dedicated to getting up close to the models and WMO's. You can customize characters and build tabards, mount your persona and export as a gif to be an avatar. I find this incredibly useful because of what's included with the program, and not just in the exe. You can also view WMO files, which is very handy for seeing what is what. there are a few CSV files included in the .rar of it. Of which are NPCs and items.



3.3
BLP Converter:
There is no one name for a program like this, as it exists i multiple forms, however the basic premise is that you extract a .blp and drag it over the command line window, and it makes a new one with the same properties in a .Tga or .Png file, making it readable and editable. You can reconvert to make custom textures. Search for one on google or curse-gaming.


3.4
DBC Converter:
Again, like the BLP converter, this doesn't exist under a single banner.The basics of a program like this takes a DBC file and converts it, usually, into a CSV file readable by Microsoft Excel. I'd personally advise against CSVD, as it corrupts the DBC file and causes WoW errors.

3.5
Mircrosoft Excel:
This is very useful for examining DBC files.
Get it here: http://www.microsoft.com/office/trial/default.mspx

3.6
Wow Map viewer

WoWMapViewer is a program that reads the terrain data of Warcraft and allows you to freely explore the reigons of Azeroth. It does not read current patch files however, and will often only read release 1.0 data. It also lets you view instances and travel under the world or over the world free of regular physics.

It's a very handy tool for finding out Coordinates of an area. The X Y and Z coords are in the bottom left hand corner of it - but they are inversed. It actually read Y X Z, so when getting coords make sure you switch them so it's X Y Z.

Wow Map view takes a very long time to load, but a fix came out for it. An unoffical version .6 was released sometime ago. The link is on Curse-Gaming, I don't have it right now though.

Those are the files and programs I personally use.




4.5
Making Custom Objects
This is where somethings get tricky. You can and are able to make new objects in 3d modeling programs such as 3d studio max. There is a conversion script availble here(
http://www.verzend.be/v/5161865/WoWM2Import.ms.html). This allows you to extract an M2 and view and edit it as you please in Studio Max. However, I know it exists, but I don't know where to obtain a Reverse Convert script. So at the moment, you cannot turn it back.

You can however, make custom Textures. You can extract and edit it as you please. If any of you saw my Felguard with a Bikini on, that was a custom texture.

-Open up texture or Patch.mpq. Doesn't matter.

-Find the texture you want to edit and extract it.

-Run it through your BLP converter

-Open it up in Paint if you want to do a quick job, or Photoshop if you want a more detailed customization

-Edit it as you please and save it.

-Run it through the BLP converter(Make sure to delete the original extracted copy)

-Pack it into an MPQ with the proper Treepath

-Viola, new texture.

4.7. My helmet size if off after doing a race change!
Yeah. This means that you didn't do a complete change. There are model files for helmets, which correspond to each races genders. Tauren males have TaM, females have TaF, etc. You'd need to replace the TaM files with whatever race you swap with to fix it.

5.0
ERRORS:

There are a great, many, many things that can and will go wrong at some point during your editing career. Some I know how to fix, some I don't.

5.1
Error #1: Green Models
This is caused by writing NEW data into the game. It only happens some times but when it happens, it sucks. If you've ever taken a model from the Test servers that's never been in the Live servers, sometimes this will happen. This is not a texture problem if you didn't edit the texture. There's nothing you can do except deal or delete it if you did nothing but bring it over untouched.

Basically this happens when model data is read, but no texture data can be found, even though it's looking. When you get a white matte for parts of the model, that means there just is no data at all, so it's not even looking for it.

If you made a texture from an original and, say, cut the canvas size of the texture down, this will happen. Delete the texture and redo it, but keep the canvas size the same, otherwise it won't work.

5.2
Error #2: Non Loading Models or Texture/Whatever
This happens many times when the treepath of your files are incorrect. Go back and double check it to make sure it's right.
If you know it's right and have double checked it, make sure the file is right. Remember, you can't turn a WMO(building) into a creature(model) or vice versa. Also make sure you're not using Burning Crusade Beta files.

5.3
Error #3: Error with Whatever.DBC, expected 42 Collumns and got 40.
Many things cause this. Whatever you did, make sure you did NOT extract your DBC file as a CSV from MWCS. YOU lose two columns when doing this. You must extract the file as a dbc and convert.
Sometimes the file just happens to corrupt itself. Do it over and be careful.

5.4
Error #4: I changed my Campfire/HunterTrap/whatever to X and I run right through it!

The model you are changing it to has no collision to speak of, which means that when you collide with it you will not be halted. OutLandsBoneDam, which looks like a good change to switch, has no collision, so it won't work. Most of the items located in "Goober" do have collision though.

An example of an item with collision is the dark portal edit. Using it allows yo to walk up a long flight of stairs to reach higher places.

You cannot tell if a model has collision just by looking at it in MWCS or model viewer, you have to test it.

6.0
Theory Crafting:

This is where I'll discuss the theory and ideas of Model Changing. This will be updated a lot.

Why does this work? Why does Warcraft read this? It happens because WoW is programmed to Read any Patch-X file First, before it reads any other file. And if there's a file in this Patch-x that overlaps another file, then it gets priority and doesn't load the one in a lower patch file. That's all that can be said at the moment.

Send me your ideas of stuff you want to see in this section. Ask questions, please. I'd love to answer them to the best I can.

7.0
Sources
MMowned:
http://www.mmowned.com/forums/model-...e-clothes.html
http://www.mmowned.com/forums/model-...creatures.html

www.wowdev.org

www.Hackwow.com

www.Curse-Gaming.com

http://shadowflare.samods.org/inside_mopaq/

www.SourceForge.com/WowMapview


A big thanks for SomethingCool for being so awesome and knowlegable
Thanks to Avainar47 for his DBC guides
Idusy 'cause I loves you.
And fault for his guides.
Relz too, cause he asked for it.

[A_Snake01]

I apologize, the Word Processor I wrote it in had some serious format issues. I double posted some info. It's all correct now.

[Fault]

Well, your welcome. Also note, u missed some files:
.WLW - A water based terrain file, much like adts
.MDX - A DBC related file, which is a combination of .blps and .m2s, for GameObjects and some other things
I havent had time to completely mow over this, but still, nice work

[A_Snake01]

I knew about these, but I decided to not include them as they are so rare.

[Avianar47]

lol, thanks for a mention in the guide, and i think this needs a sticky at the top of the list for all new model editers(spelled that wrong im pretty sure )

[A_Snake01]

Updated with Wlw/MDx, thanks Fault.

[Kru2]

Nice job man +rep

[Alkhara Majere]

Nice job indeed.
+rep. I think this needs a sticky.

[Scarmaker]

6.0
Theory Crafting:

This is where I'll discuss the theory and ideas of Model Changing. This will be updated a lot.

Why does this work? Why does Warcraft read this? It happens because WoW is programmed to Read any Patch-X file First, before it reads any other file. And if there's a file in this Patch-x that overlaps another file, then it gets priority and doesn't load the one in a lower patch file. That's all that can be said at the moment.

Send me your ideas of stuff you want to see in this section. Ask questions, please. I'd love to answer them to the best I can.

speech2.MPQ works also. I already know how to ME, but by the length of the guide and iothers responses, I believe slso believe thsin deserves Sticky. +rep for a long ass guide with good info!

[A_Snake01]

I do love it when people pass judgment based on length of post. But yeah, I mentioned speech2 through 9 somewhere else in it.

[Relz]

psh, you dont thank me?!?!?! im the coolest of the coolest contributers. anyways, +rep.

[A_Snake01]

I'll add you in, just because. :P Maybe.

[Relz]

lol "relz too, cause he asked for it"

it should be "relz because he is the greatest person on this site and should be everyones role model"

and remember, i bumped this TWO TIMES!!!!111oneoneeleven

[Alkhara Majere]

relz never followed up on my Lore forum
I hates you. Not really. I got rep...but you never posted after!!!111oneone

<3 relz anyways.

Offtopic much? Once again, a great guide. Matt, this needs a sticky! Wewt!

[Nugma]

Will read the whole thing later + rep.