ADT/v18

From wowdev
Jump to navigation Jump to search

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.

MHDR chunk

  • 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. 

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 offsFlightBoundary; // tbc, wotlk	
/*028h*/  UINT32 offsMH2O;		// new in WotLK
/*02Ch*/  UINT32 pad3;	
/*030h*/  UINT32 pad4;		
/*034h*/  UINT32 pad5;		
/*038h*/  UINT32 pad6;		
/*03Ch*/  UINT32 pad7;	
/*040h*/
};

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.

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.

MMDX chunk

  • List of filenames for M2 models that appear in this map tile. A contiguous block of zero-terminated strings.

MMID chunk

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

MWMO chunk

  • List of filenames for WMOs (world map objects) that appear in this map tile. A contiguous block of zero-terminated strings.

MWID chunk

  • Lists the relative offsets of string beginnings in the above MWMO chunk. (again, redundant) One 32-bit integer per offset.

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.

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 	Upper Extents
0x2C 	3 floats 	Lower Extents
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)


MH2O chunk

This is a new chunk in WotLK. The old MCLQ subchunk died for it. Its now holding all values for the adt in one chunk.

The chunk itself is seperated in three parts. A header, the data-block and the other referenced data.

Structure

Header

The header is a list of 256 entries of this structure: 

0x00	int32	ofsInformation		An offset to the first data-block.
0x04	int32	layer count		0 if the chunk has no liquids. If > 1, the offsets will point to arrays.
0x08	int32	ofsData		An offset to the second data-block.

struct MH2O_Header
{
	MH2O_Information ** information;	// points to an array with layers entries.
	uint32 layers;
	char * Mask1[];			// the blocks to render. 8*8 bits (=8 bytes). regardless of the information on width and height.
}

Information

This block is made of 0x18 bytes and is at ofsInformation for all layers. 

0x00	int16	flags			Mostly 5
0x02	int16	type			Seems to be the type of liquid (0 for normal "lake" water, 1 for lava and 2 for ocean water)
0x04	float	heightLevel1		The global liquid-height of this chunk. Which is always in there twice. Blizzard knows why.
0x08	float	heightLevel2		(Actually these values are not always identical, I think they define the highest and lowest points in the heightmap)
0x0C	byte	xOffset			The X offset of the liquid square (0-7)
0x0D	byte	yOffset			The Y offset of the liquid square (0-7)
0x0E	byte	width			The width of the liquid square (1-8)
0x0F	byte	height			The height of the liquid square (1-8)
0x10	int32	ofsMask2		Offset to some data.
0x14	int32	ofsHeightmap		Another offset to data.

struct MH2O_Information
{
	uint16 flags;
	uint16 type;
	float levels[2];
	char x, y, w, h;
	char * Mask2[];		// points to an array of bits with information about the mask. w*h bits (=h bytes).
	MH2O_Data * Data;
}

Data

This block holds w*h float values defining the actual water heights. After them, there are the transparency bytes. These bytes define, if the ocean is full blue or if the ground can be seen. 

struct MH2O_Data
{
	float heightmap[]; 	// w*h, not if type & flags are 2, 0 (ocean)
	char transparency[]; 	// w*h
}

Explanation: Mask1 & Mask2

These bits define which tiles / blocks of the chunk are filled with water.

  • Mask1 are all possible tiles and if they are rendered.
  • Mask2 is listing only those which are needed and defined in Information (x, y, w, h).

More indepth and with example below. Thanks Slartibartfast.

The full heightmap that covers a whole chunk would be created from 9x9 float values, effectively creating 8x8 quadratic pieces. But since WotLK and the introduction of the MH2O chunk there is no more need to define the full heightmap if only part of a chunk is actually covered with water (such as with a thin river). Instead, the four byte values in ofsData1 define the size and location of a "liquid rectangle" which can be smaller than a full chunk.

An example: let's say there's a river crossing a chunk like this ('x' is the river): 

++++++++
++++++++
xxxxxx++
++xxxxxx
++++++++
++++++++
++++++++
++++++++

This would lead to xOffset = 0, yOffset = 2, width = 8 and height = 2. The data at ofsData2b would then list 27 float values for the heightmap (a 9x3 heightmap which results in 8x2 quads, as shown in the picture above).

The data at ofsData2a would finally define which of the quads should be rendered. Its length is always height bytes, and each byte is a bitmap which contains a 1 for each quad to be rendered and a 0 for each invisible quad. In our example this would be two bytes: 0xFC (binary 11111100) for the first line and 0x3F (binary 00111111) for the second line.

