(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
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!
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.
2 Likes
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.
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
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?
Yeah im not sure whats happening there - but possibly some sort of caching Unreal is doing. Ive had a hell of a time trying to get Unreal to recognise a change and thinking im getting somethimg wrong only to turn it on the next day and the problem has disappeared!
Anyway, glad its resolved!
This fixed it for me! Many thanks, I was tearing my hair out!
Thank you Renhosoft, this problem was extremely confusing. I mean some of my random tanks i would spawn, like maybe after 3 or 4 would randomly work while the rest would just stand still. It was odd for awhile i was seeing brand new placed Tanks from the Tank BP changing around the positions of their components. They were not getting reattached to others, but just different places on the list it was odd. Then like i said some would randomly work and some others would not, all of them placed at the same time fresh from the same bp.
Anyways Thank you for the fix, i will remember this lesson and move on!
I had the same issue of the AI tanks not logging anything, except when I hit them - forcing them to change positions and after they log everything out. Decided to fix it by just spawning the tanks slightly above ground and now everything works just fine. For now that is 
I wasn’t logging either.
What fixed it for me was looking at the Nave mesh output, the ground underneath the tank wasn’t being calculated, so i just moved the AI tank up until it was.