Camera rig rotate camera target is reset after input stops

I have a camera with a camera rig component attached. I set up the rotate camera target look at behavior with a gameplay event that fires if the mouse is moved on the y axis. The camera rotates fine but as soon as I stop the mouse movement, the view gets reset. I tried deleting all other behaviours, but the view still gets reset.

I’ve attached a screen of the rig component. The yellow capsule is the target called “Player” and has a character physics component attached. Also I use the “pressed”, “held” and “released” scripts to convert the input event into a gameplay event called “pitch”.

Behaviors used


  • OffsetPosition

  • RotateCameraTarget

  • FollowTargetFromDistance

  • FaceTarget
    Any idea if I’m doing something wrong?

LY version:, Windows 10 Pro


FaceTarget may be resetting your camera’s facing when the input is finished altering it, try removing FaceTarget. You can place the camera on a new entity that is the child of player and have more control of CameraTarget while still having that target move along with your entity too.

The following post has an example of a third person camera attached to an entity:

Thanks, but I already tried deleting every other behavior except Rotate Camera Target, with no effect. The sample uses the exact same setup like me (except I’m using Character Physics while the sample uses Static Physics) and suffers from the same reset. The samples in the Samples Project use their own camera implementation, so I guess I’ll have to do so, too. Meh…

I made a sample of a third person controller with camera.

Youtube video of third person camera controller

I change the pitch with the mouse (only on held) and it remains at that pitch until another mouse movement changes it. If this is the behavior you are looking for, I don’t use look-at in the camera rig at all, instead the camera entity has a script canvas graph with only two nodes, the input handler for the rotate pitch action plugged into a ‘rotate around local x’ node.

Here is the code I wrote for my 3rd person camera. It has auto-zoom and auto-rotate. Just create a child entity from your character called cam_z …position (0,0,1). Then create a child of cam_z called cam_y …position(0,1,0). Make the camera a child of cam_y. You can adjust the positions to your likings. I gave up on the automated stuff. Make sure the code is in your on-tick section. Here is a sample of what it can do. Oh yeah, when you setup mouse control, be sure to rotate around z on cam_z and rotate around x on cam_y.

here is the code:

Properties =
{ cam_z = {default = EntityId()},
cam_y = {default = EntityId()}, }
pi = 3.14159265359;-- put this variable in your onactivate section
----auto camera zoom	--put everything below into ontick section
local cam_y_loc = TransformBus.Event.GetLocalY(self.Properties.cam_y)
local cam_z_rot = TransformBus.Event.GetLocalRotation(self.Properties.cam_z)
local player_rot = TransformBus.Event.GetLocalRotation(self.entityId)
if cam_y_loc > -1 then cam_y_loc = -1 -- clamp
if cam_y_loc < -1.5 then cam_y_loc = -1.5 --clamp
if is_moving == true then
TransformBus.Event.SetLocalY(self.Properties.cam_y, cam_y_loc -.01) --zoom out
if is_moving == false then
TransformBus.Event.SetLocalY(self.Properties.cam_y, cam_y_loc +.01) --zoom in
----turn to camera rotation
if is_moving == true and cam_z_rot.z > pi and cam_z_rot.z < 6.18 then TransformBus.Event.RotateAroundLocalZ(self.entityId, -.1)
if is_moving == true and cam_z_rot.z < pi and cam_z_rot.z > .1 then
TransformBus.Event.RotateAroundLocalZ(self.entityId, .1)

Maybe automated stuff was the wrong word to use. I just meant camera rig and settings you get from starter game for instance. And yes it is very stable in my game, and really simple. The properties section is the first section of an lua script. Here is what mine looks like.

Been trying for days to get a non shaky stable ‘camera’ with zero luck,Ive tried all camera rig settings,zero changes, camera is SO unstable its not funny.

DOes this code prevent that instability, after I do the cam setup you’re referencing ?

One quick question, where does;

  • {
  • Properties=
  • {
  • cam_z ={default=EntityId()},
  • cam_y ={default=EntityId()},
  • }
  • }
  • go ? :wink: SOrry if thats a lame dumb question, and while I totally understand what’s going on in the code, doesn’t mean I know where to put all of it.
    Also what do you mean , automated stuff ?


you have to reference your camera entities like below…you can drag and drop them to the correct fields. The fields are created from your properties section in your lua script.

fyi…I answered this question last night, but it hasn’t posted yet. It went to moderation for some reason…maybe because I included a screenshot…dunno

OK ty so much I’ll try this now,I was using the script canvas example here:

Alas, it doesn’t work , unless I’ve have a value wrong somewhere, but I"ve looked and looked and see nowhere I"ve placed a wrong value.

I’m going to try yours now.


Found onTick area, but I can’t find the movement script you’re referencing in picture.

I tried several that seemed to apply, but none had the cam_y or x fields that yours do.

The movement script I reference is the script I wrote for the character in my game. The cam_y and cam_z fields were created when I defined the properties in that script. …

  • {
  • Properties=
  • {
  • cam_z ={default=EntityId()},
  • cam_y ={default=EntityId()},
  • }
  • }
  • This can be done in script canvas to. I started my project using script canvas.
  • Here’s a video I posted on youtube when I started out using script canvas. There are screenshots of the scripts at the end.

Hey @Ihatenames and everyone else who has been contributing,

It looks like there may be a bug. For anyone that feels comfortable adjusting the RotateCameraLookAt.cpp file, the recommendation from one of our engineers was to remove line 110.


m_rotationAmount = 0.f;

Should become:


If someone does decide to make the change and run some tests, we would definitely love to see it make it back to us through GitHub. :slight_smile:

But just in case, I’ve sent the bug off to the team.

No worries, I am not a programmer myself so I’m working off the recommendation provided.

This would likely impact any behavior at the end of any rotation “look at”, which is why the engineer recommended running tests before committing to the changes. From what was explained to me, it sounds like it just removes the forced zeroed rotation at the end of the active rotation look at. If anyone was accounting for this zeroed out behavior before, this could potentially require them to re-adjust again when the fix goes in based on their original approach.

I’d be happy to,but does this affect everything to do with player camera rotation ‘look at’ or ?

I"m not a good enough programmer to ‘know’ , yet :wink:

Ya on second look(ha) I saw that, sounds good.

OK ty so much