Weapon/Object Rotation Oppossed to Camera Rotation

Hello everyone!

I hope your holiday went well.

As I was creating a flashlight for my player a thought hit me: Its extremely static.

The flashlight beam doesn’t move; it’s attached to the camera that moves.

I seems like the character is rotating on a fixed pivot (alright well he is…but it looks odd).

I was curious how one would go about having the flashlight beam (or any weapon) rotate and move around the screen instead.
When the object got too far to the edge the player would turn.

Here’s a perfect example:

  1. - YouTube (skip to roughly nine minutes in)

See how the flashlight moves and because of that it rotates the camera?
That’s how I want it to be.

Honestly, the “RelaisticRendering” UE4 project has the same effect on its flashlight.
I just couldn’t grasp how they did it.

NOTE: This is for a FPS game!

Any Ideas?

Thanks,
~ Jason

First thing that comes to mind would be to attach the flashlight to a socket on the arm mesh instead of the. Then it would pick up movement from the idle and movement animations “for free”, so to speak.

After watching the video, I think what they’re doing is not parenting the light to the camera, but lerping it toward the camera, then overshooting it a bit and lerping back.

Another possible way would be to child it to the camera, and then apply some subtle local space animations to the camera itself, either procedural (e.g. a sine curve with some randomness) or hand-animated.

not sure if this is what you want , but in the blueprint / components / springarm . details panel / options “Lag” enable camera lag / rotation , tick boxes and set the values

Thanks for the responses.

I’ll try to make it a child and see if that results in even a small change.

I’ll also look into the camera “Lag” option and report back.

~ Jason

Alright I’m at a loss.

Using this tutorial as a base where would one go?

Tutorial:

How could I lerp/lag it using this setup (if using this setup is even a good idea).

I’m going to assume I’m over complicating this. It just seems too complex to actually be complex.

Thoughts, Ideas?

Thanks,
~ Jason

I thought I’d look at this since it’s an interesting problem. It seems to have a simple solution in enabling the built in camera lag, but in fact, it kinda does the inverse of what’s required. So I’ve been messing around with this for a few hours and finally got a working solution. So Here’s how I got it working.

First, in your Pawn blueprint -> components, you need to add a dummy object that matches the pivot of the camera, unless your first person arms you’re using already has the pivot matching the camera. The reason for this is to get a matching pivot point because you will rotate the arms separate from the camera and they need to match.

So now what you have is a dummy object parented to the capsule and the camera is also parented to the capsule. Now, parent the arms to the dummy object. So the arms no longer follow the camera, but rather the dummy object.

Now, for the dummy object, change the Rotation type to “World”, so it will be unaffected by the pawn. You see in my screen shot it says Absolute Rotation, that is what you want, changing it to “World” gives you that.

8f852950124f42bd902f84817d8b70e225e18fa3.jpeg

Now with all that stuff set up, you can change your mouse input inside your Character Blueprint to look like the following.

7a110482d8528978072582617afdca14d85c6662.jpeg

You can see what this does, it basically lags the camera, while forcing the gun or arms, to rotate directly on mouse input.

You see there are two multiply nodes in there, one reads “2.5” and the other “-1.75”. These values are based on the default input multipliers used inside the PlayerController. So if at any point you had modified those defaults, you would need to use those values in here as well.

Of course on the FInterp nodes, the Interp Speed is how heavy the lag is, so you can tweak that to tweak the lag.

Anyway, I hope this helps. You’ll see that it kinda feels a bit weird because you’re lagging input essentially. But see how it works for you.

Just to show it working…

That got me started it the right direction, Obihb!

I see what you mean about it being…odd.

It’s as if everything is overly sensitive.
I’ll play around with some of the values.

There’s only one question:

When I look up/down the spotlight doesn’t follow. Do I need a MouseX/Y setup like usual or should this setup cause it to follow?
I tried out the Mouse X/Y, but it causes it to be static again (for some reason) is there something I’m missing?

Thanks,
~ Jason

EDIT: Just tried it again. Everything seems to be working fine (using the Mouse X/Y setup). I’ll play around with the FLOAT values to see if it becomes less sensitive.
Hopefully I’ll find a reasonable medium.

Thanks for the setup I really appreciate the help!
You’re a life-saver!

Happy Holidays,
~ Jason

To keep it local to your blueprint, without tweaking the actual player controller, you should be able to create a multiplier for sensitivity. I didn’t test it out but you should be able to just add a multiplier right after the Input Event to multiply the TurnTargetRot and LookTargetRot values with something less than 1. So for example 0.5 to make it half as sensitive.

I didn’t test to see how it works, so not 100% sure.

EDIT: So of course right after I wrote this I had to go test it out. It does work… :slight_smile:

You, my friend, are the best!

Thanks for the fix and the system as a whole!
It was extremely helpful (and informative)!

Have a happy New Year :slight_smile: !

~ Jason