Path file issue: ~.path failed to load

[AdrianD]

Don't know how I missed your post provocating but, with that in mind...

I've read up a bit on #path. It's not committed to memory yet. Before I engage in a project such as this I want to prepare accordingly. I intend to dedicate a fair amount of time to this. It seems it will consume a fair amount of time.

I'd like to be as efficient about fixing all this zone crap as possible. I will not be adding anything custom to zones at this time. I simply want everything to work fine.

I will do the majority of research on my own but, it's important a few things are clarified before I jump in.

Regarding pathing:

Question set 1 - (similar questions framed differently)
Will one node recognize the presence of other nodes nearby? For example, if I add a node out of numerical sequence, does it matter? What happens to previous node connections if I <#path connect [connectid]>?

Question set 2 - (similar questions framed differently)
How does LOS, azone2 and the map files relate to pathing? What can I do with maps in conjunction with working on pathing?

I will be looking in to this stuff myself but, hopefully, someone will have a reasonably succinct answer which could assist.

Thanks

[provocating]

Originally Posted by AdrianD

Regarding pathing:

Question set 1 - (similar questions framed differently)
Will one node recognize the presence of other nodes nearby? For example, if I add a node out of numerical sequence, does it matter? What happens to previous node connections if I <#path connect [connectid]>?

Yes it will, as long as you process the zone afterwards. If you do the info on the last path node you add, you will see it is connected to other ones within visual range.

But there is a caveat to this. If you manually connect a path node, and do not let it do it automatically and then run the process command you will lose the manual one. So do any manual ones last.

Also save often, trust me. And it does not hurt to save with different file names as you go, in case you screw up. Like this.

#path process kaladimb-a
#path process kaladimb-b
#path process kaladimb-c

And so on

Question set 2 - (similar questions framed differently)
How does LOS, azone2 and the map files relate to pathing? What can I do with maps in conjunction with working on pathing?

Not a damn thing that I know of.

Also, as a tip, skip outdoor zones. There is no point in doing them, in fact it will make matters worse.

[AdrianD]

Thanks a lot bro. I appreciate the clarifications especially about saving multiple files.

I got started on the pathing stuff. I can imagine an entire complex dungeon is rather laborous. I #path process probably more often than I need to but, I don't really have a system to groove with yet. I have the EQ UI macros set up, though. It's kinda cool to see it actually work.

As far as connecting manually: What would be the purpose of connecting manually when you can simply <#path process Maps/short_name.path>. I'm not seeing it.

Thanks again

[AdrianD]

Is there a way to remove a node. I didn't see this in the list of commands.

[image]

use #path remove to get rid of a node (target the NPC that is the node you want to remove).

the point of doing #path dump versus #path process as I mentioned before is that, path process will connect all nodes within line of sight.

If you disconnected certain nodes from one another that were in line of sight, you probably added them back. So you want to use 'dump' instead to use the existing node connections you have made without establishing any new ones during that save stage.

[AdrianD]

I thought for nodes to function they needed to be connected to others in line of sight. Maybe my thinking is incorrect.

I'm having a hard time understanding the purpose or function if the dump command, as well. I get that it saves the nodes without making the connection. Why would a person not want to make a connection.

I spent most of the night working on a few zones that were either missing nodes in areas or needed improvements. Befallen, gukbottom and mistmoore all saw improvement. I was able to get npcs in all three zones path properly down/up various vertical areas including water. I hotkeyed bind affinity and gate and shot with arrows to test - #aggrozone was acting funny and isn't realistic in most circumstances so I didn't use it, it would be nice to have just #aggro with the target selected. The spatial understanding is there as well as some techniques to work with vertical pathing.

I think it's also important to think like a player when applying nodes, if you get what I mean.

I've also noticed some .path files are much larger than others and I'm curious to know how this could effect overall zone efficiency. The guks are a prime example.

Speaking of which, guktop pathnodes do not appear when using the command. I downloaded two other versions which were likely the same version (they were all the same size) with no difference. I've held off on doing anything with guktop until verification of my issue.

EDIT: I found a purpose of disconnecting nodes - it would be bad news for players to have npcs take the most efficient route when training in those vertical node connections - thinking like a player, easier said than done. One-way connections would be a neat feature.

[AdrianD]

Hello,

I'm trying to understand the nuances of the #path tool and, specifically, what corrupts the file. I've found whenever I #path remove with a target node selected, it corrupts the file. I don't know why this happens. I wish I did.

This is what the log file reads after #zoneshutdown <short_name> or rebooting the server:

