I don't mean to create a topic regarding the exact same subject as another topic on the front page, but I didn't want to hijack their's. :pAnyway, I've been implementing A* path finding from a tutorial found here: http://web.mit.edu/eranki/www/tutorials/search/I've been going off the algorithm detailed at the bottom of that page and was just wondering where the final path is.In other implementations of this algorithm, there was an open, closed and final path list. I understand most of the algorithm, but once it's been designed, how do I access the final list of nodes?

Yes and no. The correct path is a subset of the closed list. This means that all nodes from start to finish will appear in the closed list. However, the closed list contains every visited node.

From a quick glance as the pseudocode that was posted in your link, to get your path you're going to treat the end node as a sort of linked list and backtrack through path using node.parent to construct it. Something like:

At the moment I'm declaring it with the start and goal nodes set to (0, 0) and (10, 5) respectively. Can anyone spot the reason why it's loading out?

Thanks!

1

open.add(start);

At no point do you remove start from the open list, therefore its size is always > 0. Infinite loop.

Also when you are creating your NodeMap, if you have one...are you predefining a bunch of nodes that are automatically closed?

EDIT:

Also I have no idea if my way is more efficient, but I have each node store an array of neighbours instead of doing that in the loop, my nodes are all initialized at game start so that only gets done once.

Also from what I see you have no predefined nodemap, I suggest you make one. Surely you have obstacles? If so, get a node map made.

EDIT 2:

Actually now that I think of it, why is start even on the open list? It is not an option, you are already there. It should be on the closed list.

"This code works flawlessly first time and exactly how I wanted it"Said no programmer ever

All the tutorials I've looked at have told me to add the start node to the open list. :xThe start node is removed almost immediately because it is the node with the lowest f value in the open list and that node is removed at the beginning of the loop.

All the tutorials I've looked at have told me to add the start node to the open list. :xThe start node is removed almost immediately because it is the node with the lowest f value in the open list and that node is removed at the beginning of the loop.

Ah right I see where that is removed now, fair enough.

Regardless you are stuck in that loop, it seems your open list is never actually empty therefore your path is never actually found.

I suggest slapping a bunch of print statements in each part of the code where the search is complete, the loop should break or when a node is removed. As well as print the size of open each time one of those happens.

That should help you pinpoint, my pathfinder is quite a bit different. Hella lot easier to read, probably just because I wrote it .

EDIT: Oops yeah, I add my start node to the open list as well! Shows the last time I looked over this code LOL.

"This code works flawlessly first time and exactly how I wanted it"Said no programmer ever

You really need to rethink all your variable names, this could have been avoided if you where not messing around with variable called n, q, f and h and what not, I know what they are but it is still annoying as hell, for instance:

Which is computing the g value wrong for all nodes (G value is the ACTUAL TRAVELED DISTANCE!) so this is giving bad values.

This file: http://www.java-gaming.org/?action=pastebin&id=898 gives you the right value and has some other misc corrections. You still end up exploring negative areas though. This version also cuts out when the F of the 'next shortest path' is greater than the best (Which is an important part of A*. )

All works great. Thanks for everyone's help. Hey UprightPath, when you say the next shortest path, wouldn't that always be greater than the shortest path? Also, do you know how I would solve that problem?

When each node takes only 1 to move between (A flat cost map) then you don't need to do anything. It's when you have maps of different costs (Say, moving from a road to a swamp in a strategy game, or going up stairs or something) then you have to worry about it.

What you can do when it comes to the out of bounds things is use some method call to get the nodes:

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org