Windcatcher
01-31-2004, 04:26 PM
I have good news and bad news...
The good news is I know how to make ambient sound files for OpenZone zones. Not music, like the music in Kelethin, but sounds like wind, fire, birds, etc. The sounds are defined in the <zone>_sndbnk.eff and <zone>_sounds.eff files. I don't know how to do everything that they support, but I have some things working. I also have OpenZone about 90% of the way there in terns of defining sounds and exporting the .EFF files along with the .S3D files. You'll be able to point it to your EQ folder, add sound areas in the ground editor, and even listen to them to find the one you want.
Now for the bad news...
Simply put, the client caches the sound files. Once it loads the .EFF files for a given zone they stay loaded until you quit the client. If you zone out and zone back again the file is NOT reloaded. Even camping out and in again doesn't work. This means that the sound file for the first third-party zone you enter will remain active for all other third-party zones. :(
My solution...
The only way I see around this is going to require a new OpenZone, Admin Tool, and ZoneProxy. The OpenZone work is 90% done, the Admin Tool work is 100% done, but I haven't started the ZoneProxy work yet. Simply put, what has to be done is: the sounds for all third-party zones will have to be loaded all at once, and in such a way that they don't interfere. The only way to do this is to have every third-party zone for a server reside at coordinates where THEY won't interfere.
For instance, the real tutorial zone lives at its usual coordinates, so that's out. Let's say I take my "windszone" zone and shift EVERYTHING by 50000 in the x direction. Then I do the same thing for everything in the database that refers to it. Then I take my next third-party zone "zone1" and shift it by -50000 in the x direction. Even if the sounds for all three zones are simultaneously loaded, they won't interfere. This is the idea. I've tested zones in-game at ridculous coordinates (+200,000 in x and y directions) and it works fine. A year ago this would have never worked, but now that the client uses longs for everything it's ok.
OpenZone and the Admin Tool will have the ability to perform this shift. OpenZone 3.4 can shift everything in the zone by arbitrary x, y, and z values (though there is an internal limit of 10,000,000 I believe) and the Admin Tool will be capable of similarly shifting everything in the database that affects a particular zone (you can always shift back by shifting by the negative of what you shifted by).
Here's how I see this working:
1. Make your zone with OpenZone exactly as you do now. Build it, test it ingame, whatever.
2. Once your zone is done and ready to be populated, load the zone in OpenZone, shift it, and export it. You can save it if you wish but it isn't necessary. One possibility is to save it as a different name. After you've shifted the zone, you should then generate the .MAP file so it corresponds to the both zone geometry and where the spawns will go.
3. Enter spawns in the DB as normal, but the coordinates have to correspond to the shifted coordinates (so if you shifted by x=50000 then enter spawns in that neighborhood). Basically it works the same as normal since ingame you'll also be walking around in the new coordinates -- to the server there's no difference whatsoever. The only extra thing you'll have to do is set the safe point, since 0,0,0 won't be a good place to be...
The only reason for adding the shift capability to the Admin Tool is if you have zones already built and populated (like me). The Admin Tool can shift an already populated zone in one go. For zones not yet populated you should never have to use it. The tables it looks at are:
spawn2
grid
ground_spawns
zone
zone_points
player_corpses
doors
start_zones
object
I wanted to do zonepoints_raw also but I don't understand the format.
Regarding ZoneProxy, the change will be relatively minor. It will need to have a text file listing all third-party zones. When it starts up, it will immediately and intelligently build a single pair of sound files from the alias (e.g. tutorial) and third-party zones so that everything is available when the client starts up. As usual it will restore the backed-up alias zone files when it is closed.
Of course, if you don't care about sounds in the zone, then ignore this entire post, but I'd really like to hear opinions about all this from anyone interested.
Wind
The good news is I know how to make ambient sound files for OpenZone zones. Not music, like the music in Kelethin, but sounds like wind, fire, birds, etc. The sounds are defined in the <zone>_sndbnk.eff and <zone>_sounds.eff files. I don't know how to do everything that they support, but I have some things working. I also have OpenZone about 90% of the way there in terns of defining sounds and exporting the .EFF files along with the .S3D files. You'll be able to point it to your EQ folder, add sound areas in the ground editor, and even listen to them to find the one you want.
Now for the bad news...
Simply put, the client caches the sound files. Once it loads the .EFF files for a given zone they stay loaded until you quit the client. If you zone out and zone back again the file is NOT reloaded. Even camping out and in again doesn't work. This means that the sound file for the first third-party zone you enter will remain active for all other third-party zones. :(
My solution...
The only way I see around this is going to require a new OpenZone, Admin Tool, and ZoneProxy. The OpenZone work is 90% done, the Admin Tool work is 100% done, but I haven't started the ZoneProxy work yet. Simply put, what has to be done is: the sounds for all third-party zones will have to be loaded all at once, and in such a way that they don't interfere. The only way to do this is to have every third-party zone for a server reside at coordinates where THEY won't interfere.
For instance, the real tutorial zone lives at its usual coordinates, so that's out. Let's say I take my "windszone" zone and shift EVERYTHING by 50000 in the x direction. Then I do the same thing for everything in the database that refers to it. Then I take my next third-party zone "zone1" and shift it by -50000 in the x direction. Even if the sounds for all three zones are simultaneously loaded, they won't interfere. This is the idea. I've tested zones in-game at ridculous coordinates (+200,000 in x and y directions) and it works fine. A year ago this would have never worked, but now that the client uses longs for everything it's ok.
OpenZone and the Admin Tool will have the ability to perform this shift. OpenZone 3.4 can shift everything in the zone by arbitrary x, y, and z values (though there is an internal limit of 10,000,000 I believe) and the Admin Tool will be capable of similarly shifting everything in the database that affects a particular zone (you can always shift back by shifting by the negative of what you shifted by).
Here's how I see this working:
1. Make your zone with OpenZone exactly as you do now. Build it, test it ingame, whatever.
2. Once your zone is done and ready to be populated, load the zone in OpenZone, shift it, and export it. You can save it if you wish but it isn't necessary. One possibility is to save it as a different name. After you've shifted the zone, you should then generate the .MAP file so it corresponds to the both zone geometry and where the spawns will go.
3. Enter spawns in the DB as normal, but the coordinates have to correspond to the shifted coordinates (so if you shifted by x=50000 then enter spawns in that neighborhood). Basically it works the same as normal since ingame you'll also be walking around in the new coordinates -- to the server there's no difference whatsoever. The only extra thing you'll have to do is set the safe point, since 0,0,0 won't be a good place to be...
The only reason for adding the shift capability to the Admin Tool is if you have zones already built and populated (like me). The Admin Tool can shift an already populated zone in one go. For zones not yet populated you should never have to use it. The tables it looks at are:
spawn2
grid
ground_spawns
zone
zone_points
player_corpses
doors
start_zones
object
I wanted to do zonepoints_raw also but I don't understand the format.
Regarding ZoneProxy, the change will be relatively minor. It will need to have a text file listing all third-party zones. When it starts up, it will immediately and intelligently build a single pair of sound files from the alias (e.g. tutorial) and third-party zones so that everything is available when the client starts up. As usual it will restore the backed-up alias zone files when it is closed.
Of course, if you don't care about sounds in the zone, then ignore this entire post, but I'd really like to hear opinions about all this from anyone interested.
Wind