[09-13-2015 :: 02:33:10] [Status] Path File Header: Version 2, PathNodes 1518
[09-13-2015 :: 02:33:10] [Error] Path Node 296, Neighbour 16 (1523) out of range.
[09-13-2015 :: 02:33:10] [Error] Path Node 296, Neighbour 17 (1524) out of range.
[09-13-2015 :: 02:33:10] [Error] Path Node 297, Neighbour 17 (1523) out of range.
[09-13-2015 :: 02:33:10] [Error] Path Node 297, Neighbour 18 (1524) out of range.
[09-13-2015 :: 02:33:10] [Error] Path Node 307, Neighbour 14 (1523) out of range.
[09-13-2015 :: 02:33:10] [Error] Path Node 307, Neighbour 15 (1524) out of range.
[09-13-2015 :: 02:33:10] [Error] Path Node 308, Neighbour 14 (1523) out of range.
[09-13-2015 :: 02:33:10] [Error] Path Node 308, Neighbour 15 (1524) out of range.
[09-13-2015 :: 02:33:10] [Error] Path Node 309, Neighbour 14 (1523) out of range.
[09-13-2015 :: 02:33:10] [Error] Path Node 309, Neighbour 15 (1524) out of range.
[09-13-2015 :: 02:33:10] [Error] Path Node 312, Neighbour 16 (1524) out of range.
[09-13-2015 :: 02:33:10] [Error] Path Node 313, Neighbour 16 (1524) out of range.
[09-13-2015 :: 02:33:10] [Error] Path Node 314, Neighbour 16 (1524) out of range.
[09-13-2015 :: 02:33:10] [Error] Path Node 315, Neighbour 10 (1524) out of range.
[09-13-2015 :: 02:33:10] [Error] Path Node 320, Neighbour 9 (1519) out of range.
[09-13-2015 :: 02:33:10] [Error] Path Node 320, Neighbour 10 (1520) out of range.
[09-13-2015 :: 02:33:10] [Error] Path Node 323, Neighbour 10 (1520) out of range.
[09-13-2015 :: 02:33:10] [Error] Path Node 1514, Neighbour 0 (1524) out of range.
[09-13-2015 :: 02:33:10] [Error] Path Node 1515, Neighbour 5 (1524) out of range.
[09-13-2015 :: 02:33:10] [Error] Path Node 1516, Neighbour 9 (1522) out of range.
[09-13-2015 :: 02:33:10] [Error] Path Node 1516, Neighbour 10 (1523) out of range.
[09-13-2015 :: 02:33:10] [Error] Path File ./Maps/gukbottom.path failed to load.

You can see the file has <PathNodes 1518> and the nodes seem to be numbered up to 1524. I must have taken out six although there is no instance of 1521 in the error log (1521 was not removed).

I went through the same process in a different zone with far fewer nodes and the same thing happened. To test this I removed a single node, processed and repopped to verify. Then, I left the zone, #zoneshutdown <short_name>, renentered the zone and #path shownodes at which point they would not appear. At this point I would overwrite the file with a saved non-corrupt copy.

Is there a way to re-number the nodes (not manually) or make the program work with the actual <count> of nodes? Maybe something else is happening. Am I doing something wrong? I am only a couple days (hours) into this although not having this function to clean up some zones would be unfortunate.

Thanks

EDIT: Image, what I am gathering from dump/process is the moment you need to use dump instead of process, you can't go back to process. This means if dump was needed and more nodes need to be added, they will need to be connected manually. Just horrible. Better plan my silly pathing endeavors. Does this sound right?

[image]

Kind of hard to answer this all via my cellphone.. But looking at the code:

