Hello guys,
I have started to prototype simple weapon sway mechanic in blueprints and I have decided to move blueprints to C++, but I can’t get it to work as It worked in blueprints.
I think the issue is with the RInterp function.
Any thoughts on this, guys?
Just for future reference, it’s usually preferred you post the code here with the code tags (enable advanced editor when creating a post, its the icon with the letter A above the post text box)
It looks like you have the SmoothSway in the wrong spot, you are multiplying it with delta time. You should leave deltatime alone and set Smoothsway as your speed or do whatever time manipulation where you have 3.0f. I’m not sure what smoothsway even is, a float i guess?
The 2nd issue is you have your current rotation, and your target rotation are the SAME.
your current rotation is going to be whatever values your rotator are for x,y,z. (err I mean pitch roll yaw etc etc)
then your target rotation, you are just breaking out roll and yaw but not changing them at all. You need to take the actors current rotation .yaw or .roll and ADD or subtract to it whatever amount, lets say 20 units.
Then Rinterpt will modify the actor rotation from what is is now, to whatever your new target is, 20 units to roll and 20 units to yaw. it will do this based off delta time and how much based off the smoothsway or 3.0f whatever value speed you want here.
Thank you for the post.
Obviously the function itself doesn’t work because there are much more blueprint nodes etc after it. I am adding or substracting pitch based on Character rotation which owns the gun.
I am just wondering why I am getting different behaviour when I wrote all blueprints to C++ code. I think that my C++ code is exacly the same as in blueprints screen but it gives me different output.
I think you’re having a problem with the fact you’re multiplying delta time by your smooth amount.
You really shouldn’t be scaling delta time at all when using interp nodes.
Try adjusting your speed instead and remove the smooth amount usage.
Thank you for your effort. You are right, I no longer scaling the delta time, but It does not fixed the issue.
The main issue I got now is that weapon doesn’t follow the player, it always trying to point in the one way. Weapon does not stick into hands, just keep pointing as in the begining.
I got a BaseWeaponClass, and AutoRifle which derives from BaseWeaponClass. I am implementing weapon sway in BaseWeaponClass in C++, but the blueprints are in the derived class. Do you guys think that could be the issue?
Have you verified that the tick code is actually running?
Yeah, I put some logs in the function and it is printing/ticking. I have really no idea what is going on. I really don’t see any difference between my code and blueprints. I should get the same result but I don’t.
do a log statement after your interpt and print out the .yaw and the .roll (or whatever values you are trying to modify) to see if they are being changed at all.
Based off the code you sent, it looked like current rotation and target rotation were exactly the same values.
Thank you very much guys for you effort, really :).
Please don’t focus on what the function actually does. Do you guys agree that blueprints code is the same as C++ code? Do you guys see any difference?
I just want to write this blueprint screenshot to C++ weapon base class, but It doesn’t work in C++ as in the blueprints and I have no idea what is going on.
No, they are not the same, because your C++ code has a wrapping if() statement that tests some FinalWeaponSway variable that’s not tested in the blueprint.
If InitialWeaponSway is in any way different from FinalWeaponSway, your C++ code (in the else statement) won’t run at all.
InitialWeaponSway in C++ is TemporaryCharRotation in blueprint.
FinalWeaponSway in C++ is TemporaryCharRotation2 in blueprint.
This - Also with FRotators shouldn’t you be using the
FRotator::Equals
function with a tolerance value?
Tried, didn’t fix the problem.
I don’t want to waste your time guys so I will prepare full c++ code and blueprints screenshots and I will upload two videos to show off the problem.
I think the problem is that they are too similar. The order for the FRotator arguments in C++ should be (Pitch, Yaw, Roll) and not (Roll, Pitch, Yaw).
You are beast! I got FRotator in wrong order… Thanks a lot for all your effort guys.
Don’t you love weird Unreal engine quirks like that which would break every single project in existence if they decided to fix?
And these little quirks are the reason we love Unreal so much.