I would like to upgrade to the beta as it seems to fix the issue, but I have made a lot of changes to the source code to improve performance and expose certain things for my specific use cases of A*, which I would like to continue to be able to. Would it be possible to receive the Beta as a regular plug-in folder instead of having to pull it through the scope registry?
You can download a unitypackage at A* Pathfinding Project if you click “Show Older Versions”, instead of using the npm registry.
If there are some things you think would be useful if upstreamed, I’d be happy to take a look at them
Ok, yeah, thank you! I didn’t see that button at the bottom of the page. Apparently, my colleague did see it, but got confused as there was no Download button if you don’t put the invoice number in. Maybe you can add a note there somewhere that explains this for future people struggling with this
I have given some feedback via your questionaire, but there is not one specific thing that I have that needs to be upstreamed. As stated, most of my changes are specific to our use case.
And to restate my other question: Is there a version somewhere without Burst support? We have been given our Errors through the Burst compiler regardless of whether we have Burst disabled or not. Also, the setting for turning Burst on or off seems to not be versioned through Git.
There’s no version without burst support I’m afraid, unless you want to use an older version of the package. Burst is pretty heavily used to improve performance during heavy operations in the package these days.
Thanks for the feedback in the questionnaire. Just a small response to that:
I saw that OnTargetReached was deprecated in the beta and replaced by querying a bool instead, I think that is outrageous when I want to react on exactly the moment I reach my target. I don't want to check a bool every frame to see if it has changed
I deprecated this because different people had very different requirements for this. Should it trigger again if the path is recalculated? Should it trigger even if the destination is moved only a tiny amount? Should it trigger again if the agent is pushed away from the destination, and then it moves back to it? Besides, internally it basically polled a boolean just to send the event, which was unnecessary work if this event was not interesting for the user.
For these reasons, I opted for letting the user poll the reachedDestination boolean, as it can be handled in a more flexible way (even though it is a tiny bit more verbose).
I have also tried to move away from subclassing as a method of extending the package, and instead tried to move towards exposing things in a way that allows separate components to be added so that they interact with the movement scripts instead of inheriting from them.
I wish there were more features for realistic idle movement on navmeshs. For example that you can set what slopes the agent can traverse, and if a hill is too steep, that they will go around it instead of stupidly trying to get up the hill, running into an invisible wall.
That’s what the recast graph is for. It will allow you to automatically exclude steep regions from the navmesh. The navmesh graph is for when you want full control over how the navmesh looks.
Thank you for the extensive answer. I haven’t spent too much time looking into the recast graph, maybe I will catch up on that.
As for the boolean, I would have expected a private SetReachedDestination(bool value) method that triggers the TargetReached event when the value is changed from false to true.
