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

[VSZ]

what about a Pawn w/ a UFloatingPawnMovement component?

That's what the sample project bots use. They inherit from ADefaultPawn (which uses the floating pawn movement component). Flying template doesn't use a dedicated movement component IIRC.

Also interested to hear about what setup others are using.

[Ryan Darcey]

Flying template doesn't use a dedicated movement component IIRC.

Yeah, they don't. I was really surprised about how little was leveraged from the engine for the pawn in the flying project template.

[Ryan Darcey]

[MENTION=14603]VSZ[/MENTION], I spent a few hours looking into it but wanted to get your opinion...is it non-trivial to get a "FlyToLocation" type command that's similar to the "MoveToLocation" command in the AIController class? Basically, I tried to dissect what's going on in BTTask_FlyTo and created a "FlyToLocation" command, but AI unit isn't budging. Don't want to waste your time debugging so I won't post the code...just want to get a recommendation on whether or not it's something that should be relatively straight forward. If I do figure it out, I'll post the solution here

[VSZ]

Whatever functionality the FlyTo node provides can be easily accomplished from any blueprint or C++ class. Just use the plugin API to 1) schedule a query 2) receive an event when it's complete 3) listen to dynamic collisions and course-correct (only needed if you're really interested in dynamic obstacles).

Check out Example 4.A in the sample project (BP_Navigator_Dummy) which does exactly this from inside a Pawn's blueprint (the pawn BP is the bizarre cone shaped thingee floating in the air )

Any reason you don't want to use behavior trees btw?


ps: when you say "command" I'm presuming you mean a C++ function like the AI controller's MoveToLocation function

[Ryan Darcey]

Whatever functionality the FlyTo node provides can be easily accomplished from any blueprint or C++ class. Just use the plugin API to 1) schedule a query 2) receive an event when it's complete 3) listen to dynamic collisions and course-correct (only needed if you're really interested in dynamic obstacles).

Geez...I watched the entire video and forgot about that That's exactly what I'm trying to do and I'm calling SchedulePathfindingTask from code, so I just need to debug my setup and figure out why it's failing.

Any reason you don't want to use behavior trees btw?

I will be using behavior trees for the core AI implementation. Custom scripted events may benefit from a FlyToLocation function.

ps: when you say "command" I'm presuming you mean a C++ function like the AI controller's MoveToLocation function

Exactly

[Ryan Darcey]

So, just realizing that the SchedulePathfindingTask call is working perfectly, but that it only calculates the path and doesn't handle any locomotion. There's quite a bit more in BTTask_FlyTo that actually moves the pawn. I'm considering adjusting the implementation for my project to be more like BTTask_MoveTo where it sets up the navigation in the task, but performs all the locomotion inside the AIController. That way I'll be able to more easily create an interface for calling custom scripted FlyTo events.

...but yeah, maybe not until I really need it :P

[Ryan Darcey]

[MENTION=14603]VSZ[/MENTION], another new kid question...is there any way to abort an AI unit's FlyTo task? I'm setting up some basic AI States off a selector, but new FlyTo commands don't seem to register until the FlyTo command from the previous state completes. Is that expected? Apologies if this is a basic function of AI Behavior Trees...I literally just started working with them a few days ago, but from the tutorials I've been watching, this doesn't seem to be the behavior for MoveTo tasks. They seem to abort immediately when the selector chooses a new sequence.

[VSZ]

Behavior Trees will automatically abort a task for you subject to the following conditions:-
1) A higher priority task (i.e to the left) has evaluated its decorator condition to true (so it's ready to run)
2) This higher priority task has explicitly set the "Observer Aborts" field in the detail panel to an appropriate value (typically "Aborts Both"). Use the color-coding provided in the details panel to figure out which nodes will be aborted when the node you've currently selected is ready to run.

For what you're doing here behavior trees look like a good fit, though it's also a good idea to constantly reevaluate whether BTs are the right solution for a particular AI problem or if you'd be more productive in moving to a more traditional setup (easier to debug IMO). Over time I've found myself using a more "hybrid" solution for AI logic.

[Ryan Darcey]

[MENTION=14603]VSZ[/MENTION], I had a feeling it was something stupid I was missing >_< Forgot to set the "Observer Aborts" value properly! Must have gotten distracted during the tutorial I was watching. Works perfectly now

Also, totally agree about being wary when it comes to implementing too much in BTs or Blueprints in general. They are a nightmare to maintain and debug, but I do plan on having non-coders assist with AI development at some point so I want to keep higher level logic exposed in BTs, then wrap more complicated logic in native functions.

Thanks again for the help!

[HeadClot]

Hey [MENTION=14603]VSZ[/MENTION] - Any news on the 4.12 version of this plugin?

[VSZ]

I wasn't working on a 4.12 version at any point myself so unless [MENTION=22887]MatzeOGH[/MENTION] or someone else has ported and tested it, probably not soon!

The v1.3 update that I posted last week might even work with 4.12, I simply do not know. Worst case, if Epic has deprecated some APIs there may be some compilation errors and that should be the only issue to get it working.

It takes me a fair amount of time to patch, test and reupload stuff so with the rapid pace at which Epic releases new versions it will always take me some time to release matching updates.

[MatzeOGH]

Yes I will port the plugin to 4.12 in the future but it got moved to the next sprint. We are also planning on getting this plugin more in line with the Unreal AI system so designers only have to learn them once

[HeadClot]

Yes I will port the plugin to 4.12 in the future but it got moved to the next sprint. We are also planning on getting this plugin more in line with the Unreal AI system so designers only have to learn them once

This sounds awesome!

[VSZ]

4.12 support for v1.3 released

Latest plugin and sample project downloads are available both in the OP and in this link:
http://www.drunkonnectar.com/3d-pathfinding-ue4/

--

I installed 4.12 for the first time today and while I was at it I thought I'd port the plugin to 4.12.

Just to set expectations on future releases: my project is still in 4.11 so any new features/bugfixes will most likely funnel over to 4.11 first. I've created a separate 4.12 branch in Github for today's release.

[Ryan Darcey]

Thanks for the 4.12 update, [MENTION=14603]VSZ[/MENTION]!

Also, just wanted to let you know that I was able to fix the ensure(MyNavData) crash in this function...

void UPathFollowingComponent::RecacheNavigationData()
{
	if (MovementComp != NULL)
	{
		const FNavAgentProperties& NavAgentProps = MovementComp->GetNavAgentPropertiesRef();

		if (ensure(GetWorld() && GetWorld()->GetNavigationSystem()))
		{
			MyNavData = GetWorld()->GetNavigationSystem()->GetNavDataForProps(NavAgentProps);
			// we should get something by now!
			ensure(MyNavData);
		}
	}
}

...by destroying the default PathFollowingComponent in my project's AI controller constructor:

APFAIController::APFAIController(const FObjectInitializer& ObjectInitializer)
	: Super(ObjectInitializer)
{
	bUpdatePitchWithFocus = true;

	PathFollowingComponent->DestroyComponent();
	PathFollowingComponent = nullptr;
}

Kinda ugly and not sure how safe it is, but everything seems OK for now.