I’m currently setting up a 180 turn for the player character in an FPS.
I have a timeline that takes a float fom 0 to 180 in half a second, then I convert the float to a yaw, add it to the player’s current rotation and set the relative rotation of the player using the new value. I’ve hooked up ‘Print Strings’ to all variables and they’re outputting the correct old and new rotation values.
However, ingame nothing happens. Am I doing this correctly?
As an experiment I’ve tried using the timeline float in the Pitch and Roll settings and in both cases the player character gets sunk partially into the ground and vibrates, which seems odd. I’ve had no problem rotating the player via the ‘Add Controller Yaw Input’ function, although it’s not feasible in this context.
I’ve set all the controls up myself and I’m using Epic’s movement components. I’m not using the Epic First Person Blueprint content.
Seems ok to me, although when i have done something similar in the past i dont bother with combine rotators, i just plug it straight in to set relative rotation.
Eek, you’re right, I shouldn’t be combing those when setting relative location.
I’ve now tried using just the new rotation and Set Actor Relative Rotation and the combined rotation with Set Actor Rotation and neither work. I can only assume this is intentional and relates to the fact that the character positioning is driven by the Character Movement component.
Ok, so the previous version might have been buggy, if I was abie to test it, and I’ve knocked up a more robust version here, however the Rotation is still failing to be applied at the end of the chain. Any clues?
I have never done this with a character, but what i suggest is where it says set relative rotation, delete that completely and this time right click and search capsule component, (assuming you are using a default character, not sure if char has one) and then drag that out and use set relative rotation, i think that using just Self in the target does not seem to work, best of luck.
I’ve now tried setting both the relative and the world location of the Capsule Component and neither work 
Has anyone else rotated a character before by setting its rotation and not through the Yaw input?
I’ve done it, and more or less exactly as you did (I think I might have set Character rotation rather than actor…? I’ll have to check).
But what I CAN tell you is that the result isn’t what you want. The player’s capsule rotates in the world, but the camera doesn’t. That’s desired behavior for me, but if you’re making an FPS, rotating the character capsule is not your intent, even if it would work. My thinking is that because you’ve told the game that the capsule should be controlled by the view rotation, trying to rotate the capsule won’t work… But even if it would, it wouldn’t really help you to have the player capsule rotating with the view stationary!
What you really want to do is set your VIEW rotation 180 degrees offset from the current yaw. I’ve got no idea how to do this specifically (not how my game works), though I’ll have a look this afternoon. But my guess is that you could feed your timeline to a copy of whatever function the Character Controller is using to change view rotation when mouse/stick is pressed.
You might have better luck with something like this, although it works it needs tweaking and is probably missing something
Divintize, That’s my current hack until I can get a proper solution in. The problems with using this method are that it’s not possible to hit 180 dead on the angle varies depending on framerate
Rhythme Script, thanks for the info. I wonder I will try seeing what happens if I rotate both the capsule and the camera. I don’t want the camera to be offset as it should be a full 180 degree body turn with the final rotation the new forward direction on the character.
Yes, but IF your pawn is set to orient itself to the view rotation where possible, setting the view to a new rot ought to in turn orient the actor as well. If that doesn’t work, THEN rotate the capsule too, but I think you’d risk jitteriness as the capsule tries to update itself both according to the set rot and the data being passed by the view.
Sadly it’s not possible to rotate the camera in any way using this method. I’ll try a camera animtion next.
Is anyone from Epic able to try this on their end and see if this Rotation issue is a bug?
[=;100415]
Divintize, That’s my current hack until I can get a proper solution in. The problems with using this method are that it’s not possible to hit 180 dead on the angle varies depending on framerate
Rhythme Script, thanks for the info. I wonder I will try seeing what happens if I rotate both the capsule and the camera. I don’t want the camera to be offset as it should be a full 180 degree body turn with the final rotation the new forward direction on the character.
[/]
You need to use Finished to get the value 180 degrees. Otherwise you will be getting only the last value before it’s finished.
Hi ,
Please make this a post on the answerhub at http://answers.unrealengine.com so we can track it. Thank you!
Done, thank you 
[=DarkHorror;102770]
You need to use Finished to get the value 180 degrees. Otherwise you will be getting only the last value before it’s finished.
[/]
That’s not the cause of the issue DH. A timeline is controlling a curve that goes from 0 to 1 and back over 0.5 seconds. This value is used to control an anim blend elsewhere and then multipled by 8.72. Each frame grabs the current TL value, multiplies it by 8.72 and pumps it into the Yaw input. The faster the game is running, the further the character will turn during the 180 spin. It’s possible to both over and undershoot the 180 target, but this is the only method that works so far. The Finished won’t set the final rotation to 0, but give you one final value (should be 0) to multiple by 8.72 and then plug into the Yaw.
I’ve also tried taking the player’s rotation prior to the 180 spin and blocked the Yaw update if the new rotation goes over 180 degrees, but that doesn’t fix undershoots.
[=;102822]
Done, thank you
That’s not the cause of the issue DH. A timeline is controlling a curve that goes from 0 to 1 and back over 0.5 seconds. This value is used to control an anim blend elsewhere and then multipled by 8.72. Each frame grabs the current TL value, multiplies it by 8.72 and pumps it into the Yaw input. The faster the game is running, the further the character will turn during the 180 spin. It’s possible to both over and undershoot the 180 target, but this is the only method that works so far. The Finished won’t set the final rotation to 0, but give you one final value (should be 0) to multiple by 8.72 and then plug into the Yaw.
[/]
I think I know what your problem is, please post your blueprints.
Here you go. You’ll notice that both versions are currently set up. The hack version is also used to drive an animation blend, which works correctly.
The ideal version doesn’t work full stop so the two methods dont interfer with each other and the results are the same as if the top branch was disabled.
I’ve seen a bug with the combined rotators, and fixed that as follows:
Makes no difference to the problem of not being able to rotate the Player though.
[=;102834]
Here you go. You’ll notice that both versions are currently set up. The hack version is also used to drive an animation blend, which works correctly.
The ideal version doesn’t work full stop so the two methods dont interfer with each other and the results are the same as if the top branch was disabled.
[/]
Looks to me that you simply hope that 8.72 is the correct value to get it to move correctly?
For your hack version to work correctly you need to set it up slightly different. You need take into account how much the value has changed from one timeline tick to the next timeline tick. Since that is what you care about and not the actual value in the timeline. To do that simply subtract the current value from the previous value, then multiply by the number you want to get to.
It’s not hope, I knew I needed to multiple the timeline value by around 8.5-9 and tried values around all around the 8.6 - 8.8 range and 8.72 produced the most accurate results with the least amount of overshoot and undershoot.
I’ll give your suggestion a go, but I’m still going to be approximating the rotation multiplication value and hope Epic can resolve the Set Rotation issue itself.
