OpenZone 2.1

[Windcatcher]

1. Added code so the region splitter will determine an appropriate grid splitting value to try to keep the total number of regions low when a zone is exported to .WLD or .S3D.

2. Fixed several bugs in the scripting engine.

3. Fixed some bugs in the pipe and cylinder scripts.

4. Added scripts for cones and spiral staircases.

Hopefully this will fix the problems people were having with OpenZone 2.0.

WC


EDIT: According to SourceForge, no one has downloaded it yet, so I pulled it and replaced it with a version that fixes a nasty memory hole I found since. I just uploaded it at 8:20 PM EDT, so if SourceForge is lying to me and you downloaded 2.1, I suggest you re-download it in about an hour or so. By then it'll have made it to all the download mirrors.

[IANumtin]

I'll download and give it a run as soon as it's available. I'll let you know how it goes.

[Windcatcher]

Okay. One thing I want to mention is that I have some changes planned for the cone, cylinder, spiral staircase, and pipe scripts. Up till now they were positioned by their lower left corner, but I found that they're a *lot* easier to deal with if they're written so that their position is at the center instead. In the next version of OpenZone they'll be set that way, and if you have any of those objects in your zone you'll have to reposition them.

I found the major memory leak tonight, but there's still a memory leak somewhere else in the program that I haven't found yet. As you make changes in your .SCN file the program seems to consume more and more RAM, until you eventually run out and Windows starts complaining. Until I can find it I recommend saving often and restarting OpenZone when things start to slow down.

WC

[IANumtin]

Yeah, I figured that out to. I was running out of memory after a certain amount of time with Open Zone. Just tried your 2.1, I like it. It not only converted the arena.scn perfectly but it only took like 1/4 the time it normally takes. Don't know what you did but I like it. Great improvement on this one.

Are you still experimenting with the collision tree? Still showing a spawned dragon half buried.

[Windcatcher]

I'm pretty sure the collision tree only affects the player, not the mobs. I think the mobs spawn at your eye level.

One test you can try is to go to Permafrost and spawn Vox. Since it's an EQ zone the collision tree should be fine. If Vox also spawns in the floor then it's not an OpenZone problem.

WC

[IANumtin]

Actually, I've tried that. Only thing is, I tried it with the original arena.s3d file and it spawned fine. Then I loaded in my arena.s3d and it's in the ground. One thing that came to mind, is it possible that the old arena.s3d spawns ok because the "z" axis is closer to zero? I noticed with my version of arena.s3d the ground is actually up quite a bit more. Is there a way when creating the zone (when selecting the up/down on the size during creation) to possibly use a negative number so that your heightmap forms down instead of up from zero elevation on the z axis?

[Windcatcher]

Sure. In the bottom left, enter a negative number for the Z position. The center of the zone will then be at a negative number.

WC

EDIT: I did some expmeriments and the client is *definitely* reporting your loc based on your eye level. Try running around as a big race and a small race and looking at your /loc z coordinate to see what I mean. I then dug through the server code and it sets the mob's loc to equal your loc. To me this looks like a *big* mob like a dragon should always appear in the ground regardless of the zone. I'm unsure why it works in some zones and not in others.

I'm not familiar with the #spawn command or how to use it. Could you post a #spawn command that's giving you trouble so I could try it in various zones?

EDIT #2: Okay, I've been testing with various #spawn settings (client macros are indeed terrific) and the problem seems to be that mobs don't fall at all. If you go to West Commons and do #flymode 1, then go up into the air and #spawn a mob, it falls to the ground. This doesn't happen with OpenZone zones, however. I'm still trying to find the problem. I've found and fixed three other problems in the zone export code trying to track this one down, but I haven't gotten it yet. I'm looking at the problem right now, but no guarantees :)

[IANumtin]

One thing I've noticed is when I spawn a dragon in the EQ Arena, it spawn where it should meaning I have to look up to see its head. With Open Zone when I spawn it, it's in the ground and the head is eye level with me. Here's an example:

The EQ Arena supports the dragon model therefore it'll show up. If I was to go to say East Commons and try to spawn that same dragon (Commons obviously doesn't have that model supported) it'll appear as a human but will be about 50 feet above me and appear to be floating. When using your Open Zone East Commons, that same human will be on the ground at eye level.

Basically what I'm trying to say is something else is creating the factor to go along with the spawn besides just the z position of the player spawning the mob. That's where I THINK some of the other files for each particular zone come in. There's more than one .S3D file for each zone, not to mention the .CFG for it.

[Windcatcher]

I've almost got it. There's a section in the region references that I didn't understand, and I think I know what it does now. I was up most of the night deciphering it, and it looks like a run-length-encoded region list. I started playing with what I figured out and I can get the mobs to position themselves correctly--sometimes. My guess is that, for any given region, it's either a list of all regions above and below it or regions that region "touches" (or both). I'm on vacation this week, so I have lots of time to play with it.

WC

EDIT: Actually I'm revising my assessment of the list. I still think it's a region list, but I think it's merely a list of regions within a certain radius/cubic volume with the region in question at the center. This way the client can know if you're in the vicinity, and it can then reposition the mobs in the region. This list is expensive to produce from a CPU standpoint and would definitely be something that should be calculated in advance.