Yet Another Pathfinder example

[MuddyMole]

Consider an obstacle like this:



The closest node to the target is #3, but the closest point to the target that lies outside the obstacle, is actually on the edge between nodes #1 and #4, so node #3 is irrelevant.
Unless you force the user to strategically place extra nodes just to account for this (which I don't want to do), you have to assume that the closest point could be in any direction, on any of the edges between two nodes - and then you'e back to explicitly listing the walls that define each polygon, which is what the previous version did.

Although the spiral method seems a little inefficient, as it's likely to require up to maybe 200 fastloop iterations (hopefully not much more than that), I would imagine that depending on the map complexity, the overall pathfinding system is probably going to use a few thousand iterations (I really ought to test that!), so the overall impact may not be that bad.

[ciaciosacchetti]

I have another idea, i try to explain with my basic english, if you click inside an obstacle the system automaticly draw a big spiral without loop, and then a loop start to find the closest spiral node outside the obstacle close to the mouse click.
Sorry if you don't understand, i try to do my best

[NaitorStudios]

The problem isn't the loop, it's the amount of actions lol
If you just create the spiral without a loop, you most likely would create more than necessary since you can't break actions.

[danjo]

Consider an obstacle like this:



The closest node to the target is #3, but the closest point to the target that lies outside the obstacle, is actually on the edge between nodes #1 and #4, so node #3 is irrelevant.
Unless you force the user to strategically place extra nodes just to account for this (which I don't want to do), you have to assume that the closest point could be in any direction, on any of the edges between two nodes - and then you'e back to explicitly listing the walls that define each polygon, which is what the previous version did.

Although the spiral method seems a little inefficient, as it's likely to require up to maybe 200 fastloop iterations (hopefully not much more than that), I would imagine that depending on the map complexity, the overall pathfinding system is probably going to use a few thousand iterations (I really ought to test that!), so the overall impact may not be that bad.

what i was saying, was something like this, but in the direction/line with the actual object moving to it.
it could be a simple as firing a pixel (using 360 degree angle) - at the original object from the click (and when it is NOT on an obstacle) that is the point.

[MuddyMole]

There are still going to be some odd cases where it doesn't work right.
An extreme example would be something like this:

[danjo]

what about constantly or periodically doing that pick

[MuddyMole]

There's no real advantageto that, and it's going to mean that the stored heuristic values for each node are going to be wrong because the target is changing, which is very likely to break the whole thing.

[danjo]

OK, you may as well prevent the user from targeting inside an obstable - (or) - if they do, push the target out of the obstacle - toward to the objects - this is something anyone could modify regardless;
its a great example of pathfinding that looks nice to start with

[MuddyMole]

Agreed. If it's a case of pointing and clicking, like in an adventure or strategy game, I'd probably just change the cursor to a red cross or no-entry sign or whatever, and ignore the player's click.
There are cases where that isn't going to work - like maybe you have some ground units that you want to have chase a flying unit, which can go places they can't - but yes, that can be left to the game designer to figure out...