ZoneProxy-friendly changes to 0.5.3DR2

[daeken_bb]

Most of them, unfortunately. I haven't found much of a description of what each fragment is used for, e.g. which fragment is for animated meshes, which is for static objects, etc.

Perhaps you could point me to a file in your source?

Cheers,
Daeken

[Windcatcher]

EQWldData.pas in the OpenZone source is a direct translation of the corresponding ZoneConverter file, but also has bug fixes and improvements.

Here's a rundown of the fragment types as I understand them and some basic documentation below:

0x03 - Texture Bitmap Name(s)
0x04 - Texture Bitmap Info
0x05 - Texture Bitmap Info Reference
0x08 - Camera
0x09 - Camera Reference
0x10 - Track Set
0x11 - Track Set Reference
0x12 - Mob Track/Object Track
0x13 - Mob Track Reference/Object Track Reference
0x14 - Placeable Reference/Player Info
0x15 - Object Location
0x16 - Zone Unknown
0x17 - Polygon Animation?
0x18 - Polygon Animation Reference?
0x1B - Light Source
0x1C - Light Source Reference
0x21 - BSP Tree
0x22 - BSP Region
0x28 - Light Info
0x29 - Region Flag
0x2A - Ambient Light
0x2D - Mesh Reference
0x2F - Mesh Animated Vertices Reference
0x30 - Texture
0x31 - Texture List
0x32 - Vertex Color
0x33 - Vertex Color Reference
0x35 - First Fragment
0x36 - Mesh
0x37 - Mesh Animated Vertices

There are other fragment types in the ZoneConverter source, but I haven't encountered them. Here I talk about all of the ones I've seen.



Misc
----

0x35 - First Fragment - For some reason every .WLD file I've ever encountered begins with one of these. I have no idea why or whether this is necessary.

Textures
--------

0x03 - Texture Bitmap Name(s) - Contains the names of one or more bitmaps used in a particular texture. When there is more than one bitmap in the fragment it means that the texture is animated (e.g. water).

0x04 - Texture Bitmap Info - Refers to a 0x03 fragment. Also contains flags to tell the client information about this particular texture (normal or animated).

0x05 - Texture Bitmap Info Reference - Refers to a 0x04 fragment so 0x04 fragments can be reused.

0x30 - Texture - Refers to a 0x05 fragment. Contains flags to tell the client information about this texture (normal, semitransparent, transparent, masked, etc.) Having this fragment separated from the 0x05 fragment means that the zone can have multiple flavors of the same texture bitmap (e.g. one that is normal, one that is semitransparent, etc.)

0x31 - Texture List - Contains references to all of the 0x30 textures used in the zone (or, in the case of placeable objects, in that particular object).


Meshes
------

0x36 - Mesh - Contains vertex, normal, color, and polygon information for a mesh. In the case of zones, the mesh is a subdivision of the zone. In the case of placeable objects, the mesh contains the entire information for the object.

Notes on 0x36 fragment:

1. Fragment1 refers to a 0x31 fragment to tell the client what textures are used.
2. Polygons are sorted by texture index. That is, all polygons in the Data5 area that use a particular texture are grouped together.
3. Fragment2 optionally refers to a 0x2F fragment if the mesh is animated (e.g. trees or flags that sway in the breeze).
4. Fragment4 always refers to the first 0x03 fragment in the file (I have no idea why).
5. I don't fully understand this fragment. The Data6 and Data9 areas have something to do with mob models, but I don't know how they work yet.
6. There are new-format and old-format .WLD files. They have different values in the .WLD header and the main difference is in the 0x36 fragment. In new-format files, the texture coordinate values are signed 32-bit values; in old-format files they're signed 16-bit values. At this time OpenZone only exports old-format files but it would be no great effort to switch it to new-format files.

0x37 - Mesh Animated Vertices - For a given 0x36 fragment, this fragment contains a number of animation "frames". For each frame it contains a complete vertex list that supercedes the vertex list in the 0x36 fragment. For instance, if there are three frames and 15 vertices, there will be three sets of 15 vertex values in the 0x37 fragment and they will be used in lieu of the 15 vertex values in the 0x36 fragment.

