When I use the MoveComponent node with any TargetRelativeRotation value of 180 or higher the component spins wildly as it moves to TargetRelativeLocation.
Previously in 4.10 if the component was already set to the rotation specified in TargetRelativeRotation the component would simply move to TargetRelativeLocation without adjusting rotation.
Now in 4.11 the component spins as though it’s adding rotation per frame/tick as MoveComponent executes.
I’m moving a CollisionBox component. Is this a bug or was something intentionally changed? This is seriously breaking my game.
I am having trouble with MoveComponent and rotation too. I noticed these two lines in the 4.11 release notes about MoveComponent:
MoveComponent now only sweeps if query collision is enabled (not just any collision, so now excludes PhysicsOnly collision).
Projectile uses faster FQuat code path when passing rotation to MoveComponent.
My problem is a little different, but I think it is along the same lines. I am rotating doors opened and closed using MoveComponent. The door rotates opened correctly but on close it spins back around through the walls. It was working fine in 4.9 and 4.10.
My object’s relative yaw to its root was -90 degrees. I would then rotate it to -190 degrees. When I tried to rotate it back to -90 degrees, it would get there by going 360 degrees first and then head to -90. It spun the opposite direction, choosing the farthest path instead of the shortest.
To fix it, I set my object’s relative rotation yaw at 0 degrees to the root in its blueprint class. So now I rotate it to -100 degrees and when I call it to go back to 0 degrees, it works. For some reason it can go from -100 to 0 correctly, choosing the shortest distance.
I may try to use a timeline instead of MoveComponent in the future.
Thanks for your feedback. I’m going from 0 to -180, and it should remain at -180 except move on the Y axis. That being said I’m not sure I can implement your solution into my project. I would think that if rotation is unchanged the component should simple move, and not rotate any further. A timeline node might work but would be difficult as well since the move speed varies for me.
It does seem like a bug. Or they changed it and it works in a new way.
I just tested it using -179.9 to 0 and it causes a counter clockwise rotation. Then -179.9 to 0 cause a clockwise rotation. (This is what it was doing in 4.10)
-180 to 0 causes counterclockwise rotation. Then 0 to -180 causes counterclockwise rotation. (This is new and unexpected)
Well, unreal itself have no problem with +/-180, it’s because the eular rotation angle isn’t translated well especially implemented in ways or rotator, all while no other source or access to quaternion ops.
There are something like combine rotator/negate rotator(and maybe some recent ones?) that uses quaternion internally, you can also save results to a transform(which you can then just do transform matrix manipulation(I think again are pretty limited).
If you search for keyword quaternion you will see that this popped up from time to time and still Epic think that those are too hard to break apart and put together back.
Well, the thing is, any sane people would use those quaternion ops to do rotation instead of rotator like break and make.(like Houdini VEX have pretty good quaternion support in node graph editor, I don’t see people complaint about it being too difficult.)
If you want, there might be people like Rama doing plugins to expose those advanced blueprint nodes.
Or if you want to stay stock UE4, you better change your thought path on rotation, use combine instead of numerical add/substract, this way you also don’t have to deal with float point error, as combine rotator automatically does that for you.
(which is the whole point of doing quaternion ops anyway so you don’t need to deal with all these.)
I have not but I’ll give it a try at first opportunity. I read everyone’s post and this is probably the best solution. I doubt being a partial float off will break anything.
One thing I did notice is when setting to 180(or -180) the rotation was actually being set to 179.99999. Then when I use the MoveComponent tool and tell it to use the same rotation of 180(or -180) it spins wildly. But if I tell it to use the components current rotation after previously setting it, all is well.
Just strange that this suddenly came about in 4.11.
