ZoneProxy-friendly changes to 0.5.3DR2
 

I've updated my copy of EQEmu 0.5.1 to make it work with ZoneProxy (and hence OpenZone zones), and it is tested and working (except for the GM #goto command in third-party zones; using it forces the client to reload the zone--I don't know why). I then made the same changes to 0.5.3DR2. It compiles, but I'm not equipped to test it on my setup (the code is exactly the same where the changes were made and I'm highly confident that it will work).

I've built a small ZIP file with the changed 0.5.3DR2 source code files, but I'm reluctant to put this in the Admin Tool download area. I'd really like for someone to get this into the server CVS repository so the server will be ZoneProxy compatible from here on out. It is *not* necessary that clients connecting to such a server have ZoneProxy. If a client doesn't have ZoneProxy running, the server tells the client that the third-party zone is unavailable. If a client wants to use third-party zones, they must have ZoneProxy running *before* starting the EQ client (see the ZoneProxy instructions for a full explanation).

ZoneProxy compatibility requires a small change to the database so the server knows which zones are third-party and which aren't:

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

Basically, set the thirdparty field to zero (0) for all zones that come from SOE and one (1) for all zones created with OpenZone. Regarding the zone ID, I recommend starting with numbers that definitely won't interfere with any potential SOE zone IDs (I started with 800). DO NOT USE 999.

My changes to the server code use zone ID 999 under certain circumstances to force a zone reload. At some point this might have to be changed to 9999 to make absolutely sure there is no conflict, but I seriously doubt it will ever be necessary.

And he quietly keeps churning out the good stuff!

hmmm
 

where is this wonderfull change ? is it on sourceforge?

I can put it there if people wish...the question is, would a dev please try this out and put it in CVS if it works? I'm not interested in having to do this for every EQEmu release that comes out in the future...

WC

P.S. OpenZone 2.6 is IMMINENT. Here's the $64,000 question: release it now, or try to make animated meshes working first (flags, trees, etc. -- not creatures). I know how animated meshes work in .WLD files, but OpenZone doesn't have that capability yet.

WC, I'll take a look at it as soon as we can. It will probably be a couple of weeks though.

Okay, I'll upload the EQEmu changes soon (tonight). Regarding animated meshes in OpenZone, I started laying the groundwork and realized that it'll take a lot of work and experimentation to get it completed, so I'll save that for the next version. In the meantime I'm taking a stab at dungeon creation with some dungeon-specific scripts.

WC, I was wondering if you'd be able to take the time to document WLD a bit, or come on IRC so we can discuss it and I'll write it, my nick on IRC is Daeken if you want to get in touch with me via that method :)

Cheers,
Daeken

I just uploaded the my source files to 0.5.3DR2 that have to be changed to make it compatible with ZoneProxy. You can get it at:

http://prdownloads.sourceforge.net/e...e.zip?download

I've been considering documenting what I know about .WLD files for a long time. It's definitely an overdue project, but I simply haven't had the time for it yet.

There are two major issues when dealing with .WLD files: the file format itself (that is, the overall file organization, including dealing with string locations, etc.) and fragment definitions. Documenting the fragment types will consume 99% of the document and is the most important part.

A .WLD file contains what are called "fragments" (that's what the original ZoneConverter source calls them--I have no idea who wrote it). A fragment is basically just a data structure, and there are two overall types:

- standalone fragments
- fragments that have a built-in reference to another fragment (such a fragment is a superset of a standalone fragment)

Fragments that reference other fragments are something like nodes in a linked list: they contain information that's related to another fragment, such that the client will want to be able to walk from one fragment to another. An example is animated meshes: there is a fragment that details basic mesh information, but if that mesh is animated it will contain a reference to another fragment that contains the additional animation stuff (actually there is a "glue" fragment that sits in the middle, kind of like an animation reference fragment--these "glue" fragments let data that takes a lot of memory be reused). Fragments can contain multiple such references, but the FragmentReference flavor always gives you one for free. Any others are specific to a fragment type.

Every fragment, whether standalone or otherwise, contains an ID value that tells the client its type. The highest ID I've seen to date is 0x37. That's not to say I've encountered every ID between 0 and 0x37, but there are a lot of different kinds of fragments. I've figured out most of the ones I've seen, though some are still a mystery. Others are only partially understood.

Windcatcher, as I recall you don't do any C programming do you? :/ I was hoping your knowledge could fix kaiyodo's model viewer to display character models corectly. I havn't seen kaiyodo around for quite a long time, but the web page with source and exe's is still up. I figure a proper model viewer could seriously help the GenRaTex project figure out what models/textures are avaliable in each zone.

I continuously upgrade DZoneConverter to help decipher .WLD files, and I took a stab at chatacter models too. So far I haven't been able to figure it out. There's something about the Data6 and Data9 areas in the Data36 fragment that relates to character models, but I don't understand it yet.

Speaking of chracter models, it occured to me the other day that there are names for all the models in the s3d files... if that's true, and if the names are contained in some kind of index that is easy to find, and if we could get a correlation between model names and race/model numbers....

Wouldn't it be possible to get the available race/models for NPCs by reading the s3d files for a zone, matching model names to race/model numbers (possibly with a table) and therefore identifying all races/models available for a given zone?

Just a thought.

I started porting zoneconvertor's eqwlddata and fragment code to php, commenting, and documenting the wld format... i'll probably whip up some c structs for everything and release it in increments today :)

Cheers,
Daeken

The original ZoneConverter source had some bugs in that code. I suggest you look at my Delphi port of it in the OpenZone source as an update.

I understand the fragment structures and such now, but I don't actually understand the purpose of some... mind clueing me in on the use of the different types?

Cheers,
Daeken

That's kind of a broad question. Which ones don't you understand?