antz

Introduction ADT Files contain the actual terrain information (height maps, texturing, WMOs, doodads, etc) required by the client to render the static parts of the terrain. They use a chunked file structure like WDT Files. Each ADT File contains 256 (16x16) map tiles (or map chunks). Each map tile is 33.3333 yards on each side, making the size of the map block in an ADT file 533.3333 yards on each side in total. As every WDT File can reference 64x64 ADT map blocks, the whole map is approximately 34133.33 yards on each side. 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 ADT files and blocks There is an .adt file for each existing block. If a block is unused it won't have an .adt file. The file will be: World/Maps/{InternalMapName}/<{InternalMapName}{BlockY}{BlockX}.adt. {InternalMapName} - The second field in Map.dbc {BlockY} - obtained with the following formula: floor((32 - (y / 533.33333))) {BlockX} - obtained with the following formula: floor((32 - (x / 533.33333))) Chunk Definitions Identifier Length Description Notes MVER 4 bytes Version This chunk specifies the format version. All ADT Files in 1.12.X have Version 18. MHDR 64 bytes Header The Header chunk contains offsets to various other chunks. All offsets are relative to the start of the MHDR data block 00h uint32 flags; //Known Values: 1 = contains MFBO 04h uint32 offsMCIN; 08h uint32 offsMTEX; 0Ch uint32 offsMMDX; 10h uint32 offsMMID; 14h uint32 offsMWMO; 18h uint32 offsMWID; 1Ch uint32 offsMDDF; 20h uint32 offsMODF; 24h uint32 offsMFBO; // this is only set if flags &1. 28h uint32 offsMH2O; 2Ch uint32 offsMTFX; 30h uint32[4] unused; Identifier Length Description Notes MCIN 4096 bytes Chunk Index This is a lookup table containing absolute offsets and sizes for every map tile in the file. There are 16x16 = 256 entries of 16 bytes each: 00h uint32 offsMCNK // absolute offset. 04h uint32 size // the size of the MCNK chunk, this is refering to. 08h uint32 flags // these two are always 0. only set in the client. 0Ch uint32 asyncId Identifier Length Description Notes MTEX Variable Texture File Names A list of zero-terminated file names for the textures used in this map. MMDX Variable Doodad File Names A list of zero-terminated file names for the doodads / models used in this map. MMID Variable Doodad File Name Lookup uint32 offsets into the MMDX chunk for every doodad. MWMO Variable WMO File Names A list of zero-terminated file names for the WMOs used in this map. MWID Variable WMO File Name Lookup uint32 offsets into the MWMO chunk for every doodad. MDDF nDoodad * 36 bytes Doodad Definition Placement Information for Doodads. 00h uint32 mmidEntry; // references an entry in the MMID chunk, specifying the model to use. 04h uint32 uniqueId; // this ID should be unique for all ADTs currently loaded. // Blizzard has these unique for the whole game. 08h float[3] position; 14h float[3] rotation; // degrees. 20h uint16 scale; // 1024 is the default size equaling 1.0f. 22h uint16 flags; // values from enum MDDFFlags. Identifier Length Description Notes MODF nWMO * 64 bytes WMO Definition Placement Information for World Map Objects 00h uint32 mwidEntry; // references an entry in the MWID chunk, specifying the model to use. 04h uint32 uniqueId; // unique ID for the whole map. 08h float[3] position; 14h float[3] rotation; // same as in MDDF. 20h float[3] lowerBounds; // these two are position plus the wmo bounding box. 2Ch float[3] upperBounds; // they are used for defining when if they are rendered as well as collision. 38h uint16 flags; 3Ah uint16 doodadSet; // which WMO doodad set is used. 3Ch uint16 nameSet; // which WMO name set is used. // Used for renaming goldshire inn to northshire inn while using the same model. 3Eh uint16 padding; Identifier Length Description Notes MCNK 128 byte header + variable data Map Chunk Data After the general information above 256 MCNK chunks follow. Each of these has a header followed by subchunks. Subchunks mostly behave like normal file chunks, except for some flakyness in their chunk size values. The header looks like this: 00h uint32 flags; // 1h=has MCSH, 2h=impassible, 4h=River, 8h=Ocean, 10h=Magma, // 20h=Slime, 40h=has MCCV 04h uint32 IndexX; 08h uint32 IndexY; 0Ch uint32 nLayers; // maximum 4 10h uint32 nDoodadRefs; 14h uint32 ofsMCVT; // offsets to various chunks. Relative to the beginning of the MCNK Chunk 18h uint32 ofsMCNR; 1Ch uint32 ofsMCLY; 20h uint32 ofsMCRF; 24h uint32 ofsMCAL; 28h uint32 sizeAlpha; 2Ch uint32 ofsMCSH; // only with flags & 0x1 30h uint32 sizeShadow; 34h uint32 areaid; 38h uint32 nMapObjRefs; 3Ch uint32 holes; 40h uint2[8][8] ReallyLowQualityTextureingMap; // the content is the layer being on top, I guess. 50h uint32 predTex; // ??? 54h uint32 noEffectDoodad; // ??? 58h uint32 ofsMCSE; 5Ch uint32 nSndEmitters; // will be set to 0 in the client if ofsSndEmitters doesn't point to MCSE! 60h uint32 ofsMCLQ; 64h uint32 sizeLiquid; // 8 when not used; only read if >8. 68h float[3] position; 74h uint32 ofsMCCV; // only with flags & 0x20, had uint32 textureId; 78h uint32 ofsMCLV; // introduced in Cataclysm 7Ch uint32 unused; // currently unused 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 Identifier Length Description Notes MCVT 580 bytes Subchunk These are the actual height values for the 9x9+8x8 vertices. 145 floats in the following order/arrangement:. The values in here are only relative to the position given in the corresponding MCNK chunk. 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 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 WoW uses Squares out of 4 of the Outer(called NoLoD)-Vertices with one of the Inner(called LoD)-Vertices in the Center: 1 2 10 18 19 Identifier Length Description Notes MCNR 435 bytes + 13 bytes of unknown data Subchunk - Normals 9x9 + 8x8 surface normals, laid out as in the MCVT chunk. int8[3] normal; // normalized. X, Y, Z. 127 == 1.0, -127 == -1.0. This chunk has 13 bytes of unknown data at the end. The chunk size only covers the normals, though. Identifier Length Description Notes MCLY 1-4 layers * 16 bytes Subchunk - Texture Layers See Below. These are texture layer definitions for this map chunk. 16 bytes per layer, up to 4 layers. Every texture layer other than the first will have an alpha map to specify blending amounts. The first layer is rendered with full opacity. To know which alphamap is used, there is an offset into the MCAL chunk. That one is relative to MCAL. You can animate these by setting the flags. Only simple linear animations are possible. You can specify the direction in 45° steps and the speed. The textureId is just the array index of the filename array in the MTEX chunk. The effectId links to GroundEffectTexture.dbc. It defines the little detaildoodads as well as the footstep sounds and if footprints are visible. 00h uint32 textureId; 04h uint32 flags; 08h uint32 offsetInMCAL; 0Ch int32 effectId; // (actually int16 and padding) Flags Flag Description ------------------------------------------------------------------------------ 0x001 Animation: Rotate 45° clockwise. 0x002 Animation: Rotate 90° clockwise. 0x004 Animation: Rotate 180° clockwise. 0x008 Animation: Make this faster. 0x010 Animation: Faster!! 0x020 Animation: Even Faster!! 0x040 Animation: Animate this texture as told in the other bits. 0x080 This will make the texture way brighter. Used for lava to make it "glow". 0x100 Use alpha map - set for every layer after the first 0x200 Alpha map is compressed Identifier Length Description Notes MCRF Variable Subchunk See #1 Below. MCSH 512 bytes Subchunk See #2 Below. MCAL 0-3 layers * 2048 bytes Subchunk - Alpha maps See #3 Below. MCLQ ???? Unknown Subchunk - Liquids See #4 Below. #1. A uint32 list of with MCNK.nDoodadRefs + MCNK.nMapObjRefs indices into the file's MDDF and MODF chunks, saying which MCNK subchunk those particular doodads and objects are drawn within. This MCRF list contains duplicates for map doodads that overlap areas. As both, WMOs and M2s are referenced here, they get doodad indices first, then WMOs. If you have a doodad and a WMO in the ADT as well as the MCNK, you will have a {0,0} in MCRF with nDoodadRefs and MCNK.nMapObjRefs being 1. #2. Shadow map for static shadows on the terrain. Can be left out with the chunk&1 flag not set. The shadow maps work as follows: the shadows are stored per bit 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. Note that the shadow values come LSB first. #3. These are alpha maps for additional texture layers beside the base layer. Each layer contains a 64x64 alpha map. There are 2 alpha values per byte, first 4 bits and second 4 bits. Results in 2048 bytes per layer. #4. The size of the chunk is in the mapchunk header. The type of liquid is given in the mapchunk flags, also in the header. This information is old and incomplete as well as maybe wrong. The first two floats specify the minimum and maximum liquid height level. After them comes a 9x9 height map for the water with the following format per vertex: 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 but 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. Identifier Length Description Notes MCSE ???? Unknown, See Below. Subchunk - Sound Emitters This is not well understood. Struct from WoWDev Wiki below. 00h uint32 soundPointID; 04h uint32 soundNameID; 08h float[3] pos; 0Ch 10h 14h float minDistance; 18h float maxDistance; 1Ch float cutoffDistance; 20h uint16 startTime; 22h uint16 endTime; 24h uint16 groupSilenceMin; 26h uint16 groupSilenceMax; 28h uint16 playInstancesMin; 2Ah uint16 playInstancesMax; 2Ch uint16 loopCountMin; 2Eh uint16 loopCountMax; 30h uint16 interSoundGapMin; 32h uint16 interSoundGapMax;

