hey Guys im trying to use the plugin at 4.13, but im getting always this red node after close and reopen my project. Someone have issues like that?
Thanks
Wanderson
I donāt know either, hopefully someone is able to test and report, Iām busy with other work atm.
Iāve never seen anything like this. Sounds like the engine is not able to find a properly compiled version of the FlyTo class.
Is this a blueprint-only project or C++? Have you installed the plugin as a project-level plugin or engine-level plugin? Your simplest option would be to remove the plugin and copy it again (either from the the sample project or directly from the plugin zip file). In case weāre dealing with corrupted files of some sort, try downloading the plugin and/or sample-project again.
I discover the issue, I just put the command at .uplugin file and works great.
"LoadingPhase": "PreDefault",
@wandersonp - thanks for posting the solution 
I havenāt seen this issue yet, but still useful to know.
Can confirm it works with 4.14. I thought I needed to download the engine source code but it turns out if you just make a new 4.14 c++ project, add the plugin folder to the directory, open and rebuild it will work nicely!
@formatt - thanks for confirming! Glad to hear it works
@, just wanted to suggest a couple of small code changes that seem to be working well for me.
First, I implemented support for setting AI focus to the next fly to point, but was getting weird behavior on direct flight paths. Specifically, there were always 2 flight segments when I was just expecting a single segment that brought you to the final goal. It made for twitchy focusing right at the start of the flight sequence. Basically, adding the origin seems unnecessary in this case and the CUSTOM CODE edits below seem to have cleaned everything up for me.
bool ADonNavigationManager::SchedulePathfindingTask(AActor* Actor, FVector Destination, UPARAM(ref) const FDoNNavigationQueryParams& QueryParams, UPARAM(ref) const FDoNNavigationDebugParams& DebugParams, FDoNNavigationResultHandler ResultHandlerDelegate, FDonNavigationDynamicCollisionDelegate DynamicCollisionListener)
{
...
// Do we have direct access to the goal?
FHitResult hitResult;
const bool bFindInitialOverlaps = true;
if (IsDirectPathLineSweep(CollisionComponent, Origin, Destination, hitResult, bFindInitialOverlaps))
{
FDonNavigationQueryTask task(FDoNNavigationQueryData(Actor, CollisionComponent, Origin, Destination, QueryParams, DebugParams, bIsUnbound ? NULL : VolumeAt(Origin), bIsUnbound ? NULL : VolumeAt(Destination), Origin, Destination, FDonVoxelCollisionProfile()), ResultHandlerDelegate, DynamicCollisionListener);
//-------------------------------------
// CUSTOM CODE
//task.Data.PathSolutionRaw.Add(Origin);
//-------------------------------------
task.Data.PathSolutionRaw.Add(Destination);
if (!bIsUnbound)
{
//-------------------------------------
// CUSTOM CODE
//task.Data.VolumeSolution.Add(task.Data.OriginVolume);
//-------------------------------------
task.Data.VolumeSolution.Add(task.Data.DestinationVolume);
}
Second, in that same function, I made this edit to stop AI units from popping to the origin. Just allowing them to fly to it works a lot better in pretty much all of my use cases since the only time this really triggers is when the AI unit is too close to a wall/ceiling/floor. The new origin is almost always a clean sweep from the current location.
// Flexible Origin adaptation:
if (Origin != Actor->GetActorLocation())
{
// -------------------------------
// CUSTOM CODE
if (IsDirectPathLineSweep(CollisionComponent, Actor->GetActorLocation(), Origin, hitResult, false))
{
UE_LOG(DoNNavigationLog, Warning, TEXT("Adjusting %s fly to origin to new location for viable pathfinding. (Can be disabled in QueryParams)"), *Actor->GetName());
}
else
{
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);
}
// -------------------------------
}
Anyway, just wanted to share! Hope your early access is going well 
@rcdarcey - both look like great additions! Iāll incorporate them when I find some time to thoroughly test these; just so many edge-cases with something like this.
Drunk On Nectarās EA is going splendidly! Just the right level of initial interest for managing community engagement/expectations while still sustaining the gameās growth. A plant thrives when it is provided just the right amount of water, not when it is water-logged
So carefully climbing upwards like this little spider!
[screenshot]http://www.drunkonnectar.com/wp-content/uploads/2016/12/A-Spiders-Magical-Journey.jpg[/screenshot]
![http://www.drunkonnectar.com/wp-content/uploads/2016/12/A-Spiders-Magical-Journey.jpg[/screenshot]](http://www.drunkonnectar.com/wp-content/uploads/2016/12/A-Spiders-Magical-Journey.jpg%5B/screenshot%5D){kind=link}
For those interested my sig has a link to the game.
Check it out on Steam for some Nature Sandbox action!
Sorry if this was already discussed but, Is there any plans for a 4.14 version?
See this post.
Hi , my project will require a custom path-finding solution and I just wanted to check if this plugin is suitable for me before I dive into A* algorithms. I have a procedural planet world with radius ~5000 that uses a geodesic grid as tiling. Using custom gravity the player can run all the way around the planet but as you might expect I canāt use native UE path-finding tools.
Is it possible to use this plugin to simulate an AI character walking across the surface of the planet somehow? If I can use the plugin to create the effect of a walking animation matching AI xyz rotation relative to the position on the sphere where the āflyingā AI is close enough to the planet mesh such that they appear to be walking, that would be ideal.
Either way, a fantastic resource and youāre a hero for making it available free of charge.
If you already have some sort of grid you should be able to easily implement some sort of A* algorithm for it. You really donāt need anything like this plugin for pathfinding
@ In the long run writing a solution that is tailor-made for your projectās needs will indeed serve you better, especially if youāre already comfortable with coding and implementing A*, etc.
Without knowing what kind of obstacles your A.I need to navigate around itās hard to say if the plugin will save you some time, but in general, adapting a Flying A.I solution to Walking A.I is likely to cause issues.
It may be worth checking out ADonNavigationManager::TickNavigationSolver though to see the pluginās approach to A* so you have an idea of what to expect.
And thanks for the kind words
Thank you both for the insight. The reason I ask is that I have no experience with c++ code and the grid system was a commission. I donāt need anything particularly exotic, so I was wondering how difficult a simple a* is to implement and if it is something a beginner to c++ could take on with the right research?
If youāre comfortable with coding/algorithms (any language) A* itself should be doable; the most lucid A* references Iāve found online are this one and this one (courtesy redblobgames.com)
IMO the real challenge is in harvesting and supplying the collision data of your procedural world into a navigation graph that your A* can actually consume. Thatās why I asked you about the complexity of the obstacles your A.I. needs to navigate around. You donāt just need A*, you need precise knowledge of which world coordinates on your world/grid correspond to areas which are navigable and the ability to convert that into a graph that keeps up with a changing procedural world.
So ultimately Iād reconsider whether your A.I. really needs a full-fledged pathfinding solution.If you can get away with simple line-tracing heuristics then itās a very practical stopgap arrangement until youāre ready to tackle a full-blown solution.
Thatās the approach Iāve taken for ā360 degreeā walking A.I. in my own project too. If I had the time Iād make a video showing tiny creatures smartly navigating dense foliage: spherical structures like flowers, 120 degree plant stalks, etc but I have little time on my hands for Dev Diaries or blogs these days
@formatt - would you mind walking me through how you got it to work with 4.14? having some difficultyā¦
Quick question for you @ ā¦
Is there any reason why multiple navigation volumes arenāt supported? I realize code would need to be updated and I think I can easily make some small tweaks to support itā¦mainly wondering if there are any significant perf/memory costs. I have āpocketsā of areas in my levels that need navigation, but theyāre very far apart so I would prefer not to use a single volume.
If you canāt think of a reason why I shouldnāt do this, Iāll post my solution here after I get it working 
Thanks!
@rcdarcey - You probably meant multiple navigation managers.
This should be as simple as fixing UDonNavigationHelper::DonNavigationManager to smartly pick up the closest/most relevant manager based on proximity to pawn (and therefore adding an FVector input parameter) and by updating any code that fetches the Nav Manager (eg: FlyTo task or your custom AI code) to use that function. I havenāt gone in this direction yet as Iām fully relying on the Unbound manager these days and that works better when your A.I. absolutely needs to be able to pathfind from anywhere, no limits (ideal for sandbox gameplay). Of course, this is a great idea for your setup.
Would love to see some videos of your game btw!
@JordanAriel - Are you still having issues? This should be as simple as creating a new C++ project, creating and copying the plugin into a Plugins directory under project root and letting the engine recompile the whole thing, so you can copy the compiled plugin folder back out to your project.
I do not have 4.14 installed, otherwise I'd try to upload a new version when I find some time (and free space on my comp!)Yes, I did! Sorry about that
This is exactly what I was thinking of doing. I had switched over to the unbound manager for a while, but switched back to the bound volumes when I needed access to some debug info thatās only available with the bounded versions. In addition, Iām concerned about the runtime hits to perf with the unbound versionsā¦tho I havenāt actually taken any measurements so Iām not sure exactly how worried I should be about it. Do you have any specific figures there? Maybe Iāll just switch back over to the unbound managers again instead of making these modifications to the bounded versionā¦
My hope is to release a short teaser this spring! That teaser is mainly to serve as an art/music/audio high bar and wonāt feature many details about the gameplay, but I may release a much less visually refined āwork in progressā gameplay video at the same time. Iāll update this thread with links, especially if I manage to showcase how Iāve utilized this plugin!
Sounds good, looking forward to it!
A tip to anyone testing performance with the Unbound manager: donāt be discouraged by in-Editor performance. It is much faster in a packaged build with no debug info (i.e. Shipping). The default tick values are very conservative (to prevent FPS drops) so your A.I. queries may start timing out if you have many of them, but you should be able to tune the āiterations per tick unboundā to a reasonable value for your needs.
I recall a user reporting earlier in this thread that the Unbound manager was too slow for them but that was not a Shipping build AFAICT.
If your A.I. does mostly straight-line navigation with only a few complicated path-solving journeys here and there then itās even better.