OpenZone and .map files for eqemu

[Shadow-Wolf]

If im remembering correctly you shouldn't of had to do that that at all, I think OpenZone can export its own .map files.

[Windcatcher]

This is an unfortunate consequence of two projects using the same extension for different files. The .MAP files that OpenZone currently exports are for use with the Admin Tool (and ShowEQ, though why anyone would want to do that is beyond me). Those .MAP files are intended to let you see an overhead graphical map of the zone so you can more easily place spawns when using the Admin Tool.

The .MAP files being discussed in this thread are for use by the server and have to do with LOS (line-of-sight) calculations. OpenZone doesn't currently export those.

I've decided to bite the bullet and try to add EQEmu .MAP file support (the LOS kind). When you export to .S3D, OpenZone 7.0 will also create a <zone>.map file in an \eqemu_maps subfolder (the archive will have this folder in it). The map.cpp and map.h files that come with EQEmu aren't all that well documented, but I think I understand what's going on now that I've spent a few hours looking at them.

One question I have is how small should the granularity be when making the .MAP files: what is the cutoff size when making nodes? I don't have the source to the original program that made them so I'm guessing here.

[GeorgeS]

Thanks for this WC - this will help with spawns and LOS tremendously

GeorgeS

[fathernitwit]

wind,

The full source of azone is in cvs, the interesting file is:
http://eqemulator.cvs.sourceforge.ne....4&view=markup

Overall it is just a simple quadtree, ignoring the Z axis, the only hard part is doing triangle-cube intersection, but im sure you have code for that somewhere, or can port the C++. The on-disk format was meant to match to in-memory format on the reader side, so azone does a bit of extra work to get everything packed together correctly.

There are a few different criteria from stopping the quadtree split, mainly number of triangles remaining in the box, or the size of the box. I also added an information-gain style termination criteria such that if splitting the box does not actually split up the polygons further, then we stop, but I cant remember if this did any good or not. All in all, the stopping criteria are rather arbitrary, changing them around or adding more should not hurt anything.

let me know if you have any issues.