I have this settings on my character in a side scroll project:
And I set my actor rotation by a function on tick so when I press right my character interpolate it’s rotation to right and reverse of that. The problem is when I want to use Up or Down direction and “add movement input” for movements like flying my character face the camera and I can’t interp the rotation any more.
I searched this matter but I didn’t find an answer so I’m asking if anyone know how to fix this?
Thank you in advance
Needs some more information and clarification of the error. BUT.
Since you are working on rotations, your screenshot shows a rotation rate of 2880. Normal values should be around 180 a max of 360.
I suggest you just punch in /360 into the filed and get the engine to convert that value which probably works for you currently into a proper value. (I think its around 10 maybe 8 but did not do the math).
On the forums, I had some screenshots for getting a better rotation going in sidescroller since the default has issues, leaving the character to face mid screen at times.
If you search for sidescroller roation in the animation forum you could possible find the answer to what you need.
Otherwise, can you explain the problem a little better and maybe include a short video of the issue?
No, it is rotationRATE - so 2880 is fine - it just says how fast it roates around Z. @mosssi I don’t have the chance at the moment to check if there is a better way - but you could force the other rotation by simply setting it in tick (make a rotator and set the axis you don’t want to 0, then on the axis you want get the value from getRotation and break that rotator in the 3 axis) - I know, ugly workaround, but maybe one comes up with a better Idea
Why do you think it’s fine that the rotation rate around an axis which can only go from 0 to 360 is OK at values above 360? Is the character some kind of a windmill? Obviously there is some issue with the value or how the underlying mechanic was made Because of that rate value being so high. (Not to mention that normalizing rotations is extra overhead).
Because this only affects the time how quick the caracter rotates arount the axis not the angle itself. So the engine is interpolating the movement and calculates based on that value. Even the UE Default is > 360 - you can set it to negative 1 to disable that interpolation and your rotation is still working fine
When I understood correctly what you try to archive is: lets say player can rotate on Z from 0 to 180 (full left - to full right) with interpolating the values inbetween so it doesn’t only snap from left to right. But what you don’t want is that the player rotates through jumping, falling, an animation or a collision to 90 or -90. Right? So you could set on start turning a bool which indicates you are starting interpolating your movement and save your direction (“right”), and change that bool value back again when the move (changing direction) is finished - in your tick you could check if that bool is NOT true, and then set the char to the last direction it moved (rotated 90 if right, rotated 0 if not right). I guess in paper2d its used quite often to select the correct flipBooks to show matching the direction. I can have a look if I’ve done something like that already (good chances ) and show some code - if it’s what you’re looking for
You are right. I did used bools for interpolation function on tick but whenever you push up or down button in movements like swimming or flying character face to camera and again it will snap back to interpolation value. so it will cause a jaggy rotation. I will record a video and my blueprints for this in couple of hours to check.
I don’t know what the problem was but I tried remaking the logic and it solved so I post the function here for anyone with same question. thank you both
I had the same problem, I think if the movement vector is exactly aligned with the Z axis, and the yaw is oriented to the motion, it doesn’t know what to do with the yaw (because the motion is perpendicular to the yaw plane) so it resets yaw to zero.
So before feeding the vector into the “add movement input” node I broke it and got the z, then I got the actor x vector and broke it and multiplyed the x and the y by 0.01 each, and then made a new vector with the new x, y and z, and fed that into the “add movement input” node. It makes the character move ever so slightly forward while he goes up or down, but it’s imperceptible.
There’s probably a more elegant solution, though.
