Asynchronous Pathfinding API

[Dyllan]

I've put together a 3D A* Pathfinding API that takes 2 locations ( start and destination ) and returns the block locations in a list of "Point" containers. There is a max computation time of 5 seconds that limits any super large calculations. Also identifies when there isn't a solution. All of this is done Asynchronously so you're going to have to use a callback function to handle the results. You just have to use my "AfterPath" interface exactly how you would use Callable.

https://github.com/McCrearyD/MCPathfinder is the example repo, (jar found in target folder) use /pathto (x) (z) to test it out.

https://github.com/McCrearyD/MCPath...inder/src/com/dyllansplugins/mcpathfinder/api contains all of the code that you will need for your implementation in another plugin.

Like it? I would appreciate if you star my repo!

 

[Dyllan]

What

what what

 

[GotoFinal]

reading map data in async is not thread safe, might cause issues with chunk loading/unloading, or just crash. (some spigot/bukkit forks also use additional check to ensure that map access is sync)
Or in best case that path will be already outdated after calculation without any information about that.

Also why you didn't just use Consumer<List<? extends Point>> no need for separate interface
Also you could just use LinkedHashSet instead of doing that weird manual checks

 

[Dyllan]

reading map data in async is not thread safe, might cause issues with chunk loading/unloading, or just crash. (some spigot/bukkit forks also use additional check to ensure that map access is sync)
Or in best case that path will be already outdated after calculation without any information about that.

Also why you didn't just use Consumer<List<? extends Point>> no need for separate interface
Also you could just use LinkedHashSet instead of doing that weird manual checks

Reading map data is thread safe ( worlds are stored in a static context ), writing however is not. I do it on a separate thread because on the main one it causes a short delay in all processes since 3D A* is a fairly beefy algorithm for large spaces, which a little chat delay is better than full on haulting. The separate interface was for simplicity since I use it in a few other projects. Also, LinkedHashSet is a good idea, completely forgot about it, thanks.

 

[GotoFinal]

Reading map data is thread safe ( worlds are stored in a static context ), writing however is not. I do it on a separate thread because on the main one it causes a short delay in all processes since 3D A* is a fairly beefy algorithm for large spaces, which a little chat delay is better than full on haulting. The separate interface was for simplicity since I use it in a few other projects. Also, LinkedHashSet is a good idea, completely forgot about it, thanks.

reading map data is not thread safe, it is just "kind of safe" as with current code of spigot the only possible issue is returning invalid id in few rare cases, and issues with chunk loading if used on not-loaded terrain. So it might work fine, but it is not thread safe it just happens to work without bigger issues on current spigot version.

 

[Dyllan]

reading map data is not thread safe, it is just "kind of safe" as with current code of spigot the only possible issue is returning invalid id in few rare cases, and issues with chunk loading if used on not-loaded terrain. So it might work fine, but it is not thread safe it just happens to work without bigger issues on current spigot version.

I agree, it is "kind of safe". There are minor cases where the main thread could be writing to the world while the secondary thread is reading that particular block, however that would be a perfect storm. Minecraft uses multithreading to handle processes like mob AI because if that process takes up a ton of time it would hault others (also chat but for a different reason). Same thing with 3D A*, it takes a decent amount of processing power for areas greater than 30x30 block areas. Also all of the data throughout the process is held in locations, not blocks. And locations are static, the locations are only read into blocks when deciding whether or not that block is air, and even then I added null checks. So the worst case scenario is someone places a block where the algorithm has deemed an air block, and gives 1 or 2 locations that are not valid places to move because they're occupied.

I always take great consideration for shared variables when it comes to multi-treading. Great talking with you about it I always like discussing these issues.