Map Spawn Viewer (WIP)

[Kayot]

So no one thinks I'm slacking off, heres what I'm working on.

Screen Shot - 1 (http://kayosblade.googlepages.com/SpawnViewer.png)
Alfa Program - 1 (http://kayosblade.googlepages.com/LineArt.rar)

It loads the map files in the eq map folder. If you want all the maps go to eqatlas and get the color ones as they are pretty.

This program will be integrated into the main program sooner or later. Right now it just loads the map. But soon it will list spawn points and paths along with trade skill platforms and ground spawns. This is more of a look up tool due to the lack of the TRUE y-coord (Y is up and down while z is distance, EQ messes this up by swapping Y and Z). Maybe deep in the future when I figure out 3D rendering etc, I'll make a true map editor.

[GeorgeS]

I forgot to say - this is a great idea if implemented right. I like what you have so far.

Some moons ago, I tried this, but realised z-height was not possible to retirieve - even tried converting to .obj with no/limited sucess.

I'm afraid only WC can do this (can decode .s3d's) easily, and adding pathing would be fantastic. You could ask him about it - if he's done with project.

GeorgeS

[Kayot]

I wish it could be 3D, but VB.net has its limitations (Funny that C# doesn't have as many and compiles to the same exe type through the translation). For now, I'm trying to make a Data Viewer (Which doesn't work in Kedge Keep without a height filter, the raid had promise too. Thank god for Shadowrest.).

My problem is this, I'm trying to get it to paint it once for zoom level and not for moving it around. I was thinking about using an Imagebox and storing the drawn map in memory and allowing the SQL markers to move with the map (Imagebox), which can be mouse moved. The concept is mind boggling, so much that I've kind of put it on a back burner while I get full item and mob lookup (Which is key to the SQL marks, after all the npc id tells didily squat and who wants to look it up over and over?)

On the flip side, the item desc now used HTML which means colors and tables. However all the added item info kills the load time which is now 1.8 seconds which is an eternity. I think it has to do with reading the spell tables. I figure, get the program finished then optimize :)

My goal this week is to make the program do most of what allakhazam does. Quest come later somehow :(

P.S. GD Giants drop crappy loot and have poor exp. May as well keep non-KOS faction.

[GeorgeS]

Actually vb/net can do excellent 3D (truevision API dll), but I am not sure it would help me anyway. How did you decode the eq map files - they have syntax like

L 3.2725, 216.7370, 0.6260, -58.9923, 331.4005, 0.6260, 150, 100, 0
L -58.9923, 331.4005, 0.6260, -148.8005, 426.0498, 0.6260, 150, 100, 0
L -148.8005, 426.0498, 0.6260, -260.0621, 494.2486, 0.6260, 150, 100, 0

I'm looking into this as well for a future update..

GeorgeS

[AndMetal]

How did you decode the eq map files - they have syntax like

L 3.2725, 216.7370, 0.6260, -58.9923, 331.4005, 0.6260, 150, 100, 0
L -58.9923, 331.4005, 0.6260, -148.8005, 426.0498, 0.6260, 150, 100, 0
L -148.8005, 426.0498, 0.6260, -260.0621, 494.2486, 0.6260, 150, 100, 0


It looks like it's broken down in to the following:

Type (Line, Point, etc)
X Coordinate (looks to be inverted, so negatives are positive & vice versa)
Y Coordinate (looks to be inverted, so negatives are positive & vice versa)
Z Coordinate (doesn't look to be inverted)
Attribute 1
Attribute 2
Attribute 3
Attribute 4
Attribute 5
Attribute 6 (optional?)

It looks like Attributes 1-5 depend on what type of coordinate it is.

For example, on a Point, Attributes 1-3 look like they may be the color (yellow is 255, 255, 0 & black is 0, 0, 0, so it looks to be Red, Green, & Blue), Attribute 4 looks to be the size (2 for Medium), and Attribute 5 is the actual text for the Point. It doesn't look like there is a 6th attribute for Points.

On a Line, Attributes 1-3 look to be the ending X, Y, & Z coordinates (Z & Y being inverted like the first set) and Attributes 4-6 look to be the color of the line (RGB like the text colors).

On a somewhat side note, I found this website (http://www.tski.co.jp/baldio/map/) while looking up some other stuff. It basically creates an image using the map files with what looks to be a CGI script. It's not downloadable, but it might give you some ideas.

Hope this helps :-)

[GeorgeS]

Thanks - that pretty much explains it. I added a few more map file and shortly will attempy to do this in 2D overlay, then try it in 3D

GeorgeS

[sesmar]

For 3D, I know that you use Visual Basic 6 GeorgeS, but for .net take a look at the XNA Framework. You can do a lot of stuff both 2d and 3d without a lot of work using VB.Net or C#.Net.

[rmanders]

A while ago I was working on something similar (http://www.dz01.com/images/eqemu_spawnview.jpg) to what Kayot is doing now. I kind of stopped working on it for the reasons described in this post.... It's neat to view the spawns, but to actually place them you need a way of viewing the map topology....or at least "dropping" a spawn just above the surface. The problem is how to get this data. Could it be read from an s3d file?

[GeorgeS]

Yes, in essence everything in the the S3D file such as the 3D zone. It's complicated to figure out, and I tried just to export the .obj 3D file. But even that is hard to work with. I have ideas - just need time to figure it out.

The only tool is truevision3D.dll - which allows for Z-height mapping, and I'll start with that.

GeorgeS

[Bulle]

This calls for a question then : what do the *.map files contain, the ones from the Maps directory that you have to put in your server DIR ? I had always thought they contained a dumbed down 3D description of the zones, basically the world coordinates of the solid areas, so that NPCs do not fall underground etc. Am I wrong to think the contents of these files *.map is well-known and "easily" parseable ? I got them from Sourceforge so that was a given for me.

The S3D files are Sony material and feel like "less desireable", being proprietary.

I know nothing about how the 3D in EQ is orchestrated so I am asking newb questions here, to understand what we know and can retrieve, and what we cannot. If there is a place to get a bit more enlightened about this topic I welcome any link :)

[Derision]

This calls for a question then : what do the *.map files contain, the ones from the Maps directory that you have to put in your server DIR ? I had always thought they contained a dumbed down 3D description of the zones, basically the world coordinates of the solid areas, so that NPCs do not fall underground etc. Am I wrong to think the contents of these files *.map is well-known and "easily" parseable ? I got them from Sourceforge so that was a given for me.

The EQEmu .MAP files are created by the Azone utility (comes with the EQEmu source). Azone rips the polygons (triangles) describing the 'ground mesh' from the S3D or EQG files. By ground mesh, I mean the .MAP doesn't include what are classed as 'placeable objects' such as trees, some small rocks, small buildings etc. (even quite large structures such as a bridge in one zone (I think it was Thundercrest)).

As well as the actual polygons, the .MAP file contains an octree that divides the zone into rectangular 2D nodes so the code can find all the polys in a particular area of the zone quite quickly.

There is code in zone/Map.cpp to use the .MAP files, e.g. load them into memory, check if a line between two points intersects any polys etc.

The FindBestZ code for example projects a line vertically downwards from a given X,Y,Z location looking for 'the ground'.

[Bulle]

Thank you Derision. You gave me the pointers to look at if I need more.

So an extended Find BestZ (projecting downwards and upwards) could find where to put the NPC to have it with its feet on the ground for a specific coordinate. That leaves open the problem with placeables.

[rmanders]

That information on .map files helps. What about situations where there are multiple open spaces on top of each other (such as in a dungeon)?

I suppose that could be handled by using the layer properties of the UI map text files. For each layer being displayed (if more than one), then the spawn would be dropped at the first encounted ground intersection from the topmost displayed layer. I would think this depends on how accurate the UI map layers are though.