[Behavior]PathFinder

didnt see this topic before, this kicks my ass on ^^

thanks :)

Nice. Will come in handy.

I just loved it.... will be so useful.

Long time overdue, the behavior has been updated to fix the obstacles bug.

You can now use several obstacles and they get better spotted.

You can also find a new example about how to move an object with the PathFinder behavior.

Fixes and examples thanks to —

Check the first post to download everything you need.

Happy PathFinding in 2012.

By the way, this latest version only worked for me when I removed line 6 (version) from edittime.js <img src="smileys/smiley2.gif" border="0" align="middle" />

edit: maybe it was just the missing ,

Wronghands: thanks for the notice.

Indeed it was a last second copy/paste.

It should now be fixed in the zip.

Excuse my constant whining but I made this badly drawn graphic to point out an unintentional behaviour. Sprite doesn't move on a straight line from A to B but rather prefers the long route I've drawn, avoiding the green obstacle by leaving a margin of 1 cell. I'm not sure if this may have anything to do with the way motion is implemented in the example or the heuristic formulas but the online demo is working as intended. Something to do with the newly modified obstacle code perhaps?

<img src="http://dl.dropbox.com/u/3138530/weirdpath.jpg" border="0">

Also, this is how it happens vertically, from A to B and vice versa. This only happens when the sprite is on the right or below of the obstacle, never when it's to the left or above it:

<img src="http://dl.dropbox.com/u/3138530/weirdpath2.jpg" border="0" />

Indeed, the fix doesn't completely fix the issues ^^

I have a pretty good working version now. It's almost done, I need to iron out one or two things before release though.

It will probably be done by a couple of days.

Nice, thanks :)

Meanwhile I've got another report that might help you debug it more.

In a real turn based environment, movement costs and unit movement ranges come into play and one has to calculate paths before the movement is triggered then allow it accordingly. I can easily throw in a variable and compare it to the pathlist to decide whether or not the movement is allowed however I do need to calculate paths dynamically therefore I'm running the pathcheck on every tick, with issues:

With this capx, one of these things happens:

1- Works as intended for a while eventually locks up the canvas. May occur in the path generation phase before the movement is triggered with the mouse. Just hover the mouse around any element for a while and it'll lock up.

2- Canvas is frozen upon load, elements can be seen but are locked up.

3- Canvas is filled with a solid grey color.

This behavior has great potential and I'm getting the hang of it now. It'd be a shame if it wasn't actively developed so thanks for all the effort you've been putting into it.

(edited for clarification)

Today I also noticed that moving the pointer outside the canvas is a sure way to crash it. Increasing the path generation frequency from every tick to a second allows it to survive longer but it eventually fails.

Also edited the capx a bit more.

This plugin isn't really designed to allow for such a usage.

Calculating paths each tick out of a target that may be indeed out of layout will cause it to freeze/crash.

And I'm really not sure how to prevent it atm.

If you want to preview a path for your unit though, it's another logic to be used.

I'll include another example with the release.

It might take more time than just a couple of days as this is not the only matter on my hands.

In other words, I'm doing it wrong. :) It's always better not to rush it, take your time. ;)

I played with this a bit more and I'm sorry to say that either construct or the pathfinder behavior is looking for an excuse to crash. I found acceptable workarounds for most issues but here is the one bugging me at the moment:

I used the information on this thread for for previewing my path target by picking instances. Used Yann's and Kyatric's methods there and am having issues. I also had to lay invisible sprites around like a noob because that's all I could think of.

v1.capx

Yann's version. Instances aren't deselected properly and they often remain picked over the mouse's trail. Probably c2 issue. Workaround is to reduce the hotspot by at least 3 pixels on all sides. Quite unacceptable. Why can't there be "on mouse enter" "on mouse leave" conditions?

v2.capx

Kyatric's method. Reason why I'm using this thread right now. Successfully picks only one instance at any given moment but line 6 is problematic. Moving the mouse pointer outside the canvas or switching tabs around by mouse shortcuts locks the application up. Can't know if it's a c2 or pathfinder issue. Maybe this is simply the result of an overall unstable "on every tick" condition or maybe it only manifests itself when the pathfinder behavior is around. Either way, this is burning me out. :/

Additional request:

Pathfinder wants to register tiles with their middle pixel thus doesn't play well with the built in pixel grid. :/

Just a quick word, yes the PF is buggy at the moment, I still need time to fix it.

I haven't lookes at your capx, but it is likely, atm, that anything you'll do will end up crashing/failing because of the inner bugs of the PF.