madmax

THIS ISSUE MAY APPLY CROSS-CORE (ONE,TWO ETC) This issue is confirmed by Antz and myself, we mass marked 1600 accounts at covenant for deletion as part of a cleanup process, only the entries in the character table were removed and no other character data was removed. Issue: After marking characters as deleted (setting a unix date under "DeletedDate" in the Characters table in the Characters database the deletion routine does not remove character data from other character tables. Data has been observed to not be removed from character_queststatus, Character_inventory Character deletion commands - server console: You can do "help character delete" to get more info. character delete list lists deleted characters character delete old deletes all characters marked for deletion, even if you have the setting at 0 to disable it, this command ignores that (use carefully). character deleted delete guid|charname Deletes a single character based on name or guid Fix should include Remove all character data from all character tables on deletion or when the core starts and runs the check A startup task should check existing character data is correct. It should check: All character tables (character data entries) matches up to a VALID GUID entry in the character table, that exists and not marked for deletion. If marked for deletion it should be kept and deleted when the normal deletion routine runs.

We are investigating reports from Covenant-Wow servers that One is crashing at random times. This appears to be while a player is IDLE and sometimes while in combat.

Currently members of the Alliance and Horde cannot get the quest: The Magical Kingdom of Dalaran This needs to be checked out and implemented.

-- Remove the current "creature" portal for both horde and alliance respectively -- DELETE FROM creature WHERE guid = '68120'; DELETE FROM creature WHERE guid = '68119'; -- Create new portal object for both horde and alliance respectively -- insert into `gameobject_template` (`entry`, `type`, `displayId`, `name`, `IconName`, `castBarCaption`, `unk1`, `faction`, `flags`, `size`, `questItem1`, `questItem2`, `questItem3`, `questItem4`, `questItem5`, `questItem6`, `data0`, `data1`, `data2`, `data3`, `data4`, `data5`, `data6`, `data7`, `data8`, `data9`, `data10`, `data11`, `data12`, `data13`, `data14`, `data15`, `data16`, `data17`, `data18`, `data19`, `data20`, `data21`, `data22`, `data23`, `mingold`, `maxgold`) values ('500000','22','4395','Portal to Orgrimmar','','','','1735','0','2','0','0','0','0','0','0','17609','0','0','1','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0'); insert into `gameobject_template` (`entry`, `type`, `displayId`, `name`, `IconName`, `castBarCaption`, `unk1`, `faction`, `flags`, `size`, `questItem1`, `questItem2`, `questItem3`, `questItem4`, `questItem5`, `questItem6`, `data0`, `data1`, `data2`, `data3`, `data4`, `data5`, `data6`, `data7`, `data8`, `data9`, `data10`, `data11`, `data12`, `data13`, `data14`, `data15`, `data16`, `data17`, `data18`, `data19`, `data20`, `data21`, `data22`, `data23`, `mingold`, `maxgold`) values('500001','22','4396','Portal to Stormwind','','','','1732','0','2','0','0','0','0','0','0','17334','0','0','1','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0'); -- Place new portals for both horde and alliance respectively -- insert into `gameobject` (`guid`, `id`, `map`, `spawnMask`, `phaseMask`, `position_x`, `position_y`, `position_z`, `orientation`, `rotation0`, `rotation1`, `rotation2`, `rotation3`, `spawntimesecs`, `animprogress`, `state`) values('300000','500000','530','1','1','-161.318','965.41','54.3738','1.5708','0','0','0.00872639','0.999962','181','100','1'); insert into `gameobject` (`guid`, `id`, `map`, `spawnMask`, `phaseMask`, `position_x`, `position_y`, `position_z`, `orientation`, `rotation0`, `rotation1`, `rotation2`, `rotation3`, `spawntimesecs`, `animprogress`, `state`) values('300001','500001','530','1','1','-337.492','962.619','54.3719','1.22173','0','0','-0.156434','0.987688','181','100','1'); Credit to @necrovoice for providing this.

@antz One needs a DB rollup asap.

Introduction BLP files are used as texture storage. The textures can be stored with a 256 color palette or full 24bit RGB colors. The format supports 1, 4 and 8-bit alpha transparency and DXT compression. The file format is NOT chunked. Wikipedia has a nice overview over the format: http://en.wikipedia.org/wiki/.BLP Header From http://www.pxr.dk/wowdev/wiki/index.php?title=BLP Offset Type Description ------------------------------------------------------------------------------------------ 0x00 char[4] always 'BLP2' 0x04 uint32 Type, always 1 0x08 uint8 Compression: 1 for uncompressed, 2 for DXTC 0x09 uint8 Alpha channel bit depth: 0, 1 or 8 0x0A uint8 Alpha encoding 0x0B uint8 Has MipMaps? 0x0C uint32 X resolution (power of 2) 0x10 uint32 Y resolution (power of 2) 0x14 uint32[16] offsets for every mipmap level (or 0 when there is no more mipmap level) 0x54 uint32[16] sizes for every mipmap level (or 0 when there is no more mipmap level) 0x94 uint32[256] palette of 256 BGRA Values If HasMipMaps is 0, there is only 1 mipmap level. The palette is always present, even if it is not used. In that case all values are 0. Encoding Schemes Type 1 Compression 1 AlphaDepth 0 (uncompressed paletted image with no alpha) Each byte of the image data is an index into Palette which contains the actual RGB value for the pixel. Although the palette entries are 32-bits, the alpha value of each Palette entry may contain garbage and should be discarded. Type 1 Compression 1 AlphaDepth 1 (uncompressed paletted image with 1-bit alpha) This is the same as Type 1 Encoding 1 AlphaDepth 0 except that immediately following the index array is a second image array containing 1-bit alpha values for each pixel. The first byte of the array is for pixels 0 through 7, the second byte for pixels 8 through 15 and so on. Bit 0 of each byte corresponds to the first pixel (leftmost) in the group, bit 7 to the rightmost. A set bit indicates the pixel is opaque while a zero bit indicates a transparent pixel. Type 1 Compression 1 AlphaDepth 8 (uncompressed paletted image with 8-bit alpha) This is the same as Type 1 Encoding 1 AlphaDepth 0 except that immediately following the index array is a second image array containing the actual 8-bit alpha values for each pixel. This second array starts at BLP2Header.Offset[0] + BLP2Header.Width * BLP2Header.Height. Type 1 Compression 2 AlphaDepth 0 (DXT1 no alpha) The image data are formatted using DXT1 compression with no alpha channel. Type 1 Compression 2 AlphaDepth 1 (DXT1 one bit alpha) The image data are formatted using DXT1 compression with a one-bit alpha channel. Type 1 Compression 2 AlphaDepth 4 AlphaEncoding 1 (DXT3 four bits alpha) The image data are formatted using DXT3 compression. Type 1 Compression 2 AlphaDepth 8 AlphaEncoding 1 (DXT3 eight bits alpha) The image data are formatted using DXT3 compression. Type 1 Compression 2 AlphaDepth 8 AlphaEncoding 7 (DXT5) The image data are formatted using DXT5 compression. DXT Compression BLP only uses DXT 1,3 and 5. From: http://en.wikipedia.org/wiki/DXTn DXT1 DXT1 (also known as Block Compression 1 or BC1) is the smallest variation of S3TC, storing 16 input pixels in 64 bits of output, consisting of two 16-bit RGB 5:6:5 colour values and a 4x4 two bit lookup table. If the first colour value (c0) is numerically greater than the second colour value (c1), then two other colours are calculated, such that c2 = 2/3 c0 + 1/3 c1 and c3 = 1/3 c0 + 2/3 c1 Otherwise, if c0 <= c1, then c2 = 1/2 c0 + 1/2 c1 and c3 is transparent black corresponding to a pre-multiplied alpha format. The lookup table is then consulted to determine the colour value for each pixel, with a value of 0 corresponding to c0 and a value of 3 corresponding to c3 . DXT1 does not store alpha data enabling higher compression ratios. DXT3 DXT3 (also known as Block Compression 2 or BC2) converts 16 input pixels (corresponding to a 4x4 pixel block) into 128 bits of output, consisting of 64 bits of alpha channel data (4 bits for each pixel) followed by 64 bits of colour data, encoded the same way as DXT1 (with the exception that the 4 colour version of the DXT1 algorithm is always used instead of deciding which version to use based on the relative values of c0 and c1 ). In DXT3, the colour data is interpreted as not having been pre-multiplied by alpha. Typically DXT2/3 are well suited to images with sharp alpha transitions, between translucent and opaque areas. DXT5 DXT5 (also known as Block Compression 3 or BC3) converts 16 input pixels into 128 bits of output, consisting of 64 bits of alpha channel data (two 8 bit alpha values and a 4x4 3 bit lookup table) followed by 64 bits of colour data (encoded the same way as DXT2 and DXT3). If α0 > α1, then six other alpha values are calculated, such that α2 = (6α0 + 1α1) / 7, α3 = (5α0 + 2α1) / 7, α4 = (4α0 + 3α1) / 7, α5 = (3α0 + 4α1) / 7, α6 = (2α0 + 5α1) / 7, α7 = (1α0 + 6α1) / 7 Otherwise, if α0 <= α1, four other alpha values are calculated such that α2 = (4α0 + 1α1) / 5, α3 = (3α0 + 2α1) / 5, α4 = (2α0 + 3α1) / 5, α5 = (1α0 + 4α1) / 5, α6 = 0, α7 = 255 The lookup table is then consulted to determine the alpha value for each pixel, with a value of 0 corresponding to α0 and a value of 7 corresponding to α7. DXT5's colour data is not pre-multiplied by alpha. Because DXT4/5 use an interpolated alpha scheme, they generally produce superior results for alpha (transparency) gradients than DXT2/3.

BLS specify specific instructions to the video card as to how to render parts of the world and how to do certain effects. There are two major types of shaders: fragment shaders (also known as pixel shaders) and vertex shaders. Fragment shaders are executed on a per-pixel basis, thus can influence texture fetching and combining operations, whereas vertex shaders are executed on a per-vertex basis. These can change vertex positions to achieve mesh animation, particle systems, and texture animation. BLS files can be found under Shaders\Pixel as well as Shaders\Vertex. They are refernced from [[WFX]] files as well as directly from WoW.exe, so there is no client database pointing to them. There are different types of shaders. *Vertex shaders: **arbvp1 **arbvp1_cg12 **vs_1_1 **vs_2_0 **vs_3_0 *Pixel shaders: **arbfp1 **nvrc **nvts **ps_1_1 **ps_1_4 **ps_2_0 **ps_3_0 They are sorted in folders as of 3.*. Previously, there were no different folders but an additional header in the files defining the type. Header *Main header (0xC bytes) This header is in all files - pixel and vertex shaders in all profiles. struct BLSHeader { ''/*0x00*/'' char[4] magix; // in reverse character order: "SVXG" in case of a vertex shader, "SPXG" in case of a fragment shader ''/*0x04*/'' uint32 version; // Always 0x10003 - version 1.3 of format ''/*0x08*/'' uint32 permutationCount; ''/*0x0C*/'' }; Blocks There are permutationCount blocks of the following structure. They are padded to 0x*0, 0x*4, 0x*8 and 0x*C. struct BLSBlock { ''/*0x00*/'' DWORD flags0; // seen: 0x3FE80 in pixel shaders; 0x1A0F in vertex shaders. there may be more .. ''/*0x04*/'' DWORD flags4; // seen: 0x200 in pixel shaders; 0x3FEC1 in vertex shaders (there may be more ..) ''/*0x08*/'' DWORD unk8; // Never seen anything in here. ''/*0x0C*/'' uint32 size; // Tells you how large the block actually is. ''/*0x10*/'' char data[size]; // In whatever format defined. ''/*----*/'' };

Introduction dnc.db specifies the day-night cycle. It hasn't changed in any way from 1.0 or even 0.*. This looks like info for outdoor lighting with respect to the day-night cycle. The colors for the different light types are self-explanatory. The XYZ coordinates specify a directional light source. Header 8 bytes at the beginning of the file specify the number of rows (including head row) and columns 00h uint32 Number of Rows 04h uint32 Number of Columns Data Each data field has exactly 8 bytes. 00h uint32 Field Type (0x53=S for String, 0x46=F for Float) 04h uint32 Field Value String value types are offsets into a Block of Zero-Terminated strings at the end of the file. File contents Extracted and Formatted for a better overview. Hour Minute DayIntensity DayR DayG DayB DayX DayY DayZ 0.0 0.0 0.0 0.0 0.0 0.0 0.7 0.0 1.0 1.0 0.0 0.0 0.0 0.0 0.0 0.7 -0.3 1.0 2.0 0.0 0.0 0.0 0.0 0.0 0.7 -0.5 0.9 3.0 0.0 0.0 0.0 0.0 0.0 0.7 -0.7 0.7 4.0 0.0 0.0 0.0 0.0 0.0 0.7 -0.9 0.5 5.0 0.0 0.0 0.0 0.0 0.0 0.7 -1.0 0.3 6.0 0.0 0.8 0.5 0.5 0.5 0.7 -1.0 0.0 7.0 0.0 0.8 0.5 0.5 0.5 0.7 -1.0 -0.3 8.0 0.0 0.8 0.6 0.6 0.6 0.7 -0.9 -0.5 9.0 0.0 0.8 0.6 0.6 0.6 0.7 -0.7 -0.7 10.0 0.0 0.8 0.7 0.7 0.7 0.7 -0.5 -0.9 11.0 0.0 0.8 0.7 0.7 0.7 0.7 -0.3 -1.0 12.0 0.0 0.8 0.7 0.7 0.7 0.7 0.0 -1.0 13.0 0.0 0.8 0.7 0.7 0.7 0.7 0.3 -1.0 14.0 0.0 0.8 0.7 0.7 0.7 0.7 0.5 -0.9 15.0 0.0 0.8 0.7 0.7 0.7 0.7 0.7 -0.7 16.0 0.0 0.8 0.8 0.7 0.7 0.7 0.9 -0.5 17.0 0.0 0.8 0.8 0.5 0.5 0.7 1.0 -0.3 18.0 0.0 0.8 0.6 0.3 0.3 0.7 1.0 0.0 19.0 0.0 0.8 0.4 0.1 0.1 0.7 1.0 0.3 20.0 0.0 0.0 0.2 0.0 0.0 0.7 0.9 0.5 21.0 0.0 0.0 0.0 0.0 0.0 0.7 0.7 0.7 22.0 0.0 0.0 0.0 0.0 0.0 0.7 0.5 0.9 23.0 0.0 0.0 0.0 0.0 0.0 0.7 0.3 1.0 Hour Minute NightIntensity NightR NightG NightB NightX NightY NightZ 0.0 0.0 1.0 0.0 0.0 0.5 0.7 0.0 -1.0 1.0 0.0 1.0 0.0 0.0 0.5 0.7 0.3 -1.0 2.0 0.0 1.0 0.0 0.0 0.5 0.7 0.5 -0.9 3.0 0.0 1.0 0.0 0.0 0.5 0.7 0.7 -0.7 4.0 0.0 1.0 0.0 0.0 0.5 0.7 0.9 -0.5 5.0 0.0 1.0 0.0 0.0 0.5 0.7 1.0 -0.3 6.0 0.0 0.0 0.0 0.0 0.0 0.7 1.0 0.0 7.0 0.0 0.0 0.0 0.0 0.0 0.7 1.0 0.3 8.0 0.0 0.0 0.0 0.0 0.0 0.7 0.9 0.5 9.0 0.0 0.0 0.0 0.0 0.0 0.7 0.7 0.7 10.0 0.0 0.0 0.0 0.0 0.0 0.7 0.5 0.9 11.0 0.0 0.0 0.0 0.0 0.0 0.7 0.3 1.0 12.0 0.0 0.0 0.0 0.0 0.0 0.7 0.0 1.0 13.0 0.0 0.0 0.0 0.0 0.0 0.7 -0.3 1.0 14.0 0.0 0.0 0.0 0.0 0.0 0.7 -0.5 0.9 15.0 0.0 0.0 0.0 0.0 0.0 0.7 -0.7 0.7 16.0 0.0 0.0 0.0 0.0 0.0 0.7 -0.9 0.5 17.0 0.0 0.0 0.0 0.0 0.0 0.7 -1.0 0.3 18.0 0.0 1.0 0.0 0.0 0.0 0.7 -1.0 0.0 19.0 0.0 1.0 0.0 0.0 0.0 0.7 -1.0 -0.3 20.0 0.0 1.0 0.0 0.0 0.0 0.7 -0.9 -0.5 21.0 0.0 1.0 0.0 0.0 0.5 0.7 -0.7 -0.7 22.0 0.0 1.0 0.0 0.0 0.5 0.7 -0.5 -0.9 23.0 0.0 1.0 0.0 0.0 0.5 0.7 -0.3 -1.0 Hour Minute Ambient Intensity AmbientR AmbientG AmbientB FogDepth FogIntensity FogR FogG FogB 0.0 0.0 0.8 0.3 0.3 0.6 3700.0 0.8 0.0 0.0 0.1 1.0 0.0 0.8 0.3 0.3 0.6 3700.0 0.8 0.0 0.0 0.1 2.0 0.0 0.8 0.3 0.3 0.6 3700.0 0.8 0.0 0.0 0.1 3.0 0.0 0.8 0.3 0.4 0.6 3700.0 0.8 0.0 0.0 0.1 4.0 0.0 0.8 0.4 0.4 0.7 3700.0 0.7 0.0 0.0 0.1 5.0 0.0 0.8 0.4 0.4 0.7 3700.0 0.7 0.0 0.0 0.1 6.0 0.0 0.8 0.6 0.6 0.8 3700.0 0.7 0.1 0.1 0.1 7.0 0.0 0.8 0.6 0.6 0.8 3700.0 0.5 0.2 0.2 0.2 8.0 0.0 0.8 0.6 0.6 0.8 3700.0 0.3 0.2 0.2 0.2 9.0 0.0 0.8 0.7 0.7 0.9 3700.0 0.3 0.2 0.2 0.2 10.0 0.0 0.8 0.8 0.8 0.9 3700.0 0.3 0.2 0.2 0.2 11.0 0.0 0.8 0.9 0.9 0.9 3700.0 0.3 0.2 0.2 0.2 12.0 0.0 0.8 1.0 1.0 1.0 3700.0 0.3 0.2 0.2 0.2 13.0 0.0 0.8 0.9 0.9 0.9 3700.0 0.3 0.2 0.2 0.2 14.0 0.0 0.8 0.8 0.8 0.9 3700.0 0.3 0.2 0.2 0.2 15.0 0.0 0.8 0.7 0.7 0.9 3700.0 0.3 0.1 0.1 0.1 16.0 0.0 0.8 0.7 0.7 0.9 3700.0 0.3 0.1 0.1 0.1 17.0 0.0 0.8 0.6 0.6 0.8 3700.0 0.3 0.1 0.1 0.1 18.0 0.0 0.8 0.4 0.4 0.8 3700.0 0.5 0.1 0.1 0.1 19.0 0.0 0.8 0.4 0.4 0.7 3700.0 0.7 0.0 0.0 0.1 20.0 0.0 0.8 0.4 0.4 0.7 3700.0 0.7 0.0 0.0 0.1 21.0 0.0 0.8 0.4 0.3 0.7 3700.0 0.7 0.0 0.0 0.1 22.0 0.0 0.8 0.3 0.3 0.7 3700.0 0.8 0.0 0.0 0.1 23.0 0.0 0.8 0.3 0.3 0.6 3700.0 0.8 0.0 0.0 0.1

These files are obsolete! LIT files have stored lighting-information until some patch. Today, lightning is stored in the following DBC files: Light.dbc LightFloatBand.dbc LightIntBand.dbc LightParams.dbc LightSkybox.dbc For worlds that have terrain data, a corresponding LIT file includes information about the sky color, and possibly lighting conditions. They are stored in World\name\lights.lit Header Offset Type Description 0x00 uint32 Always 05 00 00 80 0x04 uint32 nSkies - number of skies defined in this file 64 bytes per sky: Offset Type Description 0x00 3 * int32 (-1,-1,-1) for the 'default' first record, (0,0,0) otherwise 0x0C 3 * float Coordinates (X,Y,Z) 0x18 float Smaller radius for area (?) 0x1C float Larger radius 0x20 char[32] Sky name The float values seem to be multiplied by 36. Dividing by 36 gives back the original scale (I think) In the case of "I think", I think that the game client uses the floats to perform some kind of Cube-Mapped LightMapping (hence the X, Y, Z, -X, -Y, -Z values). -DG Sky data 4 * 0x15F0 bytes per sky. The first block of the four seems to have the sky colors, the second and fourth are usually all black, the third might be lighting colors or something else entirely. Offset Type Description 0x0000 18 * int32 Lengths 0x0048 18 * 64 * int32 Color + time records 0x1248 32 * float Float values A 0x12C8 32 * float Float values B 0x1348 uint32 Int value I 0x134C 32 * float Float values C 0x13CC 32 * float Float values D 0x144C 32 * float Float values E 0x14CC 32 * float Float values F 0x154C uint32 Int value J 0x1550 32 * float Float values G 0x15D0 8 * uint32 Padding (all 0) The color and time records are in the following format: Each row of 64 integers contains 32 pairs of integers: the first value is the time in half-minutes (on a scale of 0 to 2880 from midnight to midnight), the second value is a BGRX color. The i-th row contains Lengths[ i ] records like that. I think the color values for intermediate times are interpolated based on the times given in this list. So there are 18 time-based color rows described here, for the first block these are always the sky colors (well, the first 8 at least). WoWmapview is currently only drawing a very crude, fake sky globe - the colors may or may not match up The 7 sets of floating-point values have to describe the arrangement of the sky colors somehow, but they're pretty difficult to interpret. They usually contain at most 8 values, the rest being 0. So today I experimented with a custom .LIT file (red and blue skies are hilarious), so here are the meanings for the various color tracks: Number Description 0 Global diffuse light 1 Global ambient light 2 Sky color 0 (top) 3 Sky color 1 (middle) 4 Sky color 2 (middle to horizon) 5 Sky color 3 (above horizon) 6 Sky color 4 (horizon) 7 Fog color / background mountains color 8 ? 9 Sun color + sun halo color 10 Sun larger halo color 11 ? 12 Cloud color 13 ? 14 ? 15 Ground shadow color 16 Water color [light] 17 Water color [dark] The different skies are interpolated based on distance. The four sets of data are completely different. Number Description 0 The default look. 1 and 3 are usually all black. 2 might be the 'ghost view' lighting for when you're dead.

Introduction M2 or MDX files are used to store polygon models along with their animations and other information. The file format is plain binary - no chunks. Information is mainly from http://www.pxr.dk/wowdev/wiki/index.php?title=M2 as well as from PseuWoW source. A note on coordinates Blizzard uses an left-handed (?) Z-up coordinate system for the models. When loading, coordinate conversions must be applied for other coordinate systems. This also must be done for all animation data. File Structure M2 files start with a header block which contains an index of number-offset pairs for all other data blocks. All other blocks follow after that one. Blocks are not delimited, but seem to be aligned to 16 byte boundaries. Header Position 0 Length 324 bytes The file format is identified by the magic string "MD20". Pairs of uint32 are given for every data block. nXXX describes the number of elements (not necessarily bytes) in this block while ofsXXX gives the offset to the beginning of the block. If a block does not exists, n and ofs are 0. Offset Type Description -------------------------------------------------------------------- 0x000 char[4] Magic Bytes => "MD20" 0x004 uint32 Version (0x100 before Burning Crusade, 0x104 after BC) 0x008 uint32 nName - model name length (including \0) 0x00C uint32 ofsName - model name offset 0x010 uint32 GlobalModelFlags (0,1,3 seen) 0x014 uint32 nGlobalSequences - number of global sequences 0x018 uint32 ofsGlobalSequences - offset to global sequences 0x01C uint32 nAnimations - number of animation sequences 0x020 uint32 ofsAnimations - offset to animation sequences 0x024 uint32 nAnimationLookup 0x028 uint32 ofsAnimationLookup 0x02C uint32 nD - always 201 or 203 depending on client version 0x030 uint32 ofsD 0x034 uint32 nBones - number of bones 0x038 uint32 ofsBones - offset to bones 0x03C uint32 nSkelBoneLookup - skeletal bone lookup table 0x040 uint32 ofsSkelBoneLookup 0x044 uint32 nVertices - number of vertices 0x048 uint32 ofsVertices - offset to vertices 0x04C uint32 nViews - number of views (LOD versions?) 4 for every model 0x050 uint32 ofsViews - offset to views 0x054 uint32 nColors - number of color definitions 0x058 uint32 ofsColors - offset to color definitions 0x05C uint32 nTextures - number of textures 0x060 uint32 ofsTextures - offset to texture definitions 0x064 uint32 nTransparency - number of transparency definitions 0x068 uint32 ofsTransparency - offset to transparency definitions 0x06C uint32 nI - always 0 0x070 uint32 ofsI 0x074 uint32 nTexAnims - number of texture animations 0x078 uint32 ofsTexAnims - offset to texture animations 0x07C uint32 nTexReplace 0x080 uint32 ofsTexReplace 0x084 uint32 nRenderFlags - number of blending mode definitions 0x088 uint32 ofsRenderFlags - offset to blending mode definitions 0x08C uint32 nBoneLookupTable - bone lookup table 0x090 uint32 ofsBoneLookupTable 0x094 uint32 nTexLookup - number of texture lookup table entries 0x098 uint32 ofsTexLookup - offset to texture lookup table 0x09C uint32 nTexUnits - texture unit definitions? 0x0A0 uint32 ofsTexUnits 0x0A4 uint32 nTransLookup - number of transparency lookup table entries 0x0A8 uint32 ofsTransLookup - offset to transparency lookup table 0x0AC uint32 nTexAnimLookup - number of texture animation lookup table entries 0x0B0 uint32 ofsTexAnimLookup - offset to texture animation lookup table 0x0B4 float[14] float values ... ? (in range -1000...1000, mostly in -20...30) 0x0EC uint32 nBoundingTriangles 0x0F0 uint32 ofsBoundingTriangles 0x0F4 uint32 nBoundingVertices 0x0F8 uint32 ofsBoundingVertices 0x0FC uint32 nBoundingNormals 0x100 uint32 ofsBoundingNormals 0x104 uint32 nAttachments 0x108 uint32 ofsAttachments 0x10C uint32 nAttachLookup 0x110 uint32 ofsAttachLookup 0x114 uint32 nAttachments_2 0x118 uint32 ofsAttachments_2 0x11C uint32 nLights - number of lights 0x120 uint32 ofsLights - offset to lights 0x124 uint32 nCameras - number of cameras 0x128 uint32 ofsCameras - offset to cameras 0x12C uint32 nCameraLookup 0x130 uint32 ofsCameraLookup 0x134 uint32 nRibbonEmitters - number of ribbon emitters 0x138 uint32 ofsRibbonEmitters - offset to ribbon emitters 0x13C uint32 nParticleEmitters - number of particle emitters 0x140 uint32 ofsParticleEmitters - offset to particle emitters Vertices Position header.ofsVertices Element size 48 bytes Vertices are global for all submeshes and views. Offset Type Description -------------------------------------------------------------------- 0x00 float[3] Position (X,Y,Z) 0x0C uint8[4] Bone weights (0 to 255) 0x10 uint8[4] Bone indices (0 to nBones-1) 0x14 float[3] Normal vector (nX, nY, nZ) 0x20 float[2] Texture coordinates (U, V) 0x28 float[2] unknown, mostly 0.0f Views Position header.ofsViews Element size 44 bytes It is not clear what Views are for. But there are always 4 of them. Offset Type Description -------------------------------------------------------------------- 0x00 uint32 nIndex - number of elements in the index list 0x04 uint32 ofsIndex - offset to the index list 0x08 uint32 nTriangle - number of elements in the triangle list (this is 3* the number of triangles to be drawn) 0x0C uint32 ofsTriangle - offset to the triangle list 0x10 uint32 nProps - number of elements in the vertex property list 0x14 uint32 ofsProps - offset to the vertex property list 0x18 uint32 nSubmesh - number of elements in the submesh list 0x1C uint32 ofsSubmesh - offset to the submesh list 0x20 uint32 nTexture - number of elements in the texture list 0x24 uint32 ofsTexture - offset to the texture list 0x28 uint32 LOD distance or something? Indices nIndex uint16 values - referencing vertices from the global Vertex list. Triangles 3 uint16 values per triangle - referencing the Index list Properties 4 bytes per Vertex. Those are indices into the BoneLookupTable for each Vertex. Submeshes 32 bytes per Submesh definition. Offset Type Description -------------------------------------------------------------------- 0x00 uint32 Mesh part ID 0x04 uint16 ofsVertex - Starting vertex number, offset into the Vertex array 0x06 uint16 nVertex - Number of vertices 0x08 uint16 ofsTriangle - Starting triangle index 0x0A uint16 nTriangle - Number of triangle indices 0x0C uint16 nBoneLookup - Number of elements in the bone lookup table 0x0E uint16 ofsBoneLookup - Starting index in the bone lookup table 0x10 uint16 unknown 0x12 uint16 unsure - maybe root bone? 0x14 float[3] Vector (3d) - mass center? Mesh part ID These IDs are referenced for Geosets and such. For character models, each hairstyle/thick armor/etc is present in the mesh, so to render a character with a specific set of looks, some of the submeshes should be omitted based on this ID.The submeshes are sorted into groups. Groups are like this for character models. They can be different for other models. 00**: Hairstyles 01**: Facial1 02**: Facial2 03**: Facial3 04**: Braces 05**: Boots 06**: Unknown 07**: Ears 08**: Wristbands 09**: Kneepads? 10**: 11**: Related to pants 12**: Tabard 13**: Trousers / kilts 14**: 15**: Cape 16**: 17**: Eyeglows (including the deathknight ones) 18**: Belt / bellypack These are referenced in CreatureDisplayInfo.dbc->creatureGeosetData.

MPQ File Format Introduction All of the game data for WoW are stored in MPQ Archives. The format's capabilities include compression, encryption, file segmentation, extensible file metadata, cryptographic signature and the ability to store multiple versions of the same file for internationalization and platform-specific differences. MPQ archives can use a variety of compression algorithms which may also be combined. The definitive source for information on MPQ Files is http://wiki.devklog.net/index.php?title=The_MoPaQ_Archive_Format. The following summary only includes facts relevant for 1.12.X Client versions Technical overview All numbers in the MPQ format are in little endian byte order; signed numbers use the two's complement system. Data types are listed either as int (integer, the number of bits specified), byte (8 bits), or char (bytes which contain ASCII characters). All sizes and offsets are in bytes, unless specified otherwise. Structure members are listed in the following general form: offset from the beginning of the structure: data type(array size) member name : member description General Archive Layout The physical layout of the files looks like this Archive HeaderFile DataHash TableBlock Table In the following the components are discussed in the logical order of processing required to read and extract files from MPQ Archives Archive Header Header size is 32 bytes, maximum archive size is 4 GB. 00h: char(4) Magic Indicates that the file is a MPQ archive. Must be ASCII "MPQ" 1Ah. 04h: int32 HeaderSize Size of the archive header. 08h: int32 ArchiveSize Size of the whole archive, including the header. 0Ch: int16 FormatVersion MPQ format version. 0000h for Classic WoW. 0Eh: int8 SectorSizeShift Power of two exponent specifying the number of 512-byte disk sectors in each logical sector in the archive. The size of each logical sector in the archive is 512 * 2^SectorSizeShift. Bugs in the Storm library dictate that this should always be 3 (4096 byte sectors). 10h: int32 HashTableOffset Offset to the beginning of the hash table, relative to the beginning of the archive. 14h: int32 BlockTableOffset Offset to the beginning of the block table, relative to the beginning of the archive. 18h: int32 HashTableEntries Number of entries in the hash table. Must be a power of two, and must be less than 2^16 1Ch: int32 BlockTableEntries Number of entries in the block table. Hash Table The Hash Table serves as a quick means of filename lookup without having to go through string comparisons. For each file in the archive, the full path is hashed using a proprietary algorithm (for source see http://wiki.devklog.net/index.php?title=The_MoPaQ_Archive_Format#Algorithm_Source_Code) resulting in three 32bit integers. The first of those hashes serves as primary lookup key for the Hash Table, the others are used for verification in case of a hash collision. In the case that two files have the same lookup key (hash collision), the first file is stored under that hash, and the second file is stored under the next free hash. So during lookup, if the second and third hash don't match, the algorithm goes down the list until it either finds a match of an empty entry. Each entry in the Hash Table looks like this: 00h: int32 FilePathHashA The hash of the file path, using method A. 04h: int32 FilePathHashB The hash of the file path, using method B. 08h: int16 Language The language of the file. This is a Windows LANGID data type, and uses the same values. 0 indicates the default language (American English), or that the file is language-neutral. 0Ah: int8 Platform The platform the file is used for. 0 indicates the default platform. No other values have been observed. 0Ch: int32 FileBlockIndex If the hash table entry is valid, this is the index into the block table of the file. Otherwise, one of the following two values: FFFFFFFFh Hash table entry is empty, and has always been empty. Terminates searches for a given file. FFFFFFFEh Hash table entry is empty, but was valid at some point (in other words, the file was deleted). Does not terminate searches for a given file. The Hash Table is encrypted using a proprietary encryption algorithm using "(hash table)" as key. The encryption algorithm is also documented at http://wiki.devklog.net/index.php?title=The_MoPaQ_Archive_Format#Algorithm_Source_Code Block Table The Block Table contains offsets into the File Data block for each File in the Archive. It also stores file attributes like compression or encryption. Hash Table FileBlockIndex points to entries in the Block Table. Like the Hash Table it is encrypted, using "(block table)" as key. Each Block Table entry looks like this: 00h: int32 BlockOffset Offset of the beginning of the block, relative to the beginning of the archive. 04h: int32 BlockSize Size of the block in the archive. 08h: int32 FileSize Size of the file data stored in the block. If the file is compressed, this is the size of the uncompressed file data. 0Ch: int32 Flags Bit mask of the flags for the block. Known flags are: Flag name Value Meaning ----------------------------------------------------------------------------------------------------- MPQ_FILE_IMPLODE 0x00000100 File is compressed using PKWARE Data compression library MPQ_FILE_COMPRESS 0x00000200 File is compressed using combination of compression methods MPQ_FILE_ENCRYPTED 0x00010000 The file is encrypted MPQ_FILE_FIX_KEY 0x00020000 The decryption key for the file is altered according to the position of the file in the archive MPQ_FILE_PATCH_FILE 0x00100000 The file contains incremental patch for an existing file in base MPQ MPQ_FILE_SINGLE_UNIT 0x01000000 Instead of being divided to 0x1000-bytes blocks, the file is stored as single unit MPQ_FILE_DELETE_MARKER 0x02000000 File is a deletion marker, indicating that the file no longer exists. This is used to allow patch archives to delete files present in lower- priority archives in the search chain. The file usually has length of 0 or 1 byte and its name is a hash MPQ_FILE_SECTOR_CRC 0x04000000 File has checksums for each sector (explained in the File Data section). Ignored if file is not compressed or imploded. MPQ_FILE_EXISTS 0x80000000 Set if file exists, reset when the file was deleted File Data Block Table BlockOffset points to the beginning of a file data block. Each file data block has a header of nSectors+1 int32 values, indicating offsets to each sector start (relative to the beginning of the file data block). The final value of this list is the total (compressed) file size, including the header. The size of each block can easily be calculated from the difference between two offsets. If the block is compressed, the first byte of every sector indicates the compression method used Extracting a file This is a step-by-step instruction. Read the File Header, find the offsets to the Hash Table and Block Table Read and Decrypt Hash Table and Block Table Compute Hashes for the file (Full Path, all Slashes converted to Backslashes) => Hash0, Hash1, Hash2 HashTableOffset = Hash0 & (Header.HashTableEntries -1) Starting from HashTableOffset, go through the Hash Table and compare Hash1 and Hash2 to HashTable.FilePathHashA and HashTable.FilePathHashB respectively until either a match or an empty entry is found. In the latter case the file you are looking for does not exist. Find the Block Table entry which corresponds to HashTable.FileBlockIndex Go to the file offset specified in BlockTable.BlockOffset Read int32 values until you reach a value that is equal to BlockTable.BlockSize => SectorOffset[0] ... SectorOffset[n] For every entry of SectorOffset[0]...SectorOffset[n-1], seek to BlockTable.BlockOffset+SectorOffset[x] Read SectorOffset[x+1]-SectorOffset[x] bytes of data. If BlockTable.Flags has a compressed flag set, the first byte of each sector indicates the compression method applied. Decrypt and or decompress each sector as necessary, stitch them together, et voila, there is your file The Listfile Each MPQ in WoW 1.12.X contains a "(listfile)". This file lists the full archive contents, one file path per line, in clear text. Hashing the file paths provides lookup keys into Hash Table. The file is provided for convenience, as it seems. It is not used by the client

Introduction For each cinematic there is one SBT (SuBTitle) file found in Interface\Cinematics (interface.MPQ). It contains localized subtitles for movies. File Structure At the beginning are 3 bytes 0xEF BB BF. Some kind of ID/Magic bytes/unknown stuff. Each entry is made of a timestamp and a text. The entries are divided by an empty line. 00:00:04:06 - 00:00:13:01 Four years have passed since the mortal races banded together and stood united against the might of the Burning Legion. 00:00:14:00 - 00:00:22:05 Though Azeroth was saved, the tenuous pact between the Horde and the Alliance has all but evaporated. 00:00:24:06 - 00:00:28:21 The drums of war thunder once again. The timestamp is hr:min:sec:msec.