Not yet I’m afraid - not formally at least. You could override AddMovementInput for your pawn or implement my AddMovementInputCustom interface (either of which the “FlyTo” node will use) with your own neighbor avoidance logic and depending on how complex your paths are this might be a viable strategy.
Another option is to use the dynamic collision repathing that I have for regular meshes (dynamic obstacles) for the neighbor pawns (by adding “Pawn” to “Obstacle Query Channels” in the manager) but there are some messy complications with this:
-
It would recalculate paths each time an obstacle occupies it, which is great for regular obstacles but not very efficient for neighbors who’re travelling along a similar path as you (because of potentially frequent recalculations of the entire query).
-
The system requires both pathfinding origin and destination to be in empty space and if not, it will reject the query. Now if we add “Pawn” as a collision object type and your neighbor has reached the goal before you (thus occupying space around the goal) then your pathfinding query will simply fail with a message that the goal is invalid and cannot be reached!
In the sample project the bots often merge into each other because of lack of neighbor avoidance and also because their pawn collision is set to only overlap pawns instead of blocking them.