0x2F - Mesh Animated Vertices Reference - Refers to a 0x37 fragment so it can be reused (e.g. for flags that all have the same shape but have different textures).


Zones
-----

0x21 - BSP Tree - BSP stands for "binary space partition". Basically the zone is broken up into regions so the client can quickly find polygons that are near the player or mobs for purposes of collision avoidance. Normally this is done along a simple grid, but the zone also has to be broken up so that "special" regions (water, lava, PvP, ambient lighting, and others) are distinct.

0x22 - BSP Region - For each node in the BSP tree there is a 0x22 fragment that describes the region. It contains information on the region's bounds and an optional reference to a 0x36 fragment if there are polygons in that region. Also contains an RLE-encoded array of data that tells the client which regions are "nearby". That way, if a player enters one of the "nearby" regions, the client knows that objects in the region are visible to the player. The client does this to know when it has to make sure mobs fall to the ground instead of stay at the spawn points, which might be in midair.

0x1B - Light Source - I suspect this defines the ambient light level in a zone (see "Light sources" below for info).

0x08 - Camera - I don't know what the parameters mean yet.

0x1C - Light Source Reference - See "Light sources" below for info.

0x2A - Ambient Light - Refers to a 0x1C fragment. Contains a list of numbers that refer to the 0x22 fragments in the zone (e.g. if there are 100 0x22 fragments then the numbers will be in the range 0-99). This fragment tells the client which regions have the particular light setting. I suspect that you could conceivably have some regions with one ambient light setting, other regions with another ambient light setting, etc. by having multiple 0x1B-0x1C-0x2A sets.

0x09 - Camera Reference - Refers to a 0x08 fragment. I don't know its purpose.

0x14 - Player Info - I don't know its purpose. Its Fragment1 value seems to use a "magic" string: "FLYCAMCALLBACK".

0x16 - Zone Unknown - It's used in zone files for some reason...

0x15 - Object Location - In zone files, this might contain the safe point?

0x29 - Region Flag - This is similar to the 0x2A fragment in that it contains a list of numbers, where each number refers to a 0x22 region. It tells the client that those regions are "special". The name of the fragment is "magic" in that it determines how the regions are flagged:

"WT_ZONE" .................... Regions are underwater

"LA_ZONE" ................... Regions are lava

"DRP_ZONE" ................... Regions are PvP areas

"DRNTP##########_ZONE" ....... e.g. DRNTP00025-02698-645.6-00020999_ZONE. This seems to tell the client that these regions constitute a zoneline. If the player enters one of these regions the client knows the player is zoning and knows the destination. I don't know if the client makes use of this since I don't think every zone has this at all zone points, but it looks interesting. I don't understand the format of the numbered part of the name.


Mob models
----------

0x12 - Mob Track - I don't know what this does, but I suspect it has to do with mob animation.

0x13 - Mob Track Reference - Refers to a 0x12 fragment.

0x2D - Mesh Reference - Refers to a 0x36 fragment. I don't know its purpose.


Light sources
-------------
0x1B - Light Source - Contains information on light color. I don't know what the other parameters in it mean.

0x1C - Light Source Reference - Refers to a 0x1B fragment.

0x28 - Light Info - Refers to a 0x1C fragment. Contains light position and radius. I don't know what the other parameters mean.


Placeable objects
-----------------
0x32 - Vertex Color - For each object that has been placed, there is one of these (put 100 trees in your zone and there are 100 of these fragments). It contains vertex shading information for each object. For example, if you have a torch near some trees, those trees should have their polygons shaded based on the light color, angle of incidence, distance, and any intervening polygons. The EQ client does *not* dyamically shade polygons in a zone; all polygons must be shaded in this way (including 0x36 fragments in the main zone file).

0x33 - Vertex Color Reference - Refers to a 0x32 fragment.

0x15 - Object Location - Contains object position, rotation, and size. Refers to a 0x33 fragment. When used in the main zone file, this fragment contains information for the whole zone (see frmMainUnit.pas in the OpenZone source).

0x17 - Polygon Animation? - I don't know what this does. I suspect it has something to do with polygon animation.

0x18 - Polygon Animation Reference? - Refers to a 0x17 fragment. I don't know its purpose.

0x2D - Mesh Reference - Refers to the 0x36 fragment.

