So I thought to myself well why don’t I clamp camera boom’s relative rotation directly instead of using a variable buffer, using your solution. (Which was brilliant and I thought would work =[). Please refer to the comment in the screenie.
And again please refer to the comment in the screenie =[
And last but not least the blueprint’s. Top is V1 with your modifications. Bottom is V1 with your modifications applied directly to camera boom instead of my variable.
Had to double comment, ran out of characters xD. Thank you for the help so far, I appreciate it. Hopefully we can figure this one out!
Please do not bump threads that have not gone unanswered for more than 4 days. This clutters the answerhub and makes it significantly more difficult to help anyone. In the mean time, you may want to browse or post on the forums in relation to this question, oftentimes the community has a readily available answer or individuals who are more readily available to assist.
Here is a tutorial I found a while back that teaches you how to create a RTS style camera and it covers clamping rotations and such. Try it out! Hope this helps you guys out!
It is from 4.1 or 4.2 so some things may be different.
Hey thanks for the reply I took a look at the tutorial and tried it out, but It seems to be for a different camera setup, and its hard for me to understand what I need to apply without seeing it in action, I gave the clamp part a shot but he does not use the yaw input nodes and because of this my camera does not work since it is based off the character yaw input. Although his system would be useful for another project I am interested in pursuing.
Right now mainly all I really want to know is why my clamp which should work, does not work. It doesn’t make any sense to me that even though the numbers are clamped 100% the camera is still updating its position beyond the clamp. Even after I tell it to reset its position to my clamp should it go past it (The camera position does not reset just the numbers).
This can mean only 1 of 2 things that I can see, either that A there is a bug, Or B I am clamping the wrong thing, or I am clamping to late in the process. At this point what looks like needs to happen is any remainder mouse axis value after I reach my clamp needs to be nulled or ignored (which is what I thought I was doing already).
Currently it looks like what is happening right now is that my initial mouse swipe (from before my clamp is reached). Is being fully calculated into my rotation because it exists before the clamp in priority. So the entirety of the initial swipe is being calculated beyond my clamp “Before” the clamp is applying itself, because the initial mouse swipe is considered a single event, the clamp is not processed until that event is finished. This would explain why the clamp works correctly after it is reached, but not before, And would also explain the inconsistency with the amount of over rotation I am getting.
Thing is I don’t understand how the axis value itself is calculated and applied and because of that it makes it difficult to come up with a solution.
Hopefully that all made sense…and thank you for all your guy’s efforts so far.
I tested it using Set use controller rotation Yaw (off) and Use pawn control rotation (off) (the latter which I understand to be the replacement of use controller view rotation).
Your thread was the only one relevant to a question I had (UseControllerRotationYaw = false; yet, my character still had its Yaw rotated).
CharacterMovement’s RotationRate Yaw was set to 360.f, while the others were 0. I updated the RotationRate for Yaw to 0, and the rotation stopped as desired.
So your issue with the over rotating during your clamp is almost definitely the fact that in the “player controller” the yaw input is multiplied by a input yaw scale variable which is normally 2.5. Simply accounting for that should fix that problem.
Here was my solution that definitely works, only a few years after xD
