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.