Good to know. I am doing mostly straight line path-solving, so I’m probably a good candidate to use the unbound version. I’ll probably switch back for now and when I get more heavily into optimization, I can evaluate whether I need to use the bounded versions. I don’t think it would affect how I build my levels, regardless, as I imagine it’d be totally fine for me to ship w/ support for multiple bounded navigation managers.
Quick question;
where in the navigation pipeline does the mesh rotation get set? Essentially I want to lock the axis to never rotate in the xy plane (no roll or pitch) because my mesh destruction animation requires no rotation about the xy plane and the pitch glitches it out.
The plugin does not perform any locomotion of its own. All locomotion is routed to your pawn via AddMovementInput (or AddMovementInputCustom if you chose to implement the IDonNavigator interface) by passing the WorldDirection towards the next target in the solution path so your pawn can decide how it wants to get there.
So just check your own pawn’s AddMovementInput behavior; setting Unreal’s native pawn properties like bUseControllerRotationPitch and bUseControllerRotationRoll to false (in Class Defaults) may help if your pawn is using control rotation to drive itself.
Hello , very good job on this Plugin, I’m using it for my project and loving it! =D
I do have a few issues tho, and I hope you can help me sort it out, sometimes my game just freezes when I place a few (1-5) flying Mosquitos around, I did everything I could think of, I made many Decorators to check if the location is within navigable world and if its beneath the landscape, disabled and enabled Multithreading, increased and decreased its values, reduced Query times and all that, still it sometimes just freezes. I can tell its from the navigation because when the Mosquito is either attacking the player, or its setting there doing nothing, it doesn’t lag a single bit.
I’m using 100 Voxel Size and 300x300 Grid that covers my whole map.
Another minor issue is that they sometimes fly around one of the waypoints of the path before being able to continue on it, I have no idea why that happens, but I think it has to do with the Mosquito’s fast speed.
Anyway, I’m sorry to post this just begging for help, I’m really really satisfied with your navigation system overall and I appreciate it very very much. I even added your game to my wishlist on Steam to give it a try !
Thank you very much, cheers.
Are you getting any debug output in the log? There’s a lot of useful info there for this system 
I assume you’re using a pawn derived from the Character class? If so, crank up your “Acceleration” & “Braking Deceleration” values to see if that helps. Also, try increasing the “Minimum Proximity Required” value on the FlyTo node. Finding the perfect combination of speed, acceleration, braking deceleration & flyto proximity can take a little while
@Narg - Agree with rdarcey on both questions.
Only thing I’d add is that even in single-threaded mode the plugin distributes its workload across multiple ticks to guarantee that the game thread is never held up for more than a certain amount. You can configure that amount by lowering “Solver Iterations Per Tick” and see if that helps. The editor build is far slower than the packaged build so the performance in your final game will be much faster. “DebugEditor” mode from Visual Studio is even slower than the normal Editor in case you’re using that.
If the issue still persists, try placing a breakpoint inside the the Navigation Manager’s Tick function to see what it is doing when your game slows down. With that information and the logs, we should be able to diagnose exactly what is happening. My own experience with this plugin has been that initial setup can take a while to get right, but once you’re past that stage everything should just work.
Edit: And thanks for wishlisting my game
Hey there! as those who tried the plugin in 4.15 will have found, its not very happy at all! as such, please feel free to use this FIXED FOR 4.15 source here:
http://www.filedropper.com/donainavigation415
@ thanks loads for this wonderful plugin, feel free to compile+post this version on the front page to save you the bother of fixing it I would but my internet is very slow, I can only upload small files such as this source
- Thanks for that
I’ll upload the binaries after I’ve had a to install 4.15 and test the sample project (still on 4.13 here!)
v1.5 released with 4.15 support!
Plugin and sample project downloads are available at DoN AI Navigation – A free plugin for Unreal Engine 4 – Nature And Life – Drunk On Nectar
Thanks to for the 4.15 migration help!
Extras:
Watch 100 Monarch Butterflies navigate a procedural world using DoN's 3D pathfinding!
watch?v=UYr3xNqxkLU
If you found this plugin useful check out [DoN on Steam](http://store.steampowered.com/app/512460) and consider purchasing it to show your support :)
You can also help by sharing this Monarch Lifecycle video around; it's perhaps the first game to depict an animal's complete lifecycle in full 3D from egg to larva to pupa to adult with 1mm scale accuracy (DoN uses a magnified world) and it could use some visibility :)@, thanks for the 4.15 update! I just sent out a tweet w/ the video and purchased your game, too 
As a quick suggestion, I would think about cranking out some nice animated gifs w/ the #gamedev and #indiedev tags on Twitter, too. They can get a lot more attention than videos if they’re done well. Here’s some good advice on creating them:
I’ve also got a quick question for you!
After many months of no problems whatsover…managed to find another bug! This time, it’s with landscape geo. Basically, when AI units get close to the landscape floor and use a flexible origin, they will sometimes pop below the landscape geo and get stuck cause of the “safe” volumes detected just below the surface, as demonstrated in this image:
Now, this might actually all be working as intended, but can you think of a solution for my use case?
Thanks!
So happy to see the tweet, thanks ! You are awesome
Re: Landscape bug - This is surprising because GetClosestNavigableVolume does a line trace + sweep (via IsDirectPathLineSweep) specifically to ensure that the new vector awarded to the pawn is something it can directly travel to.
If you have a consistently reproducible scenario (if not I suggest setting it up on a new map; easiest way to debug stuff like this), then you can debug the *else if (IsDirectPathLineSweep(CollisionComponent, Location, volumeGuess->Location, hit, bConsiderInitialOverlaps, CollisionShapeInflation)) return volumeGuess; * line to understand why the landscape isn't considered a barrier for auto-correction.
Btw I'm revisiting the plugin and making changes to it after a loong time, so your report has come at an opportune time!EDIT: Cleaned up my posts. I stand by my assessment below I don’t think this issue is due to any custom code I’ve written.
OK…so, it looks like when SchedulePathfindingTask calls ResolveVector to find the origin volume, this check in GetClosestNavigableVolume is what circumnavigates any sweeps and the volume below the landscape is returned as a valid origin.
// Case 1: Given volume is navigable. No further checks required:
//
if (CanNavigate(volume))
return volume;
Also, I’m still using the bound volumes, if that makes any difference. Does that make sense?
Are you sure this is the same scenario where the bot ends up under the landscape?
I ask because if the volume is navigable, the “flexible origin goal” stuff won’t even get called and your pawn will never be teleported anywhere, leave alone, under the landscape.
The popping that you describe can only ever happen with forced teleportation and the only place which does that happens below the code block you’ve highlighted.
I’m positive that when ADonNavigationManager::SchedulePathfindingRequest calls ADonNavigationManager::ResolveVector on the Origin in this snippet that it leads to my AI unit popping.
if (!bIsUnbound)
{
// Resolve origin and destination volumes
originVolume = ResolveVector(Origin, CollisionComponent, QueryParams.bFlexibleOriginGoal, QueryParams.CollisionShapeInflation);
destinationVolume = ResolveVector(Destination, CollisionComponent, QueryParams.bFlexibleOriginGoal, QueryParams.CollisionShapeInflation);
I verified that by adding this if (tweakDir.Z < 0.f) continue; modification in the ADonNavigationManager::ResolveVector snippet below. The AI unit does not pop below the surface with this quick hack.
if (bFlexibleOriginGoal) // we could filter this adaptation to only consider bInitialPositionCollides scenarios, but there are some edge cases which aren't covered with that approach
{
UE_LOG(DoNNavigationLog, Error, TEXT("Pawn's initial position overlaps an obstacle. Pathfinding will not work from here, pawn needs to move to a nearby free spot first."));
for (auto tweakMagnitude : AutoCorrectionGuessList)
{
for (const auto& tweakDir : locationTweaks)
{
if (tweakDir.Z < 0.f)
continue;
FVector tweak = tweakDir * tweakMagnitude;
volume = GetClosestNavigableVolume(DesiredLocation + tweak, CollisionComponent, bInitialPositionCollides, CollisionShapeInflation, bShouldSweep);
if (volume)
{
UE_LOG(DoNNavigationLog, Warning, TEXT("Substitute Origin or Destination (%s offset) is being used for pawn to overcome initial overlap. (Can be disabled in QueryParams)"), *tweak.ToString());
DesiredLocation = DesiredLocation + tweak;
return volume; // success
}
}
}
}
It looks like the actual popping is happening in this snippet from ADonNavigationManager::SchedulePathfindingRequest:
// Flexible Origin adaptation:
if (Origin != Actor->GetActorLocation())
{
UE_LOG(DoNNavigationLog, Warning, TEXT("Forcibly moving %s to new origin for viable pathfinding. (Can be disabled in QueryParams)"), *Actor->GetName());
Actor->SetActorLocation(Origin, false);
}
Aha! The wily edge case emerges at last.
The bug is as follows:
“Flexible origin goal” computation relies on GetClosestNavigableVolume for verification of a suitable teleportation point. However that function will never perform a sweep from “desired-location” to “best-guess-location” because it has no knowledge of those entities. It just samples a given location and returns the closest navigable volume. So if a guess-list volume is deemed navigable and if that volume happens to be under the landscape, BAM! the end-result is what your poor bot had to endure 
Solution:- Refactor the entire flexible origin loop into a new function, perform verification of teleportation target inline:
- Check if a guessed volume is navigable
- If so, perform a IsDirectPathLineSweep test thus ensuring the bot can actually teleport there.
If you don’t need these changes urgently, I’m working on the plugin this week and can upload a fix for this in a few days.
Thanks for this report! I think a lot of people will benefit from this fix.
Nice! Glad you’ve pinpointed it I def don’t need the fix urgently, so I’ll wait until you’ve got something cooked up Thanks, @!
Trumpets blare! Drumrolls resound! *Two dancing Grebes entwine in ecstasy!
A distant rumble erupts in the skies! The rapid trills reach a blistering crescendo!
Unreal Marketplace release for DoN's 3D pathfinding happening next week!
All, I'm pleased to report that this plugin which has enjoyed a humble home in this community tools section for over one year now, will at last, formally release on the Unreal Marketplace! This is happening next week!
And, it will still be free :)
To celebrate the marketplace release the latest version has several improvements and bugfixes gone into both the plugin and the sample project.
Do check it out next week!
-@ that’s amazing. As someone that’s enjoyed this plugin for coming up on a year now, I encourage you to charge something for all the work you’ve done! Knowing you, it’d be a modest amount and probably less than what you deserve, but you should be compensated in some way for this. If not directly from sales on the marketplace, I hope it catches up to you at some point in some way!
Thanks for everything <3
Thank you @rcdarcey This plugin was originally made as a gift in return of everything I’ve learned/received from the Unreal community, Epic, sites like Stackoverflow/etc, so I figured it should remain a gift!
I hope so too! A few high-profile Youtubers covered my game on Steam recently and that’s brought a lot of sales in so maybe what you hoped for is happening slowly but surely
–
I’m also working on a commercial plugin around a tricky subject matter that many in the community have asked for with no public solution available so far.
If i manage to pull off that plugin (can’t disclose as I’m not there yet!) I will be charging an arm and a leg for it when I sell that on the marketplace
NICE! That’s awesome. Good to hear
Good on you 
Look forward to seeing what you have cooking!
Lastly, have a question…this free plugin for DonNavigation, does that include source code? I actually haven’t looked into how plugins are integrated into the marketplace. Wondering if you just get the exe and that’s it.