I think you're pretty much right about the .wld files, but you went into this with a fairly snippy and insulting tone, so I'm not sure why you expected a nice answer.

The thing is though - until someone is ready to code the usage of .wld files and fetch the exact same information,
we might as well use the .maps. If the information extracted is the same, the code is going to be same.

Really, though, you pretty much shot in with a "Hey, idiot, why the fuck are you doing it like that?". I suggest adjusting your tone for "suggestions", so they don't sound like outright complaints.

My zone viewer reads wld files (zone geometry) just fine and is written in C++. For zone geometry you really only need three or four types of fragments (0x21, 0x22 and 0x36 if my memory serves me right), though texture info might be handy as well (for zone borders and other transparent stuff), but the 0x31,0x30,0x05,0x04 and 0x03 fragments are reeeaaally easy to read.
Not sure though if it's fast enough for a zone bootup (loading times need to be fairly short).

What's the loading times? If nothing else, it could work for static servers.

If we could add texture reading so you can determine when it crosses a "hollow" wall or you're in water, that'd be a very nice addition.

As this is a huge step in the right direction, I want to thank everyone who is working on this problem and Wiz for posting the code. It may not be the optimal, all-encompassing solution, but if it works just on SOME zones for now its a good thing. LOS is the last major flaw I see in emu, so any type of solution, whether temporary, working for only some zones, or whatever I see as A Good Thing <tm>.

What is the reasoning behind this statement? Just because there are no programs allready to do it?


Here are my reasons for going from an intermediate file:
1. Somebody else allready wrote the LOS code... this has been proven to me to be wrong, since it dosent work very well.
2. It takes CONSIDERABLY longer to parse a .WLD file than reading in these map dudes... even though my map files are ending up larger. And there are a few places that I could make .map reading even faster.
3. It saves the quadtree directly, you dont have to calculate it. This is a very expensive operation. On big zones it takes up to 30 seconds for my machine to read a wld file and produce the quadtree. That wont work for zone bootups at all.
4. It increases the long term longevity of the conversion program. If the w3d/wld files change, somebody dosent need to touch the emu or conversion program, they can just change the util to extract the world object. Theres a lot more zone reading utils than any other 3rd party programs.

I also have not been able to find any C++ which will get a .wld out of a zone directly, without using the windows specific eqinside.dll. So there would be that step anyways on a zone update.


My original plan was to load directly from .wld and produce a quadtree, but something is majorly wrong with the old .wld reading code I have, because the bounding box of the zone is completely wrong (much larger)... so I am currently working off .obj files spit up from DZoneConverter. I havent been able to figure out how DZC is different than my own reading code, I looked it over pretty well.

on a more pleasant tone.

I think I have zomething resembling LOS working...
- I can officially walk around crushbone castle and into the little nook in the middle without anything coming out from the inside.
- When I go inside, in close quarters, a few mobs hop through the walls, but they are close enough to almost accept it.
- There are a few mobs stuck rigth now, you have to practically stand on them to get them to attack you.

I am accomplishing this with, what I think is a much more accurate solution, checking to see if the ray from the mob to the target intersects anything in the world. This might prove to be too expensive, so we can figure out some approximation. The downfall is that I dont know that it is actually working, no idea how to really 'test' it besides impirical tests like I did.


I would REALLY appriciate input on how the hell I can debug thing thing. It is very difficult to debug because I dont know where my problems lie.
I have 3 very complex pieces of code:
- map reader
- quadtree generation (triangle-cube intersection)
- LOS checker (ray-triangle intersection)

and I dont know which one is broken. I was having map scale problems forever (trying to read from .wld), and because of the errors at really close range, I think there are still some, but I cannot visualize this crap. My mobs that are stuck are seeing some random triangle in very close proximity to them which is not there.
It would be extremely useful if somebody could advise me on how I might try to visualize this crap on the client... any ideas on how I can get it to display SOMETHING.... I was thinking spawned items/people or anything... i just havent figured out what will work (and stay suspended in the air).

There is a #checklos command that might be helpful. Or at least, seems better than having to run around getting an aggro mob to attack you, specially since many mobs aren't aggro by default.

I assume that #checklos uses the same routines that the part of the AI that determines KOS does... but I'm not 100% certain on that.

This is just a wild guess here, but are objects and such in the map files? Like a broken table or pot sitting on the ground... Perhaps some sort of item like this is in the way causing it to not see you? And as for the aggros. perhaps the geometry in the zone is somewhat poor and there's a small "seam" between two walls or such?

again, far fetched. Admittedly i don't know what I'm talking about. =)

Can't say that right now, since I'm also loading textures, objects and other stuff, but I would guess a second or two. It's quite fast, since it's really not that complex.

hey, sounds good enuf to me :P

I would suggest that you write a quick little OpenGL/Direct3D viewer to pump out the triangle data so you can visualize it. It wouldn't really be too hard to throw together, and it would let you move around to the problem areas and see if there are any loose triangles in the way that shouldn't be there. This would pretty much tell you if 1) you're reading the map data correctly and 2) if your quadtree is okay.

If those were both okay, then you could try and put your LOS code into the viewer. You could have it set up so you input two points for your line, and have it draw the line in red if there's a blocker or green if it's okay.

Oh, and by the way, how are you deciding when to have a MOB check its LOS? Are you checking for all PCs/NPCs within a certain radius and then doing the LOS check? Also, if you want any help with the Quadtree/triangle-object intersection stuff, I might be able to help a bit since I've been doing the same stuff with the 3D engine I'm working on.

That would prolly be the most efficient in most zones, except maybe some dungeons / cities, where LOS can take out most radius checks. Aggro-radius is already in standard code btw.

As for the viewer, Mongrel had set up a quite nice one, and there is the freakU project going on. Both read from WLD files, though i know not if they use BSP or LOS (beyond OpenGL's internals) yet.

But everybody has to love walking through unrest and having 20 ghouls attack them?

I meant a viewer to check his .map file (not a wld file) so he could see if he was reading it in correctly/if he was partitioning the level right. It would be a good way to check each of the three possible problem areas (reading/quadtree/LOS), as well as display the data visually.

Then again, I'm not exactly sure what data is getting put into the .map file, since I've never messed with this zone converter program he's using. I'm assuming it's just pulling out the raw triangle (solid only) and vertex data--which would probably be all that's necessary for LOS checking.