Previous versions was ok, but something is messed now with this blueprint function. Instead of shortest path it uses only one way rotation. I tested it in completely new project (TPP). Here is the video.
I hope it will be fixed until final release of 4.11 cause it completely breaks my parkour system.
Hello,
Since you have been able to reproduce this issue in a clean project, can you provide the steps that you took to do so?
Create TPP Project and open character blueprint:
Add some input key event f.e ‘F’
Trace line in direction the camera is facing to find wall
Calculate direction using the hit result’s “Impact Normal”:
to do so: NegateVector → RotationFromXVector
Target location is hit result’s Impact Point.
Pin everything to new MoveComponentTo node.
Place some high wall as I do in the video and press the input key. In some cases it will behave oddly - rotating in wrong direction picking longer path. I did not happen in prev. versions.
I am sure you should place the Wall with the same direction as I do on my video 
I have attempted to reproduce your issue using the blueprint shown in your video, but I couldn’t get the same behavior. My character was using the shortest rotation possible to reach the desired rotation.
Does this happen every time your character rotates, or is it only at a specific rotation or specific time?
The length of this path depends on your character’s rotation. Lets assume that you are behind the basic stairs on tpp scene. Your character is facing towards the stairs. In front of you, in the middle of your character and walls there is high wall.
And if you are perfectly facing towards this wall your character will successfully rotate.
Also if you are rotated more to the left, it will succeed.
But if you are rotated more to the right it will take more distant path.
It just looks like my character always rotates to the right, even if the shortest path is to the left.
Edit:
The world rotation is important, you need to place this character facing the “-X” vector.
Hello,
After spending some time looking into your issue, I was able to reproduce this. However, it is not necessarily a bug. The problem here is that using the Move Component To node is attempting to avoid Gimbal Lock when rotating from certain directions. What you could do to work around this is instead of using Move Component To, look into setting up a timeline, which will allow you to lock certain rotation axes and get your desired behavior.
Let me know if there are any further questions.
Have a great day
So I must remake 30% of blueprint code because of one change in this function? I never experienced Gimbal Lock, and can you tell me how it is possible to get Gimbal Lock when rotating only Yaw? Of course its bug or imperfection. GL can be avoided using quaternions but not taking longer path. The most important thing is just shortest path.
Due to limitations in the engine, my above solution regarding a timeline or quaternion conversion are the primary options in your case.
I have my parkour in prepared for that Actor Component. I can’t place there any timeline - there is no option in popup menu after clicking with right mouse button. I am not beginner - I don’t have everything in one blueprint. Since starting project I’ve grouped everything nice and legibly. This component have many, many connections and references. I can’t just take everything and put it into character blueprint because of one node is absurdly “working”. Also if I did that it wouldn’t work for other - AI controlled humanoids. You said “quaternion conversion” - is it even possible. I see quaternion in UE4 as useless structure - no function or something.
Could you provide a video of the behavior you are experiencing? As stated above, this could be related to Gimbal Lock, but I’d like to see what you’re experiencing before I conclude that this is the case.
Just downloaded 4.11… experiencing same problem! In my case it rotating in wrong path no matter where my character is facing!
And yes i also can not use timeline everywhere!!
Its supposed to come back to its old position, without rotating in the wrong direction! It was working fine in the 4.10
Edit: Just solved the issue by changing the rotation from 180 to 179 http://puu.sh/o8DRk/c1a0847d64.png
Wondering if this will work in the other places i have used this node!
So is there any other way to stop it from avoiding gimbal lock? So it can work again the way it was working in 4.10?
Can i know the reason why this was changed in 4.11? what is the benefit of this change?
We are seeing the exact same bug, and we ARE using a timeline but the timeline on tick is calling set actor rotation.
And we are also only rotating on one axis (Yaw), so there is no possible way to have gimbal lock. And just digging around a bit, SetActorRotation calls MoveComponent on the root.
It’s definitely possible that this is not the issue, and if this is the case, feel free to provide a test project, or repro steps on how we can reproduce this in a clean project on our end.
Thank you
oops, we implemented the timeline tick with a FMath::Lerp, and it seems like it behaves a bit differently than before. This lerp is in the MoveComponentTo blueprint function, and can cause longest path rotations.
For me, it behaves the same way by spinning around himself, even after having created a timeline with lerp (regardless having pressed to take the shortest path or not.)
Here I’ve made a video which features the behavior of Move Component To node on an older version and the newest:
I have managed to workaround this problem, WHAT IS STILL a really dumb step from Epic. I have created an Actor, that is able to manage some delayed actions which are stored in Objects. I was forced to do it all by myself, implement a interpolation, delayed action and fair interface. This is really annoying, that when new update comes up things get broken. ALSO Sean Flint… you know what the interpolation by shortest path is? It have ABSOLUTELY nothing to the Gimbal Lock. It was just getting rid of another problematic question. I feel bad for every user that is treated like that. Gimbal Lock? Psh! Can you explain me - how can an actor fall into gimbal lock when its rotation is 0 except Yaw? This is ridiculous. Node is broken and that is the fact, not any gimbal lock avoiding. Don’t rotate at all if you want to avoid it this way.