Introduction 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. Chunks Identifier Length Description Notes MVER 4 bytes Map Version This chunk specifies the format version. All WDT Files in 1.12.X have Version 18. MPHD 32 bytes Map Header This chunk is the Map header. It contains 8 int32 Values. 00h uint32 flags; 04h uint32 something; 08h uint32 unused[6] Flags values are not well understood. From Wowdev: Flag Description ------------------------------------------------------------------------------------------------------ 0x01 Use global map object definition. 0x02 CMapRenderChunk::SetVertexFormat(2); (else: 1) -- Use vertex shading (ADT.MCNK.MCCV) 0x04 Decides whether to use _env terrain shaders or not: funky and if MCAL has 4096 instead of 2048(?) 0x08 Disables something. No idea what. Another rendering thing. Someone may check all them in wild life.. 0x10 if (flags & 0x02 && CMap::enableTerrainShaderVertex) CMapRenderChunk::SetVertexFormat(16); // cataclysm? The second integer is not ignored but stores something too. This is even less well understood. Identifier Length Description Notes MAIN 32768 bytes Main Chunk This is the map table data. It contains 64x64 8 byte entries. 00h uint32 m_flags; 04h void* m_area; // only set during runtime. Flags: Flag Description ----------------------------------------------------------------- 0x01 There is an ADT File for this position 0x02 Set by the client during runtime if the chunk was loaded We just need to know the 0x01 flag. The corresponding ADT File is found in World\Maps\\_XX_YY.adt Identifier Length Description Notes MWMO varies Map World Map Object If there is no terrain in a map (e.g. Deeprun Tram), all entries in the MAIN Chunk are 0. In this, and ONLY in this case, the MWMO Chunk contains exactly one WMO File Name (Zero Terminated). MODF 64 bytes MODF Chunk If the MWMO Chunk is not empty, MODF contains placement information for the WMO. Offset Type Description -------------------------------------------------------------- 00h uint32 ID (index in the MWID list) 04h uint32 unique identifier for this instance 08h float[3] Position (X,Y,Z) 14h float[3] Orientation (A,B,C) 20h float[6] Bounding Box 38h uint16 Flags 3Ah uint16 Doodad set index 3Ch uint16 Name set? 3Eh uint16 Padding

