[BEHAVIOR] EasyStar.js pathfinding for tilemap

Hello, in the example that you offer on the first page now the blue path does not appear.

This happens with the latest version 1.02

Move the "Node -> Destroy" action from line 2 down to line 3.

This example was created with a previous version of EasyStarJS. The asynchronous aspect of the plugin changed in a way that made the node sprite get destroyed AFTER they were created (in the same tick), so it was never visible. You could also only change the "asynchronous" property to "no", and the node sprites would appear again.

Is there possibility you add "Dijkstra's algorithm"?

Unfortunately no. The whole plugin rely on the EasyStarJS library which is an A* pathfinding algorithm javascript implementation.

Hello!

Love this behavior! It simply works perfectly.

I am trying though to find the possibles moves on a grid like this :

but it is very costy.. It takes like 1 second and a half on mobile, and like 0.3 seconds on pc, using the behavior.

I am looking for the paths in a loop from -unitMoveRange to unitMoveRange. Of course every tile has a different pathCost.

Any trick or advice on how to do it... better?

Using a breadth-first search might be more appropriate to find all possible moves, and then I guess you could use the pathfinding only once to go to the selected tile.

Nice Plugin, fast.

The sample file is not showing the red path like in the live example.

Also, I noticed a bug when using the behavior on a tilemap object. If you want to change a tile on the right side, near the edge, it won't work. I.E., in the same sample file with the red path, if you reduce the size to match the screensize, and right click to change any tile it will not detect the event.

Thanks — It feels like I corrected this particular bug for the third time! That's what you get for copy pasting code instead of working with reusable code...

I finally updated the basic example to behave correcly with the newer version of the plugin (just had to configure the behavior to synchronous mode).

I also went ahead and added an expression to retrieve the cost from a tile coordinate and a condition to test whether or not a tile is walkable.

New version here.

Bumping this topic for another new version.

I stumbled upon a nasty bug that made the plugin rebuild its array representation of the tilemap every tick instead of only on the first tick. This could have caused quite a bit of slowdown when working with large tilemaps.

Added a new condition : "Is tile walkable from". Basically the same as "Is tile walkable" but this one take into consideration directional conditions and thus need another coordinates pair. It will always return false if the two pairs of coordinates aren't neighbours.

Also removed the jQuery dependency by removing the jquery.map() call and using array.map() instead. All modern browsers should now support this.

New version here.

Magistross I don't suppose there's a way to have the tilemap's collision polygon block the path? My tilemap is mainly walkable, but has walls to the side. At the moment, the objects will happily walk through walls, which I'm trying to avoid.

Is this only useful for entire tiles being walkable or unwalkable? No way to default all tiles to walkable and collision polys to unwalkable?

There is nothing that stops you from adding all tiles as walkable except the walls.

I think the problem I'm having is that my wall needs to be only about 5 pixels across, while the floor tiles need to be approximately 32x32.

This possible with this plugin, or do all tiles need to be the same size?

A tile is either an obstacle or not.

However, a few options are open to you.

First, you could add directional conditions on wall tiles and its opposite tile, so an entity could walk along it but not through it.

Like this (grass tiles act as walls) : https://www.dropbox.com/s/4xaq1y5yt97hi ... .capx?dl=0

Or, you could use a new tilemap, with smaller tiles, where all pathfinding is done.

Like this : https://www.dropbox.com/s/9ammml47pelh8 ... .capx?dl=0

Is there a way to find out which direction a sprite would have to take in order to get to a target.

What I am trying to do is work on turn-based pathfinding on a grid.

So far the what most of the A* plugins lack is a direction a sprite can take on a grid. Unless somebody else has found that solution. Thanks for making the C3 plugin.

Well, this is a simple operation. If you want to figure which direction a sprite should be from one position to another, you just need to compare the coordinates.

Position2.X > Position1.X => Right

Position2.X < Position1.X => Left

Position2.Y < Position1.Y => Up

Position2.Y > Position1.Y => Down

And a combination of those for diagonals if you allow them.