Simplest pathfinding around a tilemap track

Here's a capx of a tilemap track with a sprite wants to find it's way from Start to Finish: https://www.dropbox.com/s/wg69djmnroga9 ... .capx?dl=0

I saw this great example by rexrainbow : request-car-pathfinding_t125153

And another pathfinding method: behavior-easystar-js-pathfinding-for-tilemap_t129056

But they seem quite tricky to set up, and I haven't got the greatest understanding of angles and loops, so I was wondering if the sprite could "drive" or crawl it's way around the track using the simple tools provided in c2? I tried it with solids, 8-dir and pathfinding, but the sprite just hit the wall and refused to go around the maze, and I'm concerned the built-in pathfinder might get stuck and I really need the sprite to always be moving, trying to find it's way around the track. Any suggestions as to how I could get started with the simplest method possible would be great!

The origins on your Start/Finish blocks were bad, so that caused some confusion at first. When corrected, simple pathfinding works fine.

Zebbi : You should really have a look at your origin-points, this is not the first time they are in the wrong place in the projects you shared..

Zebbi : You should really have a look at your origin-points, this is not the first time they are in the wrong place in the projects you shared..

Sorry, I wasn't aware the origin points were important in pathfinding, I've found that cloning items causes some strange origin point offsets, and alot of the time I haven't noticed any particular issues.

The origins on your Start/Finish blocks were bad, so that caused some confusion at first. When corrected, simple pathfinding works fine.

http://www.blackhornettechnologies.com/ ... r_BHT.capx

Wow, thanks for that, really helpful! I wasn't totally sure if it was possible or effective with pathfinding, but you've proved very well how effective it can be! <img src="{SMILIES_PATH}/icon_e_biggrin.gif" alt=":D" title="Very Happy">

> Zebbi : You should really have a look at your origin-points, this is not the first time they are in the wrong place in the projects you shared..

>

Sorry, I wasn't aware the origin points were important in pathfinding, I've found that cloning items causes some strange origin point offsets, and alot of the time I haven't noticed any particular issues.

> The origins on your Start/Finish blocks were bad, so that caused some confusion at first. When corrected, simple pathfinding works fine.

> http://www.blackhornettechnologies.com/ ... r_BHT.capx

>

Wow, thanks for that, really helpful! I wasn't totally sure if it was possible or effective with pathfinding, but you've proved very well how effective it can be! <img src="{SMILIES_PATH}/icon_e_biggrin.gif" alt=":D" title="Very Happy">

Origin points determine the x and y position of the object, regardless of the image part of the object, so yeah, kinda important..

Good point, im working on a game that requires pathfinding, and had a couple of issues, but this fixes it. Now I'm aware of it too ☺

The origins on your Start/Finish blocks were bad, so that caused some confusion at first. When corrected, simple pathfinding works fine.

http://www.blackhornettechnologies.com/ ... r_BHT.capx

blackhornet Quick beginner's question, how can I do "laps" in this way? I want to have the sprite cross the finish line an go around again, I've tried it with variables and also with offset overlaps, but due to the object either not quite reaching the destination marker properly, or trying to turn around at the end, I'm not sure how to go about this? Basically, once it hits the finish, it needs to go around again, preferably with as few markers around the track as possible (we are pathfinding after all!) and with no risk of the sprite turning around and going backwards.

What I would do in this case is use the patfinding behaviour to find the path and the bullet behaviour to move along the path, that way the path only has to be found once and when the last node is reached you could set the direction for the first node again..

Something like I did in this example:

https://dl.dropboxusercontent.com/u/485 ... erlap.capx

What I would do in this case is use the patfinding behaviour to find the path and the bullet behaviour to move along the path, that way the path only has to be found once and when the last node is reached you could set the direction for the first node again..

Something like I did in this example:

https://dl.dropboxusercontent.com/u/485 ... erlap.capx

This looks great, but it looks like a lot of maths. Is this way vastly superior to the method of pathfinding and moving? I appreciate that to do multiple passes of the same path might be more tricky, but is there no easy way of having the sprite loop around the path without using too many extra movements and expressions?

Most of the math in that example is to prevent the overlapping..

All you'd need is the part that does the bullet instead of the follow path..

Like this:

https://dl.dropboxusercontent.com/u/485 ... rcles.capx

Most of the math in that example is to prevent the overlapping..

All you'd need is the part that does the bullet instead of the follow path..

Like this:

https://dl.dropboxusercontent.com/u/485 ... rcles.capx

This is perfect! Thank you so much, a lot easier to read for those of us who are a little lacking in geo/trigan-ometrical knowledge <img src="{SMILIES_PATH}/icon_e_biggrin.gif" alt=":D" title="Very Happy"> I noticed the pathfinding method was a little shaky when the screen is set to scroll to it, I'll be keen to see if the bullet smooths things out. Is bullet a better behavior to use over, say, the car behavior?

> Most of the math in that example is to prevent the overlapping..

> All you'd need is the part that does the bullet instead of the follow path..

>

> Like this:

> https://dl.dropboxusercontent.com/u/485 ... rcles.capx

>

This is perfect! Thank you so much, a lot easier to read for those of us who are a little lacking in geo/trigan-ometrical knowledge <img src="{SMILIES_PATH}/icon_e_biggrin.gif" alt=":D" title="Very Happy"> I noticed the pathfinding method was a little shaky when the screen is set to scroll to it, I'll be keen to see if the bullet smooths things out. Is bullet a better behavior to use over, say, the car behavior?

You are free to try and make this with the car behaviour..

>

> > Most of the math in that example is to prevent the overlapping..

> > All you'd need is the part that does the bullet instead of the follow path..

> >

> > Like this:

> > https://dl.dropboxusercontent.com/u/485 ... rcles.capx

> >

> This is perfect! Thank you so much, a lot easier to read for those of us who are a little lacking in geo/trigan-ometrical knowledge <img src="{SMILIES_PATH}/icon_e_biggrin.gif" alt=":D" title="Very Happy"> I noticed the pathfinding method was a little shaky when the screen is set to scroll to it, I'll be keen to see if the bullet smooths things out. Is bullet a better behavior to use over, say, the car behavior?

>

You are free to try and make this with the car behaviour..

Tried applying your example to mine and the sprite just tries to go backwards for some odd reason: https://www.dropbox.com/s/tddz3vzcet8ya25/try.capx?dl=0

Sorry, can't open that capx, because it uses magicam-plugin..

Sorry, can't open that capx, because it uses magicam-plugin..

Sorry, forgot about that, here's a new one: https://www.dropbox.com/s/1fjgkpdpnv9o9 ... .capx?dl=0