WLD 0x04 Fragment Question

[PixelEngineer]

Hi, this fragment is completed but I am getting a different structure than what I see being used in azone and being used in the WLD documentation.

First off, just to make sure I am on the right page, bits are counted starting at zero. In the WLD documentation, the bits also start at zero. What confuses me is that in azone's handling of 0x04, they check the flags but are off by 1 each time.

For instance, here is the WLD documentation:

0x04 — Texture Bitmap Info — PLAIN 
 
Notes 
 
This fragment represents an entire texture rather than merely a bitmap used by that texture. The conceptual difference from 
0x03 fragments is that textures may be animated; the 0x04 fragment represents the entire texture including all bitmaps that it 
uses, whereas an 0x03 fragment would represent only a single bitmap in the animated sequence. 
 
Fields 
 
Flags : DWORD 
 
Bit 3........ If 1, texture is animated (has more than one 0x03 reference). Also means that Timer exists. 
Bit 4........ If 1, Params2 exists. Seems to always be set. 
 
Size : DWORD 
 
Contains the number of 0x03 fragment references. It will only reference one 0x03 fragment for most textures but should 
reference more than one for animated textures (e.g. water). 
 
Params1 : DWORD 
 
Only exists if Flags bit 3 is set to 1. 
 
Timer : DWORD 
 
Contains the delay in milliseconds before changing textures in animated textures. Only exists if Flags bit 4 is set to 1. 
 
References: DWORDs 
 
One or more references to 0x03 fragments.

Here is the azone handling:

if(flags & (1 << 2))
    buf += 4;
  if(flags & (1 << 3))
    buf += 4;

They seem to be off by one byte. I have tested this and found that the animation bit is actually as it says, on the 3rd bit, not the second. Furthermore, I found that as bit 4 is set, params2 don't exist.

Here is my code:

    // If the texture is animated, mark it as so and read in the animation delay
    if(temp04.flags & (1 << 3))
    {
		bmpInfo[cur_tex04].animated = true;
		bmpInfo[cur_tex04].delay = *temp_p;
		
		// Move past the delay
		temp_p += sizeof(long);
    }
   else
   {
   bmpInfo[cur_tex04].animated = false;
   }

After that, the references to 0x03 bitmaps are read in and they work perfectly. I assume this bug, if I am indeed correct, is unnoticed because they are checking the wrong bit and don't deal with animation in azone. Due to being off by one byte, it ends up still be aligned.

Here are my revisions to the 0x04 fragment documentation.

0x04 — Texture Bitmap Info — PLAIN 
 
Notes 
 
This fragment represents an entire texture rather than merely a bitmap used by that texture. The conceptual difference from 
0x03 fragments is that textures may be animated; the 0x04 fragment represents the entire texture including all bitmaps that it 
uses, whereas an 0x03 fragment would represent only a single bitmap in the animated sequence. 
 
Fields 
 
Flags : DWORD 
 
Bit 3........ If 1, texture is animated (has more than one 0x03 reference). It also means that texture change delay exists. 
 
Size : DWORD 
 
Contains the number of 0x03 fragment references. It will only reference one 0x03 fragment for most textures but should 
reference more than one for animated textures (e.g. water). 
 
Delay : DWORD 
 
Contains the delay in milliseconds between the texture switch in animation. Only exists if Flags bit 3 is set to 1. 

References: DWORDs 
 
One or more references to 0x03 fragments.

Can any developers please confirm this?

Cheers!

[PixelEngineer]

Looks like I am the sole developer dealing with the old EverQuest zones

I am going to be writing up documentation for all of the fragments. Windcatcher did an amazing job and I see a few corrections and additions I can supplement the documentation with.

Cheers.