0x12 - Object Track - I don't know what this does, but I suspect it has to do with object animation.

0x13 - Object Track Reference - Refers to a 0x12 fragment.

0x10 - Track Set - This seems to be optional for placeable objects. My guess is that it allows a placeable object to have more than one animation track. For each track that is used there is a reference to a 0x13 fragment. There might (though not necessarily) also be a reference to a 0x2D fragment for each track.

0x11 - Track Set Reference - Refers to a 0x10 fragment.

0x14 - Placeable Reference - Fragment1 contains a "magic" string: "SPRITECALLBACK". Data2 contains at least one fragment reference that refers to either a 0x2D or 0x11 fragment. I don't understand what all the parameters in this fragment mean.




There is much more to .WLD files than this, and this document doesn't contain anything on the file header and it's overall organization. Also, many fragments contain flags that have to be set properly for the zone to work (e.g. whether a 0x22 fragment refers to a 0x36 fragment). See frmMainUnit.pas in the OpenZone source to see how I create fragments when exporting zone files. My fragment variables typically start with "D"; that is, D36 for a 0x36 fragment, D21 for a 0x21 fragment, etc. By searching for something like "D36." you can see how I set the fields in a 0x36 fragment, for example. Over time we can possibly grow this to become a more comprehensive reference.

[daeken_bb]

Wow. Thanks a ton, perhaps I can do some fun stuff with WLD files now

[Windcatcher]

I found a problem in my description of the 0x18 fragment. Camera is actually 0x08, and 0x09 refers to that. I've since updated my notes above.

[Lurker_005]

I remember some referances to some zones "Knowing" where to zone to without EQEmu telling it... I'm sure the "DRNTP##########_ZONE" data includes zoneline_id zone_id, X,Y,Z destinations, and rotation A 999 means to keep the current zone out value. With a little cross referancing to the zoneline table, and experimenting in game that little tidbit should be deciferable.

The rest is greek to me

[Windcatcher]

I'm in the process of building a comprehensive reference. I just finished documenting all of the fragments described above, including fields, flag values, etc. So far the reference is a 23-page Word document...

WC

[Kroeg]

Windcatcher... I'm addicted to openzone.. I love that tool
My question, though, in order to test the third party zones (zoneproxy is required).. but so is the additional code. I'm using one of the various dr2 builds that is relatively recent.. what build was this code addition for? Would it be too much of a pain in the ass to post a possible snippet for later versions?

I'm assuming I MUST use zoneproxy to test a third party zone, in asking this

[Windcatcher]

I can't find the thread that had the source .ZIP file anymore. Perhaps it got wiped. My 0.5.3DR2 changes are identical to changes I had to make to the 0.5.1 source and I suspect that any build you use should be similar. All of my changes are bracketed by the following comments:

// ZONEPROXY BEGIN
.
.
.
// ZONEPROXY END

There aren't all that many of them; you shouldn't have too much trouble adding them to just about any build...

WC

P.S. Please let me know if you get it working...

[Kroeg]

Thanks, I'm working on it. So far, I've created a sample zone with one building in it and a minimal heightmap. I then exported it as "infernal1", and it saved all 3 files for my zone. I then copy these over to the zoneproxy folder, set the zonealias for "tutorial" ... load eq, attempt to #zone tutorial and 1 of 2 things happen: 1) eq client crashes 2) I zone to the normal tutorial zone (not infernal1)

Perhaps I'm just an idiot and am not taking my time to get it working right, but is there something specific im doing wrong?

[Trumpcard]

WC. I'll try to merge this in to the baseline this week so it doesnt get lost. I may put it in an ifdef section if you dont mind.

[Windcatcher]

Don't zone to "tutorial". Here's what you need to do:

1. In your zone table in the DB, create an entry for infernal1.

2. Add an integer column to the zone table called "thirdparty":

alter table zone add thirdparty int(2) unsigned default '0';

3. Set thirdparty to 1 for your new zone.

4. Log into the client and #zone to infernal1. The server will tell ZP to set up "infernal1". ZP will copy and re-code the files so they look like tutorial to the client. ZP will then tell the server when it's done and the server will tell the client to zone to "tutorial". It's all transparent.

WC