If you may think I added +0,0,50 vector by using SetFocalPoint and thats why control rotation points forward. Answer - no, it doesnt update Pitch rotation in any way (jumping, going more down, etc)
Have you tried dragging off of your player pawn reference and using the Get Actor Eyes View Point node to set the Focal Point? Let me know if that makes a difference.
I have not been able to reproduce this issue on my end in a clean project. Would you be able to zip up your project, upload it to dropbox, and provide a link so that I can take a closer look at your setup? You can PM me the link on the forums: https://forums.unrealengine.com/member.php?160394--Flint
After looking at your project, it appears that Set Focal Point is working as intended. The reason is if you notice, you’re passing in a vector value, which means that the rotation would not change. Set Focus takes in the entire actor reference, which includes the entire transform of that actor.
What you can do is use Find Look at Rotation between the two actors, and then use that to set the rotation of your gun and any other parts of your AI character that you’d like to have looking/pointing at your player character.
Give that a shot and let me know if it works out for you.
I’m passing vector value because it expects vector value.
In this situation Rotation and Scale of my Character doesn’t ever affect location in which, I expect, SetfocalPoint should find LookAt rotation. Plus he finds LookAt rotation but updates only Yaw.
Then could you explain me please what SetFocalPoint is used for and how it works.
I guess I can try to use SetControlRotation, don’t know if it will be working.
SetControlRotation overrided every tick by internal code.
Also your colleague Mieszko said in THIS thread: “we don’t recommend micro-controlling AI. If you want your AI to look at a specific location you set its focus”
So you give me 2 options:
SetFocus - where I need to send actor and it looks at its Pivot Point (Updating Yaw and Pitch) but not being able to set custom location
OR
SetFocalPoint - where I can set custom location but it only updates Yaw control rotation and not affect Pitch.
I’m 99.9% that LookAtRotation broke somewhere in SetFocalPoint. I don’t believe that you find LookAtRot, update Yaw and then just kill Pitch for no reason.
This is not a bug i think, the pitch is zeroed in function
/** Update direction AI is looking based on FocalPoint */
virtual void UpdateControlRotation(float DeltaTime, bool bUpdatePawn = true);
of AIController
In function Impl you can see the following part of code,You can comment it and recompile the engine or you can override the function in you custom controller and remove the below code alone
// Don't pitch view unless looking at another pawn
if (NewControlRotation.Pitch != 0 && Cast<APawn>(GetFocusActor()) == nullptr)
{
NewControlRotation.Pitch = 0.f;
}
Looks like this is still a bug but it has been removed from the issues tracker. The problem lies in the code that Jeslas Pravin references below. That logic will always zero-out the pitch when there isn’t an actor being focused. Since using the location over the actor is precisely so we can control the pitch, this has to be faulty logic. It’s the exact opposite of what we need. Plus, if I override that function, copy it from AAIController, and comment-out that block, the pitch works as desired. Cheers!
The reason the issue is no longer available is because it is actually a feature request (which we have removed from the bug tracker to narrow the focus of it strictly to bug reports). As Jeslas Pravin posted, the pitch is zeroed out if the focus actor is not a pawn. The behavior should be configurable, and it sounds like you’ve got a method of accomplishing this. Thanks for sharing.
But when you set the focal point, you can’t provide a pawn so there’s no way to avoid zeroing out the pitch – other than overriding the update function. So if it’s a feature then it’s incomplete IMO, but OK.
I would have to agree with here. We’re left in a position of either targeting someone’s waist, or having to write a custom function to handle this. I guess there are maybe some scenarios where you wouldn’t want to the AI to adjust their pitch, but if you’re giving them a target to either fire or look at something, why wouldn’t you want them to adjust their pitch so that they’re actually targeting that thing?
I love Unreal and I don’t mean to sound ungrateful. It’s just that there are a LOT of these fundamental bugs that are keeping us from doing great things while you guys keep adding new features (with more bugs).
Yes, we can implement this fix ourselves, but it forces everyone to use a C++ project. And isn’t the goal of providing UE4 to reduce our burden as we bring our creativity into form? There are major roadblocks in so many systems that keep us from doing new and amazing things without major consternation (to get around or fix years-old bugs). IMO, it’s antithetical to your mission, and for us it means an eternal state of frustration and confusion with a nice helping of despair. All the time. Docs are almost non-existent and advanced questions on AnswerHub sit unanswered. I’d say one in ten of my issues is addressed anywhere online. It’s really, really, lonely out here sometimes.
Again, this comes from a place of love. I’m not looking for a reply, I just wanted to express my feelings. Please consider using some of that sweet sweet Fortnite money on going through the backlog.
Cheers!
