Download

Make keyboard input blend to 1.0 like an axis (gamepad thumbstick) during tick?

I’m trying to set up leaning of a motorbike tied to the input axis value of the A nd D keys. I figured an easy way to do this is to just get the axis value of the keypress and multiply it by a lean amount float (30) and then set the relative rotation of the mesh on the X axis which works great. Only problem is that key presses instantly go from 0 - 1 whereas a gamepad thumbstick will blend the value based on how much you press it. I can’t for the life of me figure out how to blend the value so that it’s gradually leaning instead of instantly jumping to the new rotation value.

Should I create a leaning animation and use a blend space for this? I figured just rotating the mesh would be easier.

hi @TorQueMoD

if i understand correctly what you want to do …

You have to use the keyboard A, D , to increase a variable
lets call it “Turning”, if A is pressed , remove 1, if D is pressed Add 1
and then clamp the value to a min and max like -60 and + 60.
When noone of them is pressed , lerp it toward 0

Now you can use this varible to set the rotation of the object

Hey Est_engine, thanks for the reply.
That still wouldn’t give the results I want because I’d still be instantly jumping from 0 - 1 in a single key press. What I was hoping to do is figure out a way to blend from 0 - 1 over a short period of time like 0.1 second, but also during tick. Normally I would handle a blend like this with a timeline and a float track, but you can’t run a timeline during tick, otherwise it just resets every frame.
That said, your idea is helping me think of a solution. I could possibly use a variable as you suggest, and add 0.01 to it during the tick, but clamp it to avoid going above the desired value. I’ll try this thanks.

In case you’re still looking for inspiration, imagine the red block is the bike:

It’s a self-correcting value affected by another, larger value - the leaning factor. With no leaning input, Tick will correct Target Roll to 0; but leaning to a side makes Target Roll a much juicer target for the fInterpTo.


You could also tie the leaning factor to the bike’s velocity, making it harder to lean when the speed is great. And to make it even neater, you could sample an external velocity based curve - perhaps some bikes are easier to handle than others.

And the Target Roll can also be tied to velocity, a bike that is standing still & leaning will fall over, there should be no correction added. But a fast moving run-away machine will self-correct even with no rider. Playing with that x0.1 multi will also affect how hard it is to counter the self-correction for the player.

1 Like

You’re awesome Everynone. That is exactly what I was thinking to do once I read Est_engine’s reply though I was going to try using a lerp so thanks for the extra work since I didn’t know about the finterp to node. I’m curious though, what’s the point of subtracting 0.0 from the Target Roll?
Thanks so much for the awesome help!

But that’s not what is happening, ha. We are subtracting from 0, this is what creates the opposite value. If you lean to the right, 0-right will create a force that pulls you in the opposite direction.

You can actually use that 0 for gameplay. Setting it to a non-0 value will create a bias in one direction. Perhaps the bike is damaged and pulls to one side. Or a wind gust makes it more tricky to drive for a duration, the terrains is sloping, or something bumps into us. It could be used to emulate a physical interaction if you’re not using physics. It can be used dynamically and altered during gameplay.

If you are using physics to maintain balance, then there are better ways, most certainly.

Oh, that’s really cool. And yeah, I missed that. It’s 0 - so you’re getting a negative value. Got it :slight_smile:
You must be an actual programmer and not just really good with blueprints :stuck_out_tongue:

I consider punching numbers into the microwave programming, too. So there’s that.

1 Like