Archive and compression MPQ Files: archive format. Chunked Format Data Files DBC Files: DBC/DB2 files content layouts. DNC.db: Day-Night cycle specification. LIT Files: lighting information. SBT Files: cinematic subtitles. TRS Files: minimap hash translation. WDB Files: client data cache. Graphics BLP Files: texture format, supporting texture compression, and multiple resolutions. BLS Files: instructions for pixel and vertex shaders. M2 Files: Blizzard Entertainment's own model format, also known as '''.mdx'''. WFX Files: assigns shaders to surfaces. WMO Files: World Map Object file, containing either a group definition or a single world map object. Map Data ADT Files: terrain and object information for map tiles. WDL Files: low-resolution height maps. WDT Files: map and object placement information. ZMP Files: map tile reference.

Introduction ZMP Files - presumably for Zone Map - link map data to location info from AreaTable.dbc. There are 3 of those files in 1.12.2: Interface\WorldMap\Azeroth.zmp Interface\WorldMap\Expansion01.zmp (in patch.MPQ, no data present) Interface\WorldMap\Kalimdor.zmp Structure The files are headerless. They contain 128 x 128 uint32 values (double resolution compared to WDT) which are area IDs from AreaTable.dbc Speculation We think it is possible that this file is used by the client to display the name of the current area while moving in the World. WowDev Wiki says: They are used on parsing WorldMapArea.dbc. The values get copied and then get overwritten with the WorldMapArea-id the areaid they referenced is in. It will hold a zero or the WMA-id depending on if the area and the map that's currently parsed match. This also takes the virtual map id into account.

Introduction A client database or DBC file is a simple binary format for a database table. Each record in the file is one row of the table. Field values may consist of a limited range of data types, and do not include field separation characters - except for character-based string fields. DBC files nearly always use file extension DBC (or dbc) and DB2 (or db2) and have been named DataBaseClient files ever since their discovery in the DataBaseClient folder in the client files. The true extension meaning has not yet been revealed by Blizzard. Technical details Each file consists of a header, the table data, and if necessary a string block. Header 00h: char[4] Signature always 'WDBC' 04h: int32 Records number of records in the file 08h: int32 Fields number of fields per record 0Ch: int32 Record Size Fields*FieldSize (FieldSize is usually 4, but not always) 10h: int32 String Block Size Size of the string block Table Data Each record has a constant length. Usually all the values are 32bit integers. String data is stored in a block after the records. String data in records contain an offset to the string, relative to the start of the string block. When encountering string data, it usually consists of an English name field, followed by 7 additional fields for different localizations. String Block A continuous block of zero-terminated strings. Offsets into the String Block are relative to the start of the block. A more detailed breakdown follows: DBC file layout The DBC file layout is fairly simple, below is a hex display of the file AuctionHouse.dbc Col Col Col Col Col Col Col Col Col Col Col Col Col Col Col Col Col Col Col Col Col Col Col Col File Offset 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 ASCII DISPLAY 00000000 57 44 42 43 07 00 00 00 0d 00 00 00 34 00 00 00 aa 00 00 00 01 00 00 00 WDBC........4...a....... 00000018 01 00 00 00 05 00 00 00 05 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ........................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7e 00 3f 00 ....................~.?. 00000048 02 00 00 00 03 00 00 00 05 00 00 00 05 00 00 00 19 00 00 00 00 00 00 00 ........................ 00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........................ 00000078 7e 00 3f 00 03 00 00 00 04 00 00 00 05 00 00 00 05 00 00 00 30 00 00 00 ~.?.................O... 00000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........................ 000000a8 00 00 00 00 7e 00 3f 00 04 00 00 00 05 00 00 00 05 00 00 00 05 00 00 00 ....~.?................. 000000c0 48 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 H....................... 000000d8 00 00 00 00 00 00 00 00 7e 00 3f 00 05 00 00 00 06 00 00 00 05 00 00 00 ........~.?............. 000000f0 05 00 00 00 60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ....'................... 00000108 00 00 00 00 00 00 00 00 00 00 00 00 7e 00 3f 00 06 00 00 00 02 00 00 00 ............~.?......... 00000120 05 00 00 00 05 00 00 00 7d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........}............... 00000138 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7e 00 3f 00 07 00 00 00 ................~.?..... 00000150 71 01 00 00 19 00 00 00 0f 00 00 00 91 00 00 00 00 00 00 00 00 00 00 00 q...........'........... 00000168 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7e 00 3f 00 ......./............~/?. 00000180 00 53 74 6f 72 6d 77 69 6e 64 20 41 75 63 74 69 6f 6e 20 48 6f 75 73 65 .Stormwind Auction House 00000198 00 41 6c 6c 69 61 6e 63 65 20 41 75 63 74 69 6f 6e 20 48 6f 75 73 65 00 .Alliance Auction House. 000001b0 44 61 72 6e 61 73 73 75 73 20 41 75 63 74 69 6f 6e 20 48 6f 75 73 65 00 Darnassus Auction House. 000001c8 55 6e 64 65 72 63 69 74 79 20 41 75 63 74 69 6f 6e 20 48 6f 75 73 65 00 Undercity Auction House. 000001e0 54 68 75 6e 64 65 72 20 42 6c 75 66 66 20 20 41 75 63 74 69 6f 6e 20 48 Thunder Bluff Auction H 000001f8 6f 75 73 65 00 48 6f 72 64 65 20 41 75 63 74 69 6f 6e 20 48 6f 75 73 65 ouse.Horde Auction House 00000210 00 42 6c 61 63 6b 77 61 74 65 72 20 41 75 63 74 69 6f 6e 20 48 6f 75 73 .Blackwater Auction Hous 00000228 65 00 e. Header Block The first section is the header block which is 20 bytes long Col Col Col Col Col Col Col Col Col Col Col Col Col Col Col Col Col Col Col Col Col Col Col Col File Offset 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 ASCII DISPLAY 00000000 57 44 42 43 07 00 00 00 0d 00 00 00 34 00 00 00 aa 00 00 00 WDBC........4...a... 57 44 42 43 is the filetype is text. Normally "WDBC" or "WDB2" 07 00 00 00 is the number of rows, the byte order is reversed, so this would be 00 00 00 07 = 7 Rows of data. 0d 00 00 00 is the number of fields, again byte order reversed, so 00 00 00 0d = 13 rows of data 34 00 00 00 is the length of the row 00 00 00 34 = 52 bytes long aa 00 00 00 is the length of the string block The start of the string block can be calculated one of two ways: The length of the file - the size of the string block The length of the header + (number of rows * length of the row) Using the latter approach, we can calculate the start of the string block as follows: The length of the header + (number of rows * length of the row) i.e. 20 + (7 * 52) = 384 (or 180 in hex). This gives us the start offset for the string block 00000180h Data Block The Second section is the data block, from the values obtained above from the header we know there are 7 records and 13 fields. Each field is typically 4 bytes long. Here is the first record: Col Col Col Col Col Col Col Col Col Col Col Col Col Col Col Col Col Col Col Col Col Col Col Col File Offset 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 ASCII DISPLAY 00000000 01 00 00 00 .... 00000018 01 00 00 00 05 00 00 00 05 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ........................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7e 00 3f 00 ....................~.?. All the byte groups are in reverse order as before 01 00 00 00 is 00 00 00 01 = 1, 01 00 00 00 is 00 00 00 01 = 1, 05 00 00 00 is 00 00 00 05 = 5, 05 00 00 00 is 00 00 00 05 = 5, 01 00 00 00 is 00 00 00 01 = 1, is the string offset for the text 00 00 00 00 is 00 00 00 00 = 0, same for localised languages 00 00 00 00 is 00 00 00 00 = 0, same for localised languages 00 00 00 00 is 00 00 00 00 = 0, same for localised languages 00 00 00 00 is 00 00 00 00 = 0, same for localised languages 00 00 00 00 is 00 00 00 00 = 0, same for localised languages 00 00 00 00 is 00 00 00 00 = 0, same for localised languages 00 00 00 00 is 00 00 00 00 = 0, same for localised languages 7e 00 3f 00 is 00 3f 00 7e = 4128894 If you check out the Wiki page for AuctionHouse.dbc you will see that we have the fields: AuctionHouse ID = 1 Faction ID =1 Auction Fee = 5 Deposit Tax = 5 Name = 1 Name1 = 0 Name2 = 0 Name3 = 0 Name4 = 0 Name5 = 0 Name6 = 0 Name7 = 0 Text Checksum = 4128894 String Block The string block is a chunk of text strings, separated by nulls. Now previously we had calculated the start offset for the string block as 00000180h Col Col Col Col Col Col Col Col Col Col Col Col Col Col Col Col Col Col Col Col Col Col Col Col File Offset 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 ASCII DISPLAY 00000180 00 53 74 6f 72 6d 77 69 6e 64 20 41 75 63 74 69 6f 6e 20 48 6f 75 73 65 Stormwind Auction House 00000198 00 41 6c 6c 69 61 6e 63 65 20 41 75 63 74 69 6f 6e 20 48 6f 75 73 65 00 .Alliance Auction House. 000001b0 44 61 72 6e 61 73 73 75 73 20 41 75 63 74 69 6f 6e 20 48 6f 75 73 65 00 Darnassus Auction House. 000001c8 55 6e 64 65 72 63 69 74 79 20 41 75 63 74 69 6f 6e 20 48 6f 75 73 65 00 Undercity Auction House. 000001e0 54 68 75 6e 64 65 72 20 42 6c 75 66 66 20 20 41 75 63 74 69 6f 6e 20 48 Thunder Bluff Auction H 000001f8 6f 75 73 65 00 48 6f 72 64 65 20 41 75 63 74 69 6f 6e 20 48 6f 75 73 65 ouse.Horde Auction House 00000210 00 42 6c 61 63 6b 77 61 74 65 72 20 41 75 63 74 69 6f 6e 20 48 6f 75 73 .Blackwater Auction Hous 00000228 65 00 e. As we saw above, the Value for Name was 1, add this is the base gives 181h, then read all characters until a null. This is the start character of "Stormwind Auction House" (there is a null after "House"). Looking at all the records, the string offsets are: 01h = 1 - "Stormwind Auction House" 19h = 25 - "Alliance Auction House" 30h = 48 - "Darnassus Auction House" 48h = 72 - "Undercity Auction House" 60h = 96 - "Thunder Bluff Auction House" 7dh = 125 - "Horde Auction House" 91h = 145 - "Blackwater Auction House"

Important Things to remember There are Five MaNGOS cores, each designed to support a specific version of WOW. Core Supporting Client Version GitHub URL MangosZero Vanilla 1.12.1(5875), 1.12.2(6005) & 1.12.3(6141). http://github.com/mangosZero MangosOne The Burning Crusade 2.4.3(8606). http://github.com/mangosOne MangosTwo Wrath of the Lich King 3.3.5a(12340). http://github.com/mangosTwo MangosThree Cataclysm 4.3.4 (Build 15595). http://github.com/mangosthree MangosFour Mists of Pandaria 5.4.8 (Build 18414). http://github.com/mangosFour PLEASE NOTE: The default branch of all the repos is always the latest released version, and only hotfixes are applied to it. The development branch contains the ongoing development work. If you omit the --recursive parameter, NOTHING WILL BUILD CORRECTLY - You have been warned !!! In the examples below, we are using MangosZero ! Open your favourite git command line util ie. 'git bash' or 'git shell' Then type the commands below: Cloning the default branch of the repos Cloning the Server Source into the folder serverZero Type: git clone https://github.com/mangoszero/server.git serverZero --recursive --depth=10 Cloning the Database into the folder dbZero Type: git clone https://github.com/mangoszero/database.git dbZero --recursive --depth=10 These will create a server and database folder, which then contain the contents of each repo. As the Mangos Repos now use git submodules, cloning using the "recursive" flag will pull in all required submodules automatically. i.e. Eluna, ScriptDev3 etc. If you forget to include --recursive, you can still get the missing files Type: git submodule init git submodule update NOTE: Removing the --depth=10 flag will cause the entire history to be downloaded, normally only needed be developers or when bug hunting.

Sometimes you may want to switch between branches, i.e. between Release and Development branches To switch to a Development branch, for example develop21 Type: git checkout develop21 git pull --recurse-submodules git submodule init git submodule update To switch to a Release branch. Type: git checkout release20 git pull --recurse-submodules git submodule init git submodule update The folders will then contain the updated contents of the repo for this branch.

Goals for 2016 For 2016 the following are what we would like to achieve: Release Version 21 for Zero, One and Two containing all the recent updates and fixes we have. Release Version 21 for Three and Four - which will involve a massive amount of work to get these cores up to date. Redo the server commands to make them a bit more standard and obvious. Break out AHBot into its own daemon process Develop a mangos update daemon, which allows the ability to apply DB content and minor updates automatically Create Editors for the other xxxdocs systems (we currently only have a dbDoc Editor) Normalise the character DB and remove data blob fields Continue to standardise the code across the cores where its appropriate to do so. Document where it differs and why. Move some hardcoded values from the core into the DB, possibly some enums as well. Implement Stormlib library for Zero, One and Two and remove mlib Apply the Unified Extractor to Three and Four (requires stormlib) Look at removing DBC usage from the Core and change the extraction process to include importing into a DB for use by the core. Including Multiple locale support. This would facilitate the removal of stormlib / mlib from the core and only be needed by the extraction tools. Finish implementing the database localisation and allow localised db content to be loaded and edited. Including a localisation editor to allow localised translations to be created/edited by users. As well as some of the more obvious ones: Clear down reported bugs on the Project Tracker. Improve the World Database with updates and corrections. Improve the Wiki Documentation. Include some example Eluna scripts to assist those starting out learning to script with Eluna. Include some custom Eluna scripts to help showcase it's abilities. Finally, we would like to get into a twice yearly Release cycle of more major releases. MangosVB (Formerly Spurious) RoadMap for 2016 Add RealmDB from c++ Mangos and modifying MangosVB to be compatible with it. Work out how to get MangosVB to use the standard Mangos map format. Finishing warden functionality (so it can use/read signatures from DB) Merge all of the changes from Zero to One and Two Investigate into voice functionality for One / Two Doing spells.. implementing them like stealth and getting a proper DB script system in place Getting it compiled and running under unix

Summary of 2015 As such we didn't have a formal roadmap in 2015 as it was a year of proper transition and rebuilding for MaNGOS. Much of the project foundations have been rebuilt and redesigned to allow us to be able to move forward easier in the future. I would like to make a special acknowledgement of the efforts of the following people who contributed massively over the last year: FoeReaper - Who worked tirelessly with me to get things cleaned up, especially on the cmake and build system side of things. Olion - Who helped reshape SD2 into SD2+, which became the foundation of SD3 Chuck5ta - Who's constant eagerness to fix any DB data issues I uncovered, has been a great help There have also been hundreds of other people who have also contributed in various amounts throughout the year and I would like to take the time to thank everyone who contributed !! - MaNGOS is our project, it belongs to all of us Some of the key changes made to the codebase to make it a little bit more coherent were:- Replacing the ageing SD2 libraries in each core with a single cross-core SD3 submodule Replacing the separate extraction tools on Zero, One and Two with a Unified Extractor submodule. Moving the RealmD code to a submodule My push to get MaNGOS properly documented has started to pay off. Several sub-projects were created to help achieve this: dbDocs system for the Wiki has helped us create one of the most complete database documentation of any project. dbcDocs for documenting the DBC files is still a work in progress but has come on a long way this year packetDocs for documentation the packets and their structure is well into development codeDocs this is still in a prototype phase atm, but the idea behind it is to allow full API documentation of the codebase These four projects use a semi-automatic system for creating the information. In principle the key information is pulled from the source material whether that be the database, dbc files or the mangos source code - This information is then mapped onto a documentation layer which allows anyone to add information and notes freely. In the contrib folder of the mangos 'repos' is a tool called dbDocs Editor, this allows for documentation to be created and/or edited relating to the database.

The db docs system is made up of three core tables dbdocstable dbdocsfields dbdocssubtables The World database also has an additional table:- dbdocsprogressquests I will attempt to explain how the dbdocs system links everything together below dbdocstable - DB Docs Table This table contains two fields: Field 'tableName' This field contains the table name to link the additional notes to. Field 'tableNotes' This field is the description of the table, since this is a text field the text can be quite lengthy if required and contain html. dbdocsfields - DB Docs Fields This table contains three fields: Field 'tableName' This field contains the table name to link the additional notes to. Field 'fieldName' This field contains the field name in the table to link the additional notes to. Field 'fieldComment' This field contains a short description of the field. Field 'fieldNotes' This field is the description of the field, since this is a text field the text can be quite lengthy if required and can contain html. You can also add subtable directives at any point through the text. The directive takes the format: ¬subtable:x¬ Where x is the subtable Id. What follows is a list of allowed races: ¬subtable:1¬ * Remember that some races are not available on earlier expansions This literally means add subtable Id 1 into the text at this point dbdocssubtables - DB Docs SubTables This table contains two fields: Field 'subtableId' This field contains the table name to link the additional notes to. Field 'subtablecontent' This field contains the markup for the subtable, since this is a text field the text can be quite lengthy if required and contain html. This directly replaces the subtable directives used in field notes. Field 'subtableNotes' This field is the short description of the subtable is. The last of the tables is: dbdocsprogressquests - DB Docs ProgressQuests This table contains three fields: Field 'QuestId' This field contains the quest Id. Field 'Progress' This field contains the percentage complete this quest is. By default the dbdocs system assumes that this is 0% if unmatched. Field 'QuestNotes' This field is the a note regarding the state of the quest, since this is a text field the text can be quite lengthy if required and contain html. All the current wiki Database and DBC reference information page are now built using the above system. The system for documenting dbc files (dbcDocs) is a variant of this one and is described elsewhere.

From the Mangos command prompt:- We need to create an account to use with the server. account create testuser mypassword This will set up a user called testuser with a password of mypassword In order to use the expansions for Classic - No need to do anything for TBC - account set addon testuser 1 for WotLK - account set addon testuser 2 for Cata - account set addon testuser 3 for Mop - account set addon testuser 4 Setting up the client to access the server 1) Navigate to the location of the Warcraft Client installed on your local PC 2) Navigate to the “Data\enGB” folder (or other locale if not uk) - On Classic this file is in the root folder, so you don't need to do this. - On Mop the realmlist.wtf is merged with config.wtf in the WTF folder. 3) Open the file “realmlist.wtf” with WordPad It will contain the following lines (actual detail may vary slightly) :- set realmlist eu.logon.worldofwarcraft.com set patchlist enGB.patch.battle.net:1119/patch Change these values to the IP address of the server. That’s it. You are ready to roll....

Generic Resources about Git All about Git - official page Some good video talks about http: Linus Torvalds: History&Concepts Scott Chacon: Git basics, live examples Randal Schwartz: Git basics, descriptional Jesica Kerr: Git basics, descriptional A good book of the subject: Pro-Git Install Git On Windows Install MySysGit (Be sure to check the install with "Git bash here" support) On Linux Use your package manager to install git. Basic Functions Cloning a repo to your hard drive The most basic form of this command is: $ git clone --recursive http://github.com/{username}/{reponame} A slightly better form is to specify the folder name of the local repo: $ git clone --recursive http://github.com/{username}/{reponame} {localreponame} In the case of mangosZero this would be a valid command to clone it correctly to a folder called 0server $ git clone --recursive http://github.com/mangoszero/server serverZero Sometimes you may want to clone a specific branch i.e. develop21 $ git clone --recursive http://github.com/{username}/{reponame} -b develop21 {localreponame} Updating an existing repo with the latest source From the folder containing the source, type: $ git pull --recurse-submodules This will pull in all updated files, you can then proceed to build using Visual Studio or cmake/make on Linux.

Introduction As you may have noticed, from time to time there is a news article on the left side of the login screen for the WoW Client. Sometimes it can be annoying having a Blizzard notice that the servers are going down, when in reality, your server(s) is not going to be going down for maintenance in the foreseeable future. Here are instructions on how to alleviate this problem for you and your players, should you have anyone else on your server: Disabling Breaking News First, we need to go into our “hosts” file, which, depending on your operating system, will be in a different location. For Windows, the hosts file is in C:\Windows\System32\drivers\etc\hosts. In order to edit this file, though, you are going to have to go into your start menu, type notepad, right-click on notepad and run as administrator. Then just hit file, open, and navigate to the hosts file. For *NIX, the location of the “hosts” file is /etc/hosts. Second, once you are editing the “hosts” file, you will need to go to the end of the file and enter the ip address of your server, in my case it would be 192.168.0.4. Then tab over to the space under “localhost” and enter the actual servername of the warcraft breaking news server, again, in my case it was “launcher.worldofwarcraft.com”. Depending on your region the address will be different. There will be a list of breaking news server later. Finally, once you are done modifying your “hosts” file, you can restart the client and you will never see Blizzard’s breaking news again. “Pushing” Breaking News for your Server In order to start “pushing” your own news, follow the instructions from Disabling Breaking News and then, once you have finished modifying your “hosts” file, come back to this section. I’m assuming that you are using the WAMP server which covers both MySQL and Apache and are on Windows. If you are in *NIX, then you should not have to worry about MySQL and Apache as they should both already be installed, normally. With our server configuration out of the way, we are ready to begin preparing to push our own news to our clients. In the root web directory for your domain name or ip address, create a file called “Alert”. No quotation marks, no file extension, just Alert. And yes, capitalize the A. Alert is an over-simplified html file. As an example Alert file we have: SERVERALERT:<html><body><p>Your Message.</p></body></html> If you feel the need to disable your news system again at a future date, simply rename Alert to something like Alert2. When you want to re-enable your news system for a new tidbit of news, all you have to do is move Alert2 back to Alert and edit it. Blizzard’s Breaking News Servers US/SEA - http://launcher.worldofwarcraft.com/alert LA - http://launcher.worldofwarcraft.com/es/alert EN - http://status.wow-europe.com/en/alert ES - http://status.wow-europe.com/es/alert FR - http://status.wow-europe.com/fr/alert DE - http://status.wow-europe.com/de/alert RU - http://status.wow-europe.com/ru/alert KR - ??? http://launcher.worldofwarcraft.co.kr/alert CN - ??? http://launcher.battlenet.com.cn/alert TW - ??? http://launcher.wowtaiwan.com.tw/alert

The MaNGOS core is hosted on Git. For those contributors who are just starting out, here’s a quick list of tips we have put together especially for you. This is no substitute for a proper tutorial, but rather a MaNGOS biased supplement to one. The first thing you do should be configure a real name and email. By default, Git chooses a default name based on the GECOS data (which is probably right) and a default email based on your login and hostname (which is almost certainly wrong). Best practices dictate you use your real name and email here, not your login, IRC handle, or any other aliases you may have. These fields will be immortalized in the repository history so make sure you get them right. $ git config --global user.name "Your Name" $ git config --global user.email "Your@emailAddress" While you’re configuring, you may want to enable colouring for some commands: $ git config --global color.diff auto $ git config --global color.status auto $ git config --global color.branch auto $ git config --global color.interactive auto While Git will accept just about any commit message you feed to it, sticking to best practices makes the log a lot easier to work with. A model commit message is shown below. Short (50 chars or less) summary of changes More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line is treated as the subject of an email and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); tools like rebase can get confused if you run the two together. Further paragraphs come after blank lines. - Bullet points are okay, too - Typically a hyphen or asterisk is used for the bullet, preceded by a single space, with blank lines in between, but conventions vary here. - Use a hanging indent As far as submitting your work to the MaNGOS core, the work flow here is still being fleshed out. For now, either give a public URL and branch where your contribution can be found, or use the following series of commands to get a file that can be easily applied by anyone with the git am command to reconstruct your history locally. $ git checkout my_funky_branch $ git rebase origin/master $ git format-patch --stdout origin/master.. > my_funky_patches Here’s a tip for keeping up to date: In lieu of using git pull to download the latest changes, use: $ git pull –rebase --recurse-submodules Instead of cluttering the history with a merge commit, it reapplies your changes to the latest upstream. The only caveat is that you shouldn’t use this method if you’ve already published the changes to another repository. Doing so would cause problems for anyone who has already downloaded the original commits.

Finding Patches for the older clients is not an easy task, the following sites may help:- Older patches can be found here like 2.4.3 to 3.3.0 → 3.3.5a http://www.wowpedia.org/Patch_mirrors The following site lists all patches since alpha to cata (en and us versions) http://www.wowpedia.org/Patch_mirrors_(old_patches)