https://github.com/EQEmu/Server/blob...ne/pathing.cpp

	int MaxNodeID = Head.PathNodeCount - 1;

	bool PathFileValid = true;

	for(uint32 i = 0; i < Head.PathNodeCount; ++i)
	{
		for(uint32 j = 0; j < PATHNODENEIGHBOURS; ++j)
		{
			if(PathNodes[i].Neighbours[j].id > MaxNodeID)
			{
				Log.Out(Logs::General, Logs::Error, "Path Node %i, Neighbour %i (%i) out of range.", i, j, PathNodes[i].Neighbours[j].id);

So if you look at your log errors the number at the end (just before out of range) should be less than the version header count which is 1518 nodes.. I am not fully sure how you pulled this off did you start your own path file or use mine?? Cause I haven't seen these errors before

Pathing files do require lots of planning or at least getting the full set of nodes up you think you need, process however many times to save during that endeavor after you can load the nodes up and if you need to add one here and there manually to make pathing more smooth I add and connect additional nodes manually.


Honestly I never removed nodes so maybe that has a bug..? I always add nodes I plan to keep and disconnect to other nodes I don't like them making

Also yes nodes don't have to be connected to be used individually but it can definitely make them prefer a path by connecting the nodes.

[provocating]

I have a rule that I follow. I never, ever remove nodes. Removing nodes always seem to corrupt the path file for me, almost every time. If I have to remove a node I just start over again. So this makes me be very careful when doing my path files.

[AdrianD]

Thanks for the responses.

The specific path file from gukbottom was kindly given to me by Mr. provocating. It was the first zone I utilized this tool in a couple days ago.

It looks like the maxnodeid is being set at nodecount - 1 like your code quote says but, that is not the real maxnodeid. I don't know how it is supposed to work but, setting the maxnodeid = nodecount -1 is obviously incorrect if a functional #path remove option exists. Maybe resetting the nodeids is an easier solution than correcting the counting function. I don't know.

Corrupted .path files have been around a while I imagine. As long as I have been around here. I know this much.

I can't say using #path remove is the only thing that could corrupt a .path file but, it seems apparent it does. I haven't heard of this issue in the few threads I've searched. I think it's possible people have just accepted this as "working as intended" to not stir any pots.

I was watching the memory/cpu usage as various zones were being loaded and #showpathnode -ed. I understand some zones are more complex than others. Point being, the potential efficiency gain is present and may be worth looking into.

Thanks

[AdrianD]

I found this: (it wasn't hard to find)

#path sconnect [connectid] - Requires target, connects the pathing NPC node id to the provided node id (connectid), but not the other way.

I had only skimmed over the descriptions previous and dismissed this command. The description could be better. Just call it a one-way connection.

This is an excellent command and glad it works.

Some clarification and proper use of a couple commands would be appreciated, the descriptions, well, the descriptions. I've messed around with the two commands below only a small amount and noticed nothing different.

#path qconnect [set] - Requires target, short cut connect, to the previously targeted [set] (?).
#path resort [nodes] - resorts connections/nodes after they have been manually altered.

................

It looks like the maxnodeid is being set at nodecount - 1 like your code quote says but, that is not the real maxnodeid. I don't know how it is supposed to work but, setting the maxnodeid = nodecount -1 is obviously incorrect if a functional #path remove option exists. Maybe resetting the nodeids is an easier solution than correcting the counting function. I don't know.

I'm not the only one with corrupted .path files from using this command. Can others replicate this issue? I get that the code would probably need to be changed and I don't expect anyone to jump up and do it just because I said so. If I could code it would either be done or in progress but, this is currently my issue. Any insight on this? Please correct me if anything I deduce is incorrect.

While I am not ungrateful that #path exists, the process, as it functions now, seems like a house of cards and jenga combined. A little dramatic maybe but, this issue reduces functionality significantly, for me at least.

I've put most of this project on hold until I'm given some insight on more of this. I'd like to clean up a bunch of zones and knowing whether I need to start over on the zone or not would be helpful.

Thanks

[image]

From the small pool we have here it seems that it is just you encountering that problem, but yes the existing paths might be borked. You can try some of the extended commands like reorder, but I don't know if it will save you. Sometimes you have to start over (I have had to as well, but other reasons). After a while you should get the hang of just putting nodes down, processing and doing a second run to clean up bad pathing through testing and be done with it.

I don't see anyone fixing this issue with removing nodes anytime soon. Barely anyone touches the #path commands or code at the moment. There is only one server that has a complete set of pathing files which are 'proprietary' it seems.

As far as the commands you noted, I would stick to connect/disconnect/add. Those are the ones you need and then use process/dump as previously instructed.

[AdrianD]

From the small pool we have here it seems that it is just you encountering that problem

Just me?! Oh, well, now I feel special. But in the way some inbred donkey feels around his sister.

Sometimes you have to start over (I have had to as well, but other reasons). After a while you should get the hang of just putting nodes down, processing and doing a second run to clean up bad pathing through testing and be done with it.

I'm fine with this and have been. I figured as much after a few short runs at it.

I don't see anyone fixing this issue with removing nodes anytime soon.

I wasn't planning in hearing any good news about this. Mostly, I figured to get it out there and get some feedback.

My main goal is to understand the process. These issues were creating roadblocks to efficiently getting it done. Getting clarification from people who have done this before is what I was after.

Thanks Image, provocating, N0ctrnl and anyone else who has contributed to my understanding.

[N0ctrnl]

I will say that removing a node causes issues for me as well. Every node I add after removing one comes up with the same ID. I learned the hard way that if I get one outta place, just go back and fix it when everything else is done.