Z Coordinates ...

[Batlas]

Maybe you can make a command which disables nodes for an radius around a given loc. Then all you would have to do is go inside the building and re-enable the nodes where said mobs can walk.

[Etaew]

That's an option, but still a ridiculous amount of work I'd rather some map parsing tool.

[Etaew]

Maybe you can make a command which disables nodes for an radius around a given loc. Then all you would have to do is go inside the building and re-enable the nodes where said mobs can walk.

I did exactly this Batty, also I've changed the DB from storing all nodes, to storing only disabled nodes, and I've changed the memory from storing all nodes, to storing only disabled nodes. I've also decreased the distance between nodes from 256 to 64, i might prefer 32 though, this is now a constant in the script, and can be changed at any time without reconfiguring the rest of it, it just invalidates all the dbs.

Although this still won't fix our Z problems, that requires more thought.

[Smallhorse]

Well actually Z coordinates will have to be mapped manually. As we talked on ICQ ... a 3d grid is the same as if using a mesh with each node being a point in the mesh.

Overland maps for a normal zone in DAOC are generated via 256 x 256 points.

Normally you can assume that a mob can walk any path on a overland map.

The only thing you need to take care about are as you said, areas where mobs can not enter (keeps are a good example).

To use pathing inside dungeons and keeps it is different. You need to map the valid positions, not the invalid ones and connect them. Almost like a floor-plan.

Now inside a dungeon it would work like this. A mob wants to go from A to B. It searches a path-node near B (the closest one), then it searches the closest path-node near A and then it calculates the path from node A to node B. So far so good, no problem here in dungeons if they are mapped nicely

Back to overland and keeps. To map a keep you would need to define a circle of nodes around the outside (perimeter) and a circle of nodes on the inside of the keep. The outer perimeter and the inside nodes are connected through the keep-door.
A mob wants to walk from somewhere out of the keep to inside the keep, perhaps even up a tower to the lord. It works like the dungeon (almost). It searches a path-node near the lord (node A) and then it searches the nearest path-node to himself (node B). Imagine the mob is at the backside of the keep (miles away or close does not matter). It will find a node near the lord, it will also find a node at the backside of the keep (remember the node-circle around the outer wall?). Then it will calculate the path between those nodes. This way it will go around the keep, through the door, up the stairs, etc...

The only trouble is that those nodes in dungeons and keeps need to be manually placed. Perhaps it can be done with a script that places nodes on the ground in regular intervals when you run. When you come close to a previously placed node the script could automatically connect them (if they are not already connected). This way you could build up a grid by simply running through the dungeon, visiting possible places and routes.

[Etaew]

My system is for a grid preset distance apart from each other, I agree the solution to the problem is a mesh of points placed at specific intervals, but I'm not sure how this would yet be done.

[Troglart]

I was just thinking, Etaew.. your nodes lay themselved out across all the ground, even if your in a dungeon where the Z coords are changing right?
If you dont understand what im saying heres an example.. your walking down a hill and theres nodes on the ground going down the hill, not in the middle of the air, so what im thinking is, to reduce some of the manual labor, make it so that if 2 nodes Z coordinates are a specific number jump which you normally cant run without a hill make it so the two cordinates which are in the same X or Y line cant connect to eachother because of the large Z change

[Etaew]

The nodes dont know about the height of the ground, only your client does. And the reason they are shown on the ground is because that is just how the client is set up to receive these objects regardless of height.

[Troglart]

You only answered part of my question..

When the node gets layed down at ground level, when its put into the database it has that correct z coordinate for it, right?

What i think should happen with these nodes is that you shouldnt just have nodes to open and close, the mob also needs to calculate that if the Z coordinate change is more than 40 (i think thats jumping height).
Then the Z should be currently unaccessable from where it is at, so there should be an internal flag also stating if you can go to that node from where you are, so if it the flag shows up false, then it cant use that way to get to the target area.

[Etaew]

No, when it's put in the database it does not know the correct Z, so no Z calculations can be made.

[Troglart]

Oh that sucks, if it was it could of saved alot of time

[Batlas]

Aye, if you do moveto commands etc, you can leave the z coord at 0 and most of the time it will still put you at the correct z level.. (At least it used to!)

[Troglart]

damn, theres no good way to do this lol, manually mapping seems to be in the near future unless someone can develope a program to open up the files and make 64x64 nodes on the map, and then adjust them to the ground layer and have it so it takes the coords and automatically adds them to the database.. somehow

Like Etaew using the node idea, for 1.7 (I dont know why i did it for 1.7 i am being silly i guess) i made my own type of node, so far i can make nodes through a command ingame, im going to see if i can get a mob to calculate the quickest path to me through the nodes i have self placed

[Etaew]

A* algorithm can be used for that too.

[mgX]

In my oppinion the best way is to parse all the maps from the client files. TheSchaf has already proven that they can be changed, and has a method of doing so. You should be able to parse the layout into some fancy format and then load it on demand. After that, it should just be a matter of pathing the entire world using the data collected from the client.

[Dunnerholl]

interesting thread, it was all already here 5 years ago, and we are not much further, right?