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

[Brownie]

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

[DanM]

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?

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”

[Brownie]

Ah yes lol, the famous unreal magic
Cheers Dan

[Stephen_Jenkins]

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 ). Whereas Ben deleted the collision meshes instead, so that the projectiles won’t collide with them at all.

[Brownie]

Ooo, interesting

[Brownie]

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

Need more clear explanation of how MoveToActor and RequestDirectMove work together

You can easily view the definition of MoveToActor() by right clicking in Visual Studio and clicking Go To Definition. If you dig through you will find your answers. Since you want to be so verbose, in line 932 of PathFollowingComponent.cpp, you will find your call to RequestDirectMove(), which it calls on the referenced movement component. On line 1185 of PathFollowingComponent.cpp you will find where it gets the reference to our TankMovementComponent via FindComponentByClass<UNavMovementCompo…

[Steve1222]

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.

[Nicolas_Roy]

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);

[Brownie]

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

[Steve1222]

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…

TutorialProjects/TankProject

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.

[Brownie]

Hmm - I’ll take a look now buddy!

[Brownie]

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?

[DanM]

Because of this

[DanM]

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

[Brownie]

(Thanks Dan I’m in now)

Also yes this is weird… I’m getting v. temperamental behaviour from the bots.

Any idea what is up with the aiming? It’s very jittery

[Brownie]

@DanM
@Steve1222

Okie dokie, so I’ve managed to make them come after you consistently and it was basically just tidying up that I did. I’m not sure exactly which thing I changed did it, but the thing I noticed that finally did it was to change the tank body collision to a narrower mesh that wouldn’t overlap the tank tracks:

I also did the following:

• Deleted collision meshes on the turret and barrel and deleted the thing stuck to the end of your barrel
• Deleted all your landscapes and meshes etc until I just had one flat landscape.
• Deleted an extra tank track on your TankPawn_BP
• Deleted the delay and initiate physics on the TankPawn_BP event graph

There was nothing to do in the c++ except for sorting the declaration at DanM pointed out.

I wanted to go back and re-test it to check which it was that was the key change but unfortunately I overwrote the original file - so I’ll leave that to you Steve!

[Renhosoft]

FYI
I’ve had a similar problem to Steve. I noticed that RequestDirectMove wasn’t being called until I moved the tank manually somehow in any direction (usually by ejecting myself from the tank and changing their location through the editor).
Either the NavMesh volume is unable to pick them up on creation, the tanks believe to have reached their destination immediately (and thus no request to move is made), or some other logic that I’m unaware of is taking place.

Any tips would be appreciated on why this is happening, cause the process seemed way more straightforward on the lecture.

I’m editing my response just to avoid cluttering this place. For those facing this issue, if you haven’t had luck with the steps provided by Brownie, here’s how I fixed my problem.

Apparently the NavMeshVolume was building the navigation data around the tank, as if it was part of the environment. To avoid this, I went to the BP editor, selected all the StaticMeshComponent (body, turret, barrel and tracks), and disabled the option “Can Ever Affect Navigation”

From what I understand, this makes the navigation volume ignore the tank when building valid paths. I don’t know if this might have other side effects though.

[Steve1222]

I was thinking if I did this in a regular game i would have made one collision mesh for the whole tank. That was in the back of my mind as something haphazard or unrefined. And yeah it must have been the tank body collision intersecting the track collision that bugged it out. Changing the tank body collision is what fixed it. I didnt have a need to change this before because my enable physics delay fixed the map loading problem from the main menu. It is strange this would prevent the AIcontroller from calling events on the movement component though, since there was no log from the bugged tanks. Its like the AI controller knows its stuck and it can’t move so it doesnt even bother? wierd tho.

Good find on the extra tank track I didnt notice this was on here; I think i was trying to readd the tracks before to debug why one worked differntly then the other; I wonder if I had the extra one the whole time because so far i dont seem to have the tank getting stuck problem anymore. Well, near completly stuck that is; the tanks drive completly differntly on a flat mesh then they do a flat terrain. Im guessing ben will change the way this works later in the series.

[Steve1222]

Hmm I didnt think of the nav mesh not being able to pick them up, maybe this was a problem though due to the physics glitching out over the different collision boxes. Those are some good theories I’m stumped as to why it would prevent the request direct move from being called at all. I just tried doing what you said with disabling “can ever affect Navigation”, using the bugged version of my tank pawn, and it didnt make a difference. I also added my tanks in after I already built navigation when I debugged earlier so it makes sense the nav mesh shouldnt have been the problem.

If that fixed it for you it was probably because your tank was moved to a way where it just so happened to work; like with the working tanks that worked in my map when it was still bugged. Let me know what your collision looks like if it was overlapping with your tank track collision

[Steve1222]

wierd after i put my collision back to normal after testing renhosft’s theory, now the same problem persists -_- ftw.

But when I readded a new tank into the map it works so ftw IDK. Yeah it must have been a problem with an existing instance of the BP in the level. Its wierd how it bugs like that sometimes though; since how can it load or possess an instance of an older vesion of the mesh that doesnt exist?