Note that it is always possible to omit ofsData2a and/or ofsData2b to save some bytes in the ADT file! If ofsData2a is not given, the whole "liquid rectangle" is to be rendered. If ofsData2b is not given, then the height map consists only of values equal to heightLevel1 (I am not 100% sure of this one, but this approach seems to work fine for me).

--Slartibartfast 00:41, 30 October 2008 (CEST)

MCNK chunk

  • 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. 

Offset	Type		Description
0x3C 	uint32 		holes in terrain
0x68 	float 		Z' base coordinate
0x6C 	float 		X' base coordinate
0x70 	float 		Y base coordinate
0x00 	uint32		flags
0x04	UINT32 		IndexX
0x08	UINT32 		IndexY
0x0C	UINT32		nLayers
0x10	UINT32		nDoodadRefs
0x14	UINT32		offsHeight
0x18	UINT32		offsNormal
0x1C	UINT32 		offsLayer
0x20	UINT32 		offsRefs
0x24	UINT32 		offsAlpha
0x28	UINT32 		sizeAlpha
0x2C	UINT32 		offsShadow
0x30	UINT32 		sizeShadow
0x34	UINT32 		areaid
0x38	UINT32 		nMapObjRefs
0x3C	UINT32 		holes
0x40	UINT16 		unk1
0x40	UINT16 		unk2
0x44	UINT32 		unk3
0x48	UINT32 		unk4
0x4C	UINT32 		unk5
0x50	UINT32 		predTex
0x54	UINT32 		noEffectDoodad
0x58	UINT32 		offsSndEmitters
0x5C	UINT32 		nSndEmitters
0x60	UINT32 		offsLiquid
0x64	UINT32 		sizeLiquid
0x68	3*float  	pos
0x74	UINT32 		offsColorValues
0x78	UINT32 		props
0x7C	UINT32 		effectId

struct SMChunk // 03-29-2005 By ObscuR, 11-08-2008 by Tharo
{
	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;
/*042h*/  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 offsColorValue; //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. :)

flags: 

Flag		Meaning
0x1 		Always set
0x4 		Has water(pre-Wotlk ->MCLQ)

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.
  • Inner 8 vertices are only rendered in WoW when its using the up-close LoD. Otherwise, it only renders the outer 9. -Eric
  • 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
	}
}
  • or try this one (made by tharo)
// to make it not TOO complicated u get data as 9*9 and 8*9 chain. 
// the 9th value is never used but calculation is more easy now ^^
private int stripify(Point3d[] in, Point3d[] out) {
     int outc=0;
     		
     for (int row=0; row<8; row++) {
           int thisrow = row*9*2;
           int nextrow = row*9*2 + 9;
           int overrow = (row+1) *9*2;
     			
           for(int col=0; col<8; col++) {
                 out[outc++] = in[thisrow+col];
                 out[outc++] = in[nextrow+col]; 
           }
           out[outc++] = in[thisrow+8];
     			
           for(int col=8; col>0; col--) {
                 out[outc++] = in[overrow+col];
                 out[outc++] = in[nextrow+col-1]; 
           }
           out[outc++] = in[overrow];
           out[outc++] = in[thisrow];
           out[outc++] = in[nexttow];
           out[outc++] = in[overrow];
     }
     for(int row=8; row>=0; row--) {
           out[outc++] = in[row*9*2];
     }		
     return outc;
}

MCCV sub-chunk

New Subchunk found in Northrend-adts(and only there as far as I see). Size seems to be always 0x244. Offset seems to be at 0x74 in the MCNK-header.

--Tigurius:Found in WotLK-Beta 3.0.1


The chunk contains 145 color values, each one is designated to one of the heightmap vertices. Each single color is defined in 4 bytes: 

Offset	Type 		Description
0x0 	byte 		red value
0x1 	byte 		green value
0x2 	byte 		blue value
0x3 	byte 		alpha value? (usually 0xFF, changing this doesn't have any visible effect)

The color components are one byte each, with 0x7F being 1.0, 0x00 being 0.0 and 0xFF being 2.0 (I am not sure about the 2.0 factor, but the visible change when setting a component to 0xFF suggests this value).

When rendering, these color settings manipulate the final color of a pixel in a chunk by multiplication. Usually all the component values are set to 0x7F (= multiplication with 1.0), which means there's no modification at all. But if set to (for example) 0x00, a chunk can be made completely black, or if set to 0xFF, a chunk is rendered brighter than normal.

--Slartibartfast 1 November 2008

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.

--Log 09:23, 28 May 2006 (EEST) Maybe the extra data are "edge flag" bitmaps that are used only by the client for smoothing normals around adjustment triangles ? I didn't check it, just a hint.

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
0x200          Alpha map is compressed (see MCAL chunk description)

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.

MCRF sub-chunk

  • A list of indices into the parent file's MDDF chunk, saying which MCNK subchunk those particular MDDF doodads are drawn within. This MCRF list contains duplicates for map doodads that overlap areas. But I guess that's what the MDDF's UniqueID field is for.

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. Note that the shadow values come LSB first.

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.

Flow - 21-10-2008:

In Wotlk these chunks are compressed.

I think it's a self made compression. Really simple. The size field of this chunk doesn't matter anymore.

How the decompression works

  • read a byte
  • check for sign bit
  • if set we are in fill mode else we are in copy mode
  • take the 7 lesser bits of the first byte as a count indicator
    • fill mode: read the next byte an fill it by count in resulting alpha map
    • copy mode: read the next count bytes and copy them in the resulting alpha map
  • if the alpha map is complete we are done otherwise start at 1. again

Sample C++ code 

// 21-10-2008 by Flow
unsigned offI = 0; //offset IN buffer
unsigned offO = 0; //offset OUT buffer
char* buffIn; // pointer to data in adt file
char buffOut[4096]; // the resulting alpha map

while( offO < 4096 )
{
  // fill or copy mode
  bool fill = buffIn[offI] & 0x80;
  unsigned n = buffIn[offI] & 0x7F;
  offI++;
  for( unsigned k = 0; k < n; k++ )
  {
    buffOut[offO] = buffIn[offI];
    offO++;
    if( !fill )
      offI++;
  }
  if( fill ) offI++;
}

Tested with Wotlk Beta build 8770

Note: not all alpha maps are compressed; some of them are just stored as 4096 plain bytes. If an alpha map is compressed can be determined by checking the compression flag in the corresponding MCLY chunk entry. - Slartibartfast

Anyone know of a good way to find out whether an uncompressed alphamap is 2048 (preWotLK) or 4096 (postWotLK)?

Slartibartfast - 1 November 2008:

Blizzard has changed the way how the additional textures are blended onto the ground texture in Northrend (old continents still seem to be blended the old way; they also don't use the new alpha map format). They have gone from a "one-layer-per-step" approach to blending all the 4 textures in a single step according to the following formula: 

finalColor = tex0 * (1.0 - (alpha1 + alpha2 + alpha3)) + tex1 * alpha1 + tex2 * alpha2 + tex3 * alpha3

So all the alpha values for the different layers including the ground layer add up to 1.0; the ground layer's alpha value is calculated to match this constraint.

How to render

It is of course possible to devise different ways to render such terrain; one way I use and of which I know that it's working is a 2-pass-approach: first render all ground textures without blending, then use a fragment shader program to mix the 1-3 additional layer textures and render them with a glBlendFunc setting of (GL_ONE, GL_ONE_MINUS_SRC_ALPHA) on top of the ground texture already present in the framebuffer. The fragment program that mixes the textures would have to work like this short GLSL example: 

gl_FragColor =   texture2D(texture0, vec2(gl_TexCoord[0])) * texture2D(texture3, vec2(gl_TexCoord[3])).r
               + texture2D(texture1, vec2(gl_TexCoord[1])) * texture2D(texture3, vec2(gl_TexCoord[3])).g
               + texture2D(texture2, vec2(gl_TexCoord[2])) * texture2D(texture3, vec2(gl_TexCoord[3])).b;

(this example uses 4 texture units: texture0 - texture3; the first 3 of them contain the actual textures, while the fourth unit contains the alpha maps combined in one RGB texture)

MCSE sub-chunk

  • Sound emitters.
struct CWSoundEmitter // 04-29-2005 By ObscuR (Maybe not accurate but should look like this :p )
{
/*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*/  	
};

MFBO chunk

  • Unknown chunk added to the end of some ADT files released with BC.

This chunk was added to all ADT files released with BC. It comes directly after the last MCNK chunk, and is 44 bytes long. (Including header info) Possibly flight box information for Outlands.(?)

Tharo 07:04, 9 November 2008 (CET)


Retrieved from "http://wowdev.org/wiki/index.php/ADT"

Retrieved from "https://wowdev.wiki/index.php?title=ADT/v18&oldid=2146"