Using MoveComponent with a rotator other than 0,0,0 adds rotation rather than sets.
It seems when trying to set Z(Yaw) rotation on a collision box while using MoveComponent the rotation is added per frame update rather than set. In Paper2D this creates a spinning effect.
EG:
Plugging a rotation of 0,0,0 into MoveComponent will not rotate the component.
Plugging a rotation of 0,0,180 into MoveComponent will wildly spin the component rather than rotate it into position once.
Also, it seems to only spin when I use 180 or higher as a value.
This came about in 4.11 and was not present in 4.10.
Are you performing the move over time? If so, this would explain why you aren’t seeing the rotation set immediately. If you take a look at the Move Component To node, you’ll see the Over Time float variable, which you can set. I believe it defaults to .2 seconds, which would cause the object to rotate quickly over that interval. You could set this value to 0, which would cause the rotation to happen instantly.
Yes I’m moving it over time but the rotation does not change as it moves. I instantly set the rotation prior to moving component, and then move the component with the same rotation. Since the new rotation is the same as the old there should be no rotation. This wasn’t an issue in any other releases before 4.11.
My setup uses a variable called LevelRotation where on occasion the rotation would be set to 0, 180, 0. I found that when I set SetComponentRelativeRotation to LevelRotation the compoment was actually using a Y value of 179.9999 instead of 180. I imagine this wasn’t a problem in 4.10 because when I used 180 with MoveComponent it only had to move a fraction of a float and was not noticeable. However, now it seems that the rotation is taking the long route, potentially rotating the opposite direction, and spinning what appears to be several times; it’s hard to tell because the component is a sprite. I was able to fix this by using Component->GetRelativeRotation-> and plug that into the rotation for MoveComponent. This is however more of a hack than resolution though.
Based on your description, I have determined that this is an issue related to the editor attempting to avoid gimbal lock. Unfortunately, this is something that you will have to work around because it is much too complicated to make any alterations on, if an alteration would be possible at all. The workaround that you have come up with sounds like it should do the trick as far as working around gimbal lock.
Thank you for your report and for providing the additional information.
It’s possible that some of the code changes made in 4.11 caused slightly different behavior than what you were seeing in 4.10. As you mentioned, you were seeing a different Y value in 4.11 (if I’m understanding what you were saying correctly). From what you have described, it sounds like an issue related to gimbal lock.
However, if you have been able to reproduce the issue in a clean project, feel free to provide the test project or repro steps so we can reproduce it on our end. I have not been able to see the same behavior that you have described in my own project at this time.