I own A* Pathfinding Project pro
Units do not avoid each other at all.
Each unit has:
- RVO Controller
- Funnel Modifier
- RVO Simulator
- AStarPath > Recast Graph
Destination is being set with RichAI.destination = value
What am I doing wrong?
That’s strange. You do seem to have all the right components.
Are you sure you don’t have any other components that are modifying the positions of the agents?
You could also take a look at the example scenes to see how they have configured everything. Unfortunately there is no example scene that uses both RichAI and RVO though.
Which version are you using?
Hi, I bought your asset 2 days ago. I am focusing now on moving NPCs to avoid eachother or dynamic objects. I saw Local Avoidance as one of the most important functionalities for me. I am curios what are limitations to use local avoidance.
I wanted to buy previously another asset Dynamic Obstacle Avoidance because of the movie and object avoidance: https://www.youtube.com/watch?v=1DgPuwl-zUA but A* Pathfinding Project Pro seems to be more sophisticated and mature. Am I wrong?
I’ll double check if any of the other components modify position but as far as I know they don’t.
The units do have kinematic rigidbodies attached to them.
Latest version Astar as of yesterday updated through editor window from latest asset store version. So it’s a fresh install.
Turns out you where right, there was a script modifying the transform.
I was using a 3rd party integration that sends move/stop commands to the unit, which I assumed was implemented properly to simply notify the AI where to go. I wrote my own integration that accomplishes this.
The units avoid each other now but still getting fairly weird behavior.
Occasionally units simply refuse to move, sometimes after other units have moved maybe 5-10 seconds later they will move to the old destination but not the new one I just assigned them.
I noticed a bunch of debug log/warnings being spammed constantly even if every unit is stationary including path complete/failed
Okay, how do you make them move? What is the specific code that you are using? Also, what are the ‘path failed’ messages saying? I have a feeling that you are forcing the paths to be recalculated so often that the previous path request never has time to finish, so it is canceled all the time when a new one comes in.
How much logging should be done can be controlled by the A* Inspector -> Settings -> Path Log Mode setting.
I tried a few variations of the code but at it’s simplest form it’s this
OnMovementOrderEngage gets called once on every unit when I right click.
protected override void OnMovementOrderEngage(Vector3 destination)
if (ai != null)
ai.destination = destination;
At the start there are no path debug messages but as soon as I click once they spam forever.
How many log messages that will be logged is controlled by the A* Inspector -> Settings -> Path Log Mode setting. You can set it to None to disable it completely.
Are you sure that code is only called once on every unit when you right click? Are those ‘Path Failed: Canceled by script’ messages showing up even when you haven’t ordered them to move for a long time?
Also, what does base.OnMovementOrderEngage(destination); do?
Something interesting I noticed is if I only command a single unit it consistently follows the path, but if I select 6 units and tell them all to move, most of the time 1 or 2 units will sit there doing nothing for a while, but if I let the game sit for a while sometimes the stationary units will move 5-75 seconds later.
I turned on the debug logs to try to debug this problem and showed you the logs in case it helps. Are you saying constant Path Completed/Failed without changing destination is normal? I can leave the game idle for a while and come back and the debug messages are over Path Number 10,000 including Path Failed.
base.OnMovementOrderEngage is simply events and callbacks.
protected virtual void OnMovementOrderEngage(Vector3 destination)
private void ChangeDestination(Vector3 position)
targetPosition = position;
if (DestinationChanged != null)
That seems strange, that ‘Path Failed: Canceled by script’ message should only show up if some script is calling the AIPath.SearchPath method. Do you think you could add a Debug.Log in that method to see if it is getting called by anything?
Do you mean AIBase.SearchPath?
That gets called every frame that shouldReclaculatePath is true by RichAI.
repathRate is currently 0.5, so SearchPath gets called approximately every 0.5s on every AI.
Yeah, AIPath inherits from AIBase, so.
Okay, but excluding those cases. The shouldRecalculatePath property explicitly makes sure that it does not call the SearchPath method in a way that would cause that error message (i.e. it waits until the last path has been calculated before it tries to start a new one). You could probably test it by setting the repathRate to infinity.
CancelCurrentPathRequest never gets called if repathRate is infinity.
I can command the units perfectly once but then they ignore all future commands, which I’m guessing is expected.
Here is the debugger when CancelCurrentPathRequest gets called by AIBase.Update with a repathRate of 0.5
…Strange. Are you calling Seeker.StartPath from some other script? That’s the only way I could see that happening.
The only time StartPathInternal gets called is the following callstack
Using Seeker.StartPath instead of RichAI.destination seems to fix the problem.
I’m not sure what’s going on here. Maybe it’s a bug in the package, maybe it’s some side effect of something else you are doing. Do you think it would be possible for you to share your project with me so I could take a look at it?
I am having issues with 2018.3 as well. After object spawned, it takes 5-30 seconds for them to start moving. Their target does not seem to get updated. They only go to the first position they eventually started seeking to. (I have them following the player and update the destination 10 times a second).
This all worked fine before I updated to the official 2018.3 release. Problem does not appear in editor. I am building to IL2CPP and .net4.