Hi.
So, I managed to make something similar work with Timeline and Lerp where my object moves between two locations correctly. Now I am trying to get it to rotate on z axis prior to moving by using Timeline and Lerp again, however, with rotation (unlike vector), there is the issue of the angles being anything from negative 180 to positive 180, making it difficult to find the sum between starting rotation and destination rotation.
I am aware that this math needs to be calculated prior to running the Timeline and that I need to feed it into the Set Play Time, so that the object rotates at a constant pace regardless of the amount of rotation required, but I cannot figure out if Unreal has built-in functionality for this or I need to go through some math equations to solve it?
Any answer would be appreciated.
EDIT: I incorrectly wrote the average between two, but I corrected it to the sum between two.
I am not 100% sure if it’s the right answer but I think you can use “Set Timer By Event”. with that you can define how many time per second you want to tick it. And with a simple calculation you can define how much addition needs to be done. If this doesn’t make too much sense, let me know. Ill try to make an example.
Not sure that would be the right approach. I essentially need to figure out how to calculate the sum between the Ship rotation (angle out of 360 degrees) and Destination rotation (angle out of 360 degrees). It is a bit perplexing because the two angles can be in both positive values and negative values (180 degrees to 0 and 0 to -180 degrees).
I thought that because this may be a common math request, that perhaps Unreal had some pre-built functions to get through it.
This makes the front of the ship be rotation angle 0 with either clockwise or counterclockwise towards the end of the ship be a positive between 0-180. Based on this, you can figure a way to make the amount of rotation have a constant speed regardless of rotation amount.
I had to add a dirty min/max clamp at the end of it to ensure that rotation speed never goes past or below acceptable, as well as divide by 20 to simply get a lower increment value to feed into the Play Rate. This is not a clean method and I would not normally accept it as a solution for a proper game mechanic, but it is efficient and works for my prototype and it is easy to swap out with a proper solution later on.
