Switching camera forces the player to look down

[ExpStealer]

Greetings everyone!

I’m making a FPS project and want to setup ADS and Scopes. I tried different approaches, but so far this is the only one that truly seems to work. My setup is as follows:

• A Character with a bunch of different inputs and a camera component.
• Parent class for weapons with all functionality and its own camera component; actual weapons are child classes.
• All cameras are attached to sockets on the respective meshes.
• Weapons picked up by the player are attached to the player’s mesh as child actor components (again, via a socket).
• Both Yaw and Pitch (Y and Z) come from the pawn’s base aim rotation.

My issue is that when I switch from the player’s camera to the weapon’s camera (using the SET View Target with Blend with the node’s target being the Player Controller), the player is forced to look almost straight down and Pitch input doesn’t work at all - Yaw input still works normally. Why does that happen and how do I fix it? Here’s a video of what happens, as well as the workaround fix, mentioned below.

EDIT: I have been able to come up with a workaround fix. However, I am not sure if this is the correct way to do this.

[ExpStealer]

Thanks for investing the time to try it out yourself.

However, there are a few things you’re missing - such as an actual, animated character mesh. Your child actor is also not attached to the mesh (mine is, two of them, actually). There’s also the camera boom, which I don’t believe I have on my character’s camera.

This is how the input goes for me:

Input → bIsAiming = True → AnimBP reads the bool and changes idle animation and the 1D AimOffset used → Camera switches using the node above. The attachment hierarchy is below:

Weapon Camera → Child Actor Mesh → Child Actor (directly attached to finger bone) → Character Mesh ← Character Camera

As far as the sockets are concerned, they all face +X (except for the Child Actor one).

[Okarii]

So I’m going to venture a guess and recommend you check on how the camera and the socket are oriented, you might have a weird orientation for forward. I set up a quick test version that used a camera component instead and did not encounter any issues.

[Okarii]

Gotcha, it may be helpful then to see a bit of the setup itself. its possible there may be a easier or alternative method to what your trying to do or be able to help debug a bit easier. I experimented a bit with the set view target with blend and it doesn’t pass control inputs (your still possessing the parent bp). so that might be a matter of where the child actor is parented.

[ExpStealer]

Alright, here’s everything wired in the [ADS Input Event][1]. Below is a screenshot from the character’s setup:

The child actors are for weapons (obviously), but they’re both attached to the same bone on the character’s mesh.

I can provide more code tomorrow, but hope this helps a bit.

[Rev0verDrive]

If your weapons camera is actually setup to look down the sights. Then your character needs to be in an aim down sight animation. If its not then you’ll be looking at the ground.

On equip (attaching weapons to hand), transition to a new anim state. Hip rifle idle pose or something. There’s a free anim set from epic with the poses needed.

Animation Starter Pack in Epic Content - UE Marketplace

When you ADS you need to set a transition state for ADS animation. Then set view target with blend (gun camera). The animation class will use this variable in the anim graph (state machine) to transition to an ads sequence or blend space.

As long as you’re in the ADS state you need to stay in an ADS anim pose. Aim offset, idle, firing whatever.

---

Another thing you’ll need to do is create an offset vector variable in the weapon class for camera positioning. Each weapon will have a different camera position relative to its parent mesh. This position will also vary depending on the optic used.

e.g. iron sights vs Acog 4x / 8x scope.

Not every optic will have the camera at the same place on the mesh. You’ll need to adjust these per weapon at run time (begin play) and on optic change. So technically, depending on how you setup your weapons you may need more.

My setup is based on customization. I can attach/detach a myriad of different attachments on the fly … including optics.

For each optic item class I have an array of vectors. One vector for each weapon the optic can be attached to. When the optic is attached I get the vector and apply it to my camera.

---

My gun cameras are created at run time (Parent Class).
Construction → Add camera component → Set reference variable → Attach to Component-> Set World Scale 3D (scales camera size)

https://i.imgur.com/wJdh3C1.jpg

Begin Play (Parent Class) → Sequence →
Then 0: branch compare offset against default → set relative location
Then 1: branch compare fov against default → set field of view

This is a simple straightforward example approach. This isn’t looking at any optic attachments etc.

https://i.imgur.com/984GMOL.jpg

Input logic, set view target with blend …

https://i.imgur.com/OXPH84a.jpg

Simplified State Machine

https://i.imgur.com/Iko5J32.jpg

[ExpStealer]

Thank you for the detailed answer!

When it comes to the ADS state and animations, my setup is pretty different. I am using the ASP, but I don’t have a separate state for when the character is aiming. Instead, I have two idle animations in my Idle state, which switch based on the IsADS? variable. Then, an additive animation is added on top of it - 1D AimOffset for the vertical aiming (since it’s a FP perspective, you don’t need the horizontal aiming animations). Could the lack of a separate ADS state in the machine be the root cause?

[Rev0verDrive]

It’s possible not have a state in the state machine could be the issue. I’d need to see a vid of ads in action. Go ADS, pause and eject.

Here’s what I’ve got going in mind atm (currently rebuilding/refactoring). I have conditional logic (func) that determines my locomotion and ao states.

[ExpStealer]

I will take a video of exactly what happens when I can. However, I was able to make a workaround fix - I used the control rotation instead of the base aim rotation. Then, I did some tiny math code, so that the value ends up in the AimOffset’s range, and now it seems to work.

[ExpStealer]

Here’s the video. If you have any questions, just ask. As as I mentioned, I managed to make my own workaround, but I still want to learn the proper way to do this.