all is known about s3d format????

[Purcevil]

In a post by Windcatcher a while back he stated that everything is known about the s3d file format so its pointless to convert to wld etc etc

I've been trying to find a document on this, without success. That other places site seems to be down, dead, moved, ????? so I'm having a hard time looking there.

Does anyone have/know of documentation on the s3d format that they could point me to?

TIA,
Purcevil

[Purcevil]

Well, don't know what was up with that other site, but they are back again, and I got the "ariticle"...


Thanks

[Windcatcher]

That's right, OpenZone can export directly to .S3D, assuming that YOU USE ALL YOUR OWN TEXTURES. The main sticking point was the CRC/checksum algorithm, but this turned out to be merely the standard Ethernet algorithm that's been around for the last twenty years...

WC

[Purcevil]

8) I'm having a blast digging through the code! Thanks!

I also have a concept on the zone trading, if it works out that the devs don't come up with something better.

Seems the prevalent issue is doing everything WITHOUT touching the SOE EQ client. Understandable.

Instead of re-writing files with acceptable names why not have a rider program on the client machine that the server can tap on the shoulder and ask if its there. If so, all files can be renamed to tutorial.s3d ,as needed, having been pre-saved with the correct crc and then renamed back to what the designer intended after use. If the rider proggy isn't there, the server just says sorry that zone isn't accesible or whatever.

Yeah, its a bit more to download but it should be able to be set to a fixed port and get any other info necessary from the server the client is connected to. And it shouldn't be all that huge <shrug>.

???? Just a thought.
Purcevil

[Windcatcher]

That is a GREAT idea!

I did it one better. I wrote a program called ZoneProxy that players can run alongside their client. It listens on a socket port (port 8800 by default, but it's changeable in an .INI file) for one of the following messages (without the quotes):

"Ping" - if it sees this, it sends "Pong" back. Good for testing and checking to see if it's there.

"GetAliasZoneName" - The program will return the name of its alias zone, such as tutorial or cshome. By default it will use tutorial, but it's selectable in an .INI file. The reason for this command is below :)

"SetZone" - When the player wants to go to a third-party zone, the server should send "SetZone" and the zone name, separated by a carriage return or line feed (or both). ZoneProxy will open the .S3D files, change the .WLD names and CRC's appropriately so they reflect the alias zone, and write new .S3D files using the alias zone name. This means that, for instance, tutorial.s3d et. al. would be overwritten every time a third-party zone is accessed, so the originals should be backed up somewhere.

Possible responses to the server from a SetZone request:

"SettingZone" - When SetZone is sent, the server will immediately get "SettingZone" back, meaning that the file re-coding is taking place. In my experience it only takes a second or two, but just in case it takes longer the program performs the re-coding in a separate thread and prevents further SetZone requests in the meantime. If another SetZone request comes in during this time, the program sends SettingZone back to the server.

"DoneSettingZone" - When the re-coding is done, ZoneProxy sends this to the server to tell it that it's okay to send a zone packet to the client, one that tells it to go to the alias zone. I'm assuming that telling the client to go to a zone will always cause it to reload the zone. If this isn't true then we'll have to use two alias zones and ping-pong between them.

"CannotSetZone" - This means that the player doesn't have the needed zone files. The server should then norify the client that the zone is unavailable.

"NeedZoneName" - The server didn't supply the new zone name after the SetZone command. Remember that there must be a carriage return/linefeed/both between the command and the zone name.

"Error" - There was a problem when recoding the .S3D files. It could be from anything, like a sharing violation, lack of disk space, or some other problem.

If anything other than the three above commands are sent to the program, it sends "InvalidCommand" back to the server.

I've tested the socket code and it seems to work, but testing it with the server means that the server has to handle the above protocol and also has to know whether a zone is third-party or not. Modifying the server code to test this is beyond my capabilities. I think this will solve our problem with third-party zones, but is anyone able to put together a server that can utilize this? Right now I'm still using EQEmu 0.4.4 so this would be ideal for me.

WC

P.S. OpenZone 2.4 is coming SOON. It's basically done, but needs an instructions overhaul and possibly a tutorial. Then the next thing on my list is an updated version of the admin tool.

Edit: There were serious problems with the S3D code in OpenZone 2.3 and earlier. It created .S3D files okay but didn't read them properly. ZoneProxy and OpenZone 2.4 will have fixed versions.

[Purcevil]

That is SOOOO cool, WC.

Just one question cuz I'm obviously missing something.

Since any given client can only be in one zone at a time, wouldn't it be easier to pre-code the 3rd party zones with the correct CRC and internal file names for either cshome or tutorial as the case may be, use rename file commands when swapping zones out, and then rename file commands to put them back, than to actually rewrite the files every time they are loaded/unloaded?

for example

rename tutorial.s3d tutorial.ozback
rename mycoolzone.ozt tutorial.s3d
use and then finish with the zone
rename tutorial.s3d mycoolzone.ozt
rename tutorial.ozback tutorial.s3d

where the .ozt means openzone tutorial or .ozc would be openzone cshome so the side proggy knows which zone to use as a temporary without having to parse the file

Zoneproxy wouldn't have to be as smart, and you could make it so openzone authenticates its files before calling them usable. Once you have authenticated files from OpenZone you don't have to worry about them getting chopped up during use. Just a simple check for the renamed file existing or error. Okay, a lot of checking but less chance of fail during play.

Not sure the headaches that would cause you, but I thought it might save on processor overhead and zoning lag if it could be done that way.

As for coding it, I'm patched to live, so am using 0.5.0 DR5 and still barely treading water in that code (okay, I'm in the shallow end still). Hopefully I'll be able to step up soon.

Keep up the great work!
[Neither begging nor demanding, just tossing out ideas, that may or may not be helpful.]

[Windcatcher]

The reason I didn't want to go that route was in case the client forced us to use two alias zones instead of one (for instance, if telling it to zone to "tutorial" when already in that zone didn't do anything). That would then mean that players would have to have two copies of all the third-party zones, one coded for "tutorial" and one for "cshome", for example. That would make things messy for the people creating the zones as well as for the players. With this setup we only need one set of zone files and we have more flexibility (such as if SOE takes out the ability for the client to load the tutorial zone or if we're forced to change the name of the alias zone(s) for some reason).

The new S3D code doesn't automatically uncompress the file data, but only uncompresses it if a program requests a pointer to that data. That way, ZoneProxy can load the S3D file, rename the files, and write it out again, but skip the uncompress/recompress process. This makes re-coding happen very quickly.

WC

Edit: I just had an interesting idea. Since ZoneProxy can re-code *any* zone, I could set it up to back up the original alias zone and re-code it as ncessary. For instance, let's say that "tutorial" is the normal alias zone; the program could have "zoneproxy_orig" set as the designated backup zone name, and, when starting up, if that zone doesn't exist on the player's PC it could copy the tutorial zone over to tutorial_orig and re-code it. Then, if the player really wants to zone to the original tutorial zone (or the original version of whatever the alias zone is), ZoneProxy could grab zoneproxy_orig, re-code it back to tutorial, and tell the server that it's done. This would mean that the server would have to treat zoning to the alias zone the same as zoning to third-party zones, but would also mean that *any* zone could serve as the alias zone, not just unused ones. SOE could remove tutorial or cshome and it wouldn't matter.

Edit #2: Further thinking on this, in the case of backing up alias zones, re-coding isn't strictly necessary. ZoneProxy could simply copy the zone files to a different name. This might be desirable since the player could then always manually restore the files in the event of a problem. The server should never know about the backup names, but should simply give ZoneProxy a "SetZone" command with the alias zone name (e.g. tutorial) as the argument. ZoneProxy could check the zone name against it's alias zone name, and if it matches could simply copy the backups over without re-coding them.

[Purcevil]

Ahhhhhh, thanks.

I was under the impression that the client unloaded the zone you were in as soon as you hit the zone point and then loaded the new one while you stared at the last image in memory for a while. But, I guess if you zone from tutorial to tutorial you would get a bounce message or something. And having multiple copies of every 3rd party zone WOULD be a bit of a waste.

Neat idea using any zone and a manual restore option. BSOD or locks seem to strike a lot of people (ie windows users) and they might be a bit peeved at loosing a zone, even if it were just tutorial. And how the heck could you legally get them a new copy without going through the patch process (which might not be a desirable option to them).

[Windcatcher]

I don't know if the client will let us use only one alias zone or if we'll need to ping-pong among more than one. I'm at the point where I need a server that takes advantage of what ZoneProxy does now to find out.

Edit: I changed ZoneProxy to automatically back up the alias zone if it hasn't been done yet and restore the backup if the server tells it to set up the alias zone (e.g. "SetZone\ntutorial"). The backup is merely a copy, not a zone that has been re-coded. That way the user can restore it in the event of a problem. Theoretically any zone can be used as the alias zone, not just unused ones. Users can also theoretically have different alias zones, so the server will have to store the alias zone name whenever a user connects and the server queries that client's ZoneProxy port.

[steve]

Another junk zone that the client accepts is arttest or "Art Testing Domain".

This would be the perfect zone to use alongside tutorial.

[Windcatcher]

I've built a ZIP file containing ZoneProxy 1.0 and sources for testing. If I upload it, is anyone interested in building a server to match?

[Windcatcher]

WOO HOO! It works!!

I knew I bought that copy of Visual C++ 6 for *something*. It took a lot of doing, but I've got EQEmu 0.4.4 compiling, and I have it (mostly) working with ZoneProxy. The #zone command has some bugs regarding zoning to and from the real alias zone (e.g. tutorial), but otherwise everything is working pretty well. I can't wait to see what this turns into once it's been refined.

Only one alias zone is necessary, but the trick is to run ZoneProxy *before* running the client. ZoneProxy has to open the alias zone files for writing before the client can touch them, or you get sharing violations out the wazoo. Once I figured that out, things started running relatively smoothly. You can even zone from a third-party zone to another one, and the client reloads the alias zone perfectly.

What I have can't possibly be the best way to do this. It's only what I've gotten to work and I'm rapidly reaching the point where I could use some help refining this into something more robust. Any takers?

WC

[Purcevil]

Outstanding!

WTG WC

Can't wait to see it in action.

Sure wish I could help out, tho.

[Windcatcher]

Okay. I've gotten it to the point where it's working really well. The #zone bug is fixed and I'm happy with its operation. That's not to say that there aren't bugs lurking in there, but I'm satisfied so far :)

I just finished typing the instructions for ZoneProxy and I'm ready to package it and post it on the SourceForge download site. I need about an hour or less to go over my modified EQEmu 0.4.4 source to make sure everything's ok, but otherwise that's essentially ready to go public too. The one thing you have to do is add an integer column called "thirdparty" to the "zone" table. Populate it with 1 for third-party zones and 0 for all other zones (including the alias zone, which is set by the player). Does anyone have a suggestion as to where I could put the EQEmu archive?

WC

[Purcevil]

Wow, lots of great stuff. =)

Thanks WC.

I grabbed everything for review later (if I ever actually finish school... which was supposed to be done with last week, but was delayed due to foul weather and fools... and get to working).

I have a question if you can PM me that I don't want to discuss on the board.

However, it may be moot since they've released 5.0 now. <shrug>