OpenZone 4.0

Windcatcher · #1 07-03-2004, 01:55 PM

This is a simple bugfix version. I've been working on the .3DS code for the past few days, and 4.0 does a much better job of importing .3DS files. I plan on making other improvements to it in the near future (such as importing texture coordinates, which it still doesn't do -- it calculates them on the fly), but this should at least get people going who are trying to import .3DS files. I've tested it with .3DS files that reference multiple textures and it's been a-ok.

I'm working on another program called Dungeon Builder that is specifcally for making dungeon zones. It will probably be a few months before it's fully ready, but the basic functionality is done and I'm able to make and export zones with it. It exports zones as .3DS files which can then be imported with OpenZone. It needs a lot more refinement before it will be ready for release and I'll probably have to make more improvements to OpenZone, but with this it's *dead easy* to build dungeon zones. It uses a three-quarter isometric view, and you build zones by dropping in corridors and rooms and dragging their handles until they snap together. There are different kinds of handles for doing different kinds of modifications, like endpoint handles and wall handles. There's a ton more to do, but most of the really hard stuff is done already (thanks to code from OpenZone). Its native file format is pure XML and, since it exports zones as .3DS, it's not specificaly tied to EQ and should be usable for other games.

WC

daeken_bb · #2 07-03-2004, 07:06 PM

Well, you've been pushing for an opensource EQ client for a while, and now there is one. The start of one at least. Me, Doodman, Farce, GXTi, and others (Xiao has been our resident cheerleader, and his non-code contributions have been appreciated) have been working on a new client. We have zone rendering working (only certain parts of the zone render, e.g. all of kelethin in gfaydark, but not the rest) and have been working on the network backend of it.

Your WLD documentation has been invaluable, but there are some problems with it (namely you have centerx/y/z labeled as DWORD's, when they're floats) that I'd like to help resolve, and there are some things I'm not clear on (placeable objects in zones being the primary one)

If you'd like to see the current version (in Python for a prototype, and being ported to C now) check out http://archshadow.com/eqclient_old/ (and http://archshadow.com/eqclient/ for the C version) for screenshots and source.

Thanks for all your help so far.

Lord Daeken M. BlackBlade
(Cody Brocious)

P.S. Try to drop by #eqclient on irc.eqemulator.net if you have a chance

KhaN · #3 07-03-2004, 10:53 PM

Quote:

(placeable objects in zones being the primary one)

From my experience with openzone, i dont think that OZ use EQ Object format, the object with OZ are just MSH library and when you import them into a zone, objects are added to zone mesh but arent considered like an object.

And would love to be here too when WC will pop in IRC~

Windcatcher · #4 07-04-2004, 04:51 AM

While OpenZone uses the MSH file format when you're using it, when you export a zone to .S3D it converts any MSH objects you've placed to .WLD. Let me see if I can calrify things a bit.

Objects are *defined* in the <zone>_obj.s3d archives, in <zone>_obj.wld. A typical object definition consists of the following fragments:

- For every texture, there will be a 0x03, 0x04, 0x05, and 0x30 fragment. If the same texture is used in multiple objects I don't know if there will be duplicate entries or not, but you should assume that there won't (shouldn't be a problem anyway).

- There will then be a 0x31 fragment that tallies all of the textures together for that object.

- Then a 0x36 fragment that defines the object's polygons.

- Then a 0x2D and 0x14 fragment. I'm not sure of their purpose.

It's possible that you could see other fragments as well, such as possibly a 0x37 fragment for flags that flap in the wind.

Objects are *placed* in the <zone>.s3d archive, in objects.wld. This file is very simple. For each object, you should see a 0x32, 0x33, and 0x15 fragment. The 0x32 defines any lighting that is to be applied to the object (e.g. if it sits in torchlight). The 0x33 is the reference fragment to the 0x32 and the 0x15 contains the placement and orientation info.

I agree that there are some problems with the documentation. We'll have to agree on some way to work the problems with it out and get it updated. If you have any problems, the file EQWldData.pas in the OpenZone source should help. It should be more current than the documentation.

WC

daeken_bb · #5 07-04-2004, 05:01 AM

Thank you for that info. Perhaps when the EQclient site is put up, we will set up a wiki where we can work on the WLD docs and such. I just finished the WLD reader in the C version of EQclient, so I hope to have meshes rendering today... possibly even placeable objects if I have the time

Thanks again.

Lord Daeken M. BlackBlade
(Cody Brocious)

sianyde · #6 07-05-2004, 11:21 AM

Quote:

Originally Posted by daeken_bb

Well, you've been pushing for an opensource EQ client for a while, and now there is one. The start of one at least.

Do you think it's possible (or has it already been done) to create a version of the client that doesn't display the graphics or load the zones?

I don't have nearly as much time as I used to, and can't keep pace with a good core group on EQLive. So, I multibox in my slowly evolving custom EQEmu world with EQW and MQ. It would be great to have stripped down clients for the script controlled characters. (of course, that would require altering MQ, but that' s another story).

daeken_bb · #7 07-05-2004, 02:28 PM

If you interface with our network base, sure.

Shadow-Wolf · #8 07-06-2004, 10:28 AM

hmm when i try to compile i get an error about sdl.h where can i get it?

daeken_bb · #9 07-06-2004, 10:38 AM

http://libsdl.org/ should have everything you need. Be warned however that the version on the site is prone to crashing, requires texcache files output by the python version (until we have DDS and BMP support coded into the C version) and is generally just pretty nasty.

For instance, here's a shot of Kelethin using the experimental texture code i've been working on: http://archshadow.com/eqclient/kelethin_alien.jpg

Happy Hacking,
Lord Daeken M. BlackBlade
(Cody Brocious)

sandy · #10 07-07-2004, 04:56 AM

I don't understand well textures

you said :

Quote:

For every texture, there will be a 0x03, 0x04, 0x05, and 0x30 fragment

ok but in 0x04, it is said there is n 0x03 fragments
and in 0x03, it is said there is m filenames ...

so if 0x03 is :

0x03->filename1->filename2->filename3->filename4

i understand it is the animated texture names

but if 0x04 is :

0x04->0x03(1)->0x03(2)->0x03(3)->0x03(4)

what does this list correspond to ??? i don't understand

Windcatcher · #11 07-07-2004, 06:57 AM

Each 0x03 fragment refers to one and only one texture bitmap filename. Each 0x04 fragment can refer to more than one 0x03 fragment. So for water textures, for example, there will be four 0x03 fragments where each one refers to one texture bitmap, and there will be one 0x04 fragment that refers to all four 0x03 fragments.

An 0x03 fragment refers to an individual texture bitmap.

An 0x04 fragment represents an entire texture that a polygon may reference, whether it is a static texture (only one texture bitmap) or animated texture (more than one texture bitmap).

WC