my PC 
Intel Core i7-7700K CPU @ 4.20GHz
Hmmm, I guess we canāt consider this as a weak device. What you think about the results so far?
Tests have shown that calling set_costs() + find_path() can be done without worrying about performance. no matter on which device it is done right?
sure. 200000 iterations are quite high. it should be safe to use it on real-world scenarios .
Iāll check out your test files tomorrow, maybe I can improve a few things(maybe doesnāt need to)
Finally I got time to fixed this little thing
Updated to v 1.0.2. Added astar.toogle_zero. Default value is false so it is backward compatible.
4 Likes
Hi,
First of all thank you for the great extension
Just want to let you know, that on current master (I noticed there are some changes cca hour ago) the pathfinding seems to be broken. I have pathfinding setup only for four direction
I tried to refetch version 1.0.3 and there it seems to be working
Only change I did is
astar.use_zero(true)
as in version 1.1 as the default is now false
1 Like
New version 1.1.0
This is a major release. Consider it a Beta version. The best way to test everything is to build something with it, so new examples are on the way. I hope to share a few basic examples and one complete turn-based example in the coming weeks. There might be some fixes.
Feel free to open an issue if you encounter any problems.
What is new
- Now support odd-r, even-r, odd-q and even-q hexagonal grids.
- Entities: You can now target entities like potions, chests, or enemies, which were not possible to solve on the map before. You can toggle
astar.use_entities()before calling theastar.solve()andastar.solve_near()methods.
As you can see in the example above, tile 4-6 is occupied, which was not possible before. Additionally, the same entities are available on different tiles
astar.solve() only includes the end/last target tile to the path result. Other entities along the path stays as not passableā¦
astar.solve_near() includes all entities from entities table.
- Partial code refactoring(nearly %30) for better readability, performance improvement(minimal) and Defold compatibility. Iāll continue to improve it. Almost everything is now preallocated. You may hit the limits. If so, feel free to open an issue
-
astar.print_map()added. You can print the latest map state for debug purposes. It may not look appealing, but it can be quite useful. -
astar.solve()andastar.solve_near()now also returns tile content ID. -
astar.map_vflip()andastar.map_hflip()added. You can now flip the map. It might be helpful when importing maps from third parties, such as Tiled. -
astar.reset()added. It cleans up everything. - Optional vertically flip map added to astar.setup().
- API Documentation updated.
!! BREAKING CHANGE !!
I try not to break anything, which is why I had to make some tough decisions. So far, there is only one breaking change. Except for this minor change, even my 5-year-old examples still work.
The default value for tables and tile positions starts at 1. For backward compatibility, you can simply toggle it in astar.setup() or by using astar.use_zero(true).
Toss a Coin to Your Witcher 
If you find my Defold Extensions useful for your projects, please consider supporting it.
Iād love to hear about your projects! Please share your released projects that use my native extensions. It would be very motivating for me.
About .script_api file update
Iām sorry, but I really dislike YAML (and other tab-based languages, including Python) files. If youāre using the built-in editor and need autocomplete, please consider contributing to help me with this.
What is next
Iām considering non-blocking (async) solvers. Nothing is planned yet, and thereās no ETA. I need to do some research on this.
9 Likes
Ah, you are fast I just update the new version and post a release notes
Is it OK now when you set astar.use_zero(true) ?
You could try generating it? For extension-steam I created a Python script which parses cpp, h and lua files in search of annotations such as this one:
It puts all of them in a json like this one: https://github.com/defold/extension-steam/blob/master/api.json
And then uses that json and a Mustache template to spit out markdown and a .script_api file:
- generatedocs.py: https://github.com/defold/extension-steam/blob/master/generatedocs.py
- api_script.mtl: https://github.com/defold/extension-steam/blob/master/api_script.mtl
- api_markdown.mtl: https://github.com/defold/extension-steam/blob/master/api_markdown.mtl
You should be able to copy the above three files and make a few tiny changes to get it to work for your project (assuming that youāve annotated your code properly).
1 Like
Unfortunately, no, unless I get paid for the project(cause Iām lazy).
Iāll consider it. Thank you.
I tried my old examples, and they worked well, but they all use 8 directions. Now, Iām going to see if thereās something different for 4 directions. Iām on itā¦
@septumca I just pushed the fix for this. It wasnāt related to 0 indexes; I simply forgot to set the default map type to classic. This is why your path zig-zags. Sorry about that It should be fixed now, if you want to keep 0 indexes, you can use astar.use_zero(true)
2 Likes
It works perfectly now
Thank you for quick fix
2 Likes
New Hexagonal example is here:
Test it: defold-astar-hex-example 1.0
Art Credit: Kenny
You can set the map type to odd-r or even-r. odd-q and even-q types are not supported in this example.
Just set the map_type variable on main.script file accordingly.
-- SET IT TO -> astar.HEX_EVENR or astar.HEX_ODDR to see the difference
-- See: https://github.com/selimanac/defold-astar?tab=readme-ov-file#astarset_map_typetype
local map_type = astar.HEX_ODDR
7 Likes