DoN's 3D-Pathfinding / Flying-AI system (with full source!)

[wandersonp]

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

[VSZ]

Has anyone tried compiling it for 4.14 yet? Any luck?

I don't know either, hopefully someone is able to test and report, I'm busy with other work atm.

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'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.

[wandersonp]

I discover the issue, I just put the command at .uplugin file and works great.

"LoadingPhase": "PreDefault",

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.

[VSZ]

[MENTION=407007]wandersonp[/MENTION] - thanks for posting the solution I haven't seen this issue yet, but still useful to know.

[formatt]

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!

[VSZ]

[MENTION=32939]formatt[/MENTION] - thanks for confirming! Glad to hear it works

[Ryan Darcey]

[MENTION=14603]VSZ[/MENTION], 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

[VSZ]

[MENTION=43607]rcdarcey[/MENTION] - 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.

Hope your early access is going well

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]

For those interested my sig has a link to the game.

Check it out on Steam for some Nature Sandbox action!

[Danii_Dev]

Sorry if this was already discussed but, Is there any plans for a 4.14 version?

[VSZ]

See this post.

[andreasmaragakis]

Hi VSZ, 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.

[MatzeOGH]

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

[VSZ]

[MENTION=645005]andreasmaragakis[/MENTION] 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

[andreasmaragakis]

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

[MENTION=645005]andreasmaragakis[/MENTION] 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?

[VSZ]

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