FYI had no report from RequestDirectMove as well (solved with eye height/nav mesh height)

I see this in a few other discussions here too, but just to be clear, if your RequestDirectMove report isn’t working, it’s possibly because the eye height (set in Tank_BP) is higher than the height (Z) of your nav mesh volume.

My eye height was the standard ‘64’ in the Tank_BP, but I had only a Z height of 20 for my mesh (which looked like plenty when looking at the height of the tanks themselves, but is at odds with the ‘eye height’ setting)

2 Likes

Just ran into this issue myself, was only getting 10-15 reports every run; thanks for the heads up!

I tried setting the navmesh z scale to 400 and I’m still not getting log messages :frowning:

1 Like

@Stephen_Jenkins

Is the nav mesh box positioned so that the height extends into the sky? (Because if that z:400 is positioned so that it is low down (compared with the landscape) with most of it below the ground then I can see why you would still have the problem.

If this doesn’t solve it then perhaps this isn’t your problem at all! Feel free to post your GitHub link for people to have a look?

It’s above ground enough, you can see the green on the hill in my post No log from RequestDirectMove (tried resetting eye height and making nav mesh 400 high, no help) I need to do some git-fu to remove the vc.db file from version control history before I can push to guthub, because it’s too big for the free guthub subscription

I eventually managed to sort git out and push, here’s my repo https://github.com/turtletennis/04_battletanks

Hi Stephen,

I’ve figured it out. You haven’t yet declared or defined MoveToActor() in the Tick method of your TankAIController.

I added this and then simples, RequestDirectMove is reporting without trouble.

UE prewritten functions are a bit odd. My instinct was that you would be able to make it report no problem without MoveToActor, but I guess it is dependent on it somewhere up the chain!

Also you may need to re-jig your TankAIController. I see some custom code in there and it’s in beginPlay whereas for me my beginPlay is empty and I’m doing it all in Tick.

ALSO If someone else could clarify this then that would be great: I can’t see how movetoactor called in the TankAIController would ever get the RequestDirectMove info from the Movement component. So… is it correct that if we override the function that we are passing that into to the parent method for MoveToActor to use?

Cheers,
Ed

That’s a rabbit hole you don’t want to waste time spending on how it works. I’m doing this from memory when I tried to learn how this all worked so might not be totally accurate but basically, MoveTo will essentially set a flag which is then used during the AI’s tick call stack and will call several functions that uses the PathFindingComponent(I think that’s what it’s called?) which will move the AI.
The TL;DR version is “magic”

1 Like

Ah yes lol, the famous unreal magic :stuck_out_tongue:
Cheers Dan :slight_smile:

Thanks! I added the call to MoveToActor and now it works.

The extra code I have in BeginPlay enables the collision meshes on the tank barrel and tank turret to be accurate without sending the tanks flying when you start from the menu, so I can shoot an enemy tank’s turret or barrel and the projectile will collide with them ( and then they go spinning off ridiculously :smiley: ). Whereas Ben deleted the collision meshes instead, so that the projectiles won’t collide with them at all.

Ooo, interesting :slight_smile:

Just to finish this off - I stumbled onto this thread, which answers the question regarding the movetoactor and requestdirectmove relationship pretty fully:

1 Like

I have the call to move to actor from the video but still no output

TankAIController:

void ATankAIController::Tick(float DeltaTime)
{
	Super::Tick(DeltaTime);

		auto PlayerTankPawn = GetWorld()->GetFirstPlayerController()->GetPawn();
		PlayerTankPawn = Cast<ATankPawn>(PlayerTankPawn);
		auto AIPawn = Cast<ATankPawn>(GetPawn());
		if (PlayerTankPawn &&AIPawn) {
			
			AIPawn->AimAt(PlayerTankPawn->GetActorLocation());
			AIPawn->Fire();
			MoveToActor(PlayerTankPawn, AcceptanceRadius);
		}
}

TankMovementComponent:

void UTankMovementComponent::RequestDirectMove(const FVector& MoveVelocity, bool bForceMaxSpeed) {
	UE_LOG(LogTemp, Warning, TEXT("Hi"));
	UE_LOG(LogTemp, Warning, TEXT("%s, MoveVelocity: %s"), *GetOwner()->GetName(),*MoveVelocity.ToString());
}

Nothing happens in the game. I tried that sloppy eye height Z fix and ****** around with my nav mesh, placed new tanks, ect. ; to no avail.

Looking at this it look fine… The only thing is the Cast of playerTankPawn that I find weirdly placed. Not sure it’s your issue though. Your first line says that PlayerTankPawn will become a APawn. Then you cast it to a ATankPawn…

I usually dislike using auto variable exactly for that reason. I tend to stubbornly type my variables with the right type, so I wont get confused afterwards.

  APawn* PlayerTank = GetWorld()->GetFirstPlayerController()->GetPawn();
  if (!PlayerTank) { return; }  
  APawn* OwnTank = GetPawn();
  if (!OwnTank) { return; }

  MoveToActor(PlayerTank, CloseEnoughDistance);

Does your MoveToActor() log to the Unreal console ok?

If not you could check your condition:

if (PlayerTankPawn &&AIPawn)

If that isn’t working then MoveToActor will never get called. You could change it so you get logging for the condition. Such as:

    		if (!ensure(PlayerTankPawn &&AIPawn))
	           {
		   UE_LOG(LogTemp, Error, TEXT("PlayerTankPawn or AIPawn not active. MoveToActor() not called."));
		   return;
	           } else
		        {
			AIPawn->AimAt(PlayerTankPawn->GetActorLocation());
			AIPawn->Fire();
			MoveToActor(PlayerTankPawn, AcceptanceRadius);
		        }

If that doesn’t show up a problem, feel free to post your Git link and we’ll look :slight_smile:

Last nite I actually discovered the tanks move after I shoot them. Then I played around with their spawn heights and they only seem to log after certain heights. I cant figure out what is going on because wether they trigger the function or not is very hard to determine based on where they are spawned. It is also hard to test because my project randomly been freezing ever since ben had us introduce spawning projectiles to the mix, even when the projectile lifespan is 1 second and reload time 999. Sometimes they get stuck I beleive due to the faulty lop-sided model provided by the course, or otherwise the faulty nature of the way the tank movement is coded at this stage; but when I log I can tell if they are trying to move or not.

This is getting beyond confusing because now I’m seeing them working at regular height except for ones that are too far away. It almost seems like the program behaves however it feels like. Ok yeah so i just placed some tanks in front of me, they worked. I placed one farther away. Didn’t work. I moved it closer to me, again, RANDOMLY STOPPED WORKING. Placed another in; great I have to wait 5 minutes for the frozen unreal program to actually close from task manager. Didnt get a chance to save an example for you , again; I’ve been trying to set up and example for you to see for the past hour but It keeps freezing and loosing the map data. I guess you’ll have to play around with differnt spawn heights, locations, and logs to see for yourself. Maybe play around with the nav mesh too and eye height idk; the differentiation in results is making this quite the beast of bugs.

The version here shows two tanks working and one a bit closer to the ground collision that randomly decides its not going to fire request direct move events. But the cause of this can be deceiving…

Oh also there was no need to make a log in move to actor as you suggested since the aim at and fire methods are always being called.

Oh yeah and I agree with Nicolas about the auto variable being confusing, or perhaps in his advice inconsistent/unreliable . But removing the auto keyword doesnt change anything, since it is still triggering methods that it can only call on TankPawns

Edit: Also just noticed that driving into a problematic tank caused it to fire events (instead of just shooting them). Its almost as though the AI controller is deeming them innactive and unworthy of fireing RequestDirectMove events or something. Wierdly enough, it has a wierd naming convention differnt from the tanks that are moving by default. IT is called TankPawn_BP_2_938. The others are simply named BP1,2 ect with no additional number. Its a bit of a long shot as to the cause though.

Hmm - I’ll take a look now buddy!

Hey mate - I’ve been trying to open your project for a while with no joy. I’m getting the following error:

Not had a problem with other people’s projects so unsure whether it’s at my end or your end that the problem is occurring. If you download your project as a new zip file and try to open it, does yours compile successfully?

Because of this

Not sure why but it’s not able to find a valid path :confused:

Privacy & Terms