Download

Can I activate different animations mapped to the same key under certain conditions?

Hi guys and gals, thanks for all the tutorials and tips on the forums. It’s been a huge help, but I am in a jam. I’d really appreciate any input, as I’ve been trying to wrap my brain around it the last couple of days and have no experience with Blueprint/Programming concepts (I’m an animator/designer). My brain is melting.

Anyway, here’s what I have:

A character that has and Idle, Walk and Run animation set up using a 1DBlendspace and is controllable with W,A,S,D and the Left Analog Stick.

Here’s what I want to do:

I have 3 more animations that I want to plug in, a backstep, a roll, a sprint.

I want all of these mapped to to same key under different conditions.

eg. When ‘Left Ctrl’ or ‘Gamepad Right Face Button’ is pressed

  • while Idle → play backstep animation
  • While character is moving —> play roll animation in direction character is moving
  • while moving and holding down ‘Left Ctrl’ or ‘Gamepad Right Face Button’ —> Sprint animation until button is released

If you’ve played Dark Souls, I want it to work in a similar way those actions work in that game.

I’ve tried a lot of things, and watched a lot of tutorials in hopes I can piece this together from what I learn from those.
But nope, it’s probably a really simple solution, but I just can’t figure it out.

(If pics are needed of Blueprints etc I can update, but that won’t be for a few hours as I’m not at home)

Okay, so you need to do several things.

First is to use a Blueprint Interface to pass your R1 button press AND release messages from your character controller to your anim blueprint in the form of events (the docs will help here).

From there, you would do something like this:

  1. get Speed (the float var used in the anim graph to drive your idle/walk/run blend). Right click, type “float <= float” and select that, and feed speed to the top node. In the bottom node, type a value for the speed beyond which you will roll instead of backstep (0 if you can only backstep while stationary).

  2. create the event for R1 press. Feed it to a “Branch” flow control, and connect the output of your “float <= float” to the condition. This creates a flow difference; if R1 is pressed and you aren’t moving, “true” will fire from the branch; use this execution output to play your backstep anim (set the variable that will feed the appropriate state machine transition, play a montage if the backstep has root motion and is in a montage, etc).

Meanwhile, FALSE will feed the roll anim instead.

Doing a sprint is a bit more complicated, here’s what you’ll do. Break the link between R1 Press and the first branch. Instead, feed it to a Sequence, and then a gate (Sequence 0 will open the gate, sequence 1 will enter the Gate). The output of this gate will play your sprint anim (and, if necessary, send an interface message back to your character controller which will be used to increase max speed).

Now, call your R1 Release event. Send this to a Sequence; the first output will close the gate, the second output will fire the dodge/backstep logic we had previously connected to the R1 Press event. So far, this logic will make the character begin to sprint while R1 is held, and then stop sprinting and dodge when released.

But what we want is for the dash to be delayed slightly, so that we can only dash by holding R1, and if we tap it, we dodge/backstep INSTEAD.

So, between R1 Press and the gate entry (coming off Sequence 1), add a Delay node of however long you want to have to hold R1 to start dashing. This will make pressing R1 open the gate, and then wait before firing the dash logic. If you release R1 before the delay completes, the gate will close and the dash logic won’t fire.

So we’re almost there. The last thing is to make a new var (bDashBegun, say) and have the very first thing that the Gate output does, before firing any dash anims or movement logic, be to set that var.

Then, before the R1 release dodge logic (but AFTER the gate closing logic, so just before our backstep/dodge branch), we create a branch with the condition connected to a Get bDashBegun, and we feed the FALSE output to our backstep/dodge branch. This will prevent releasing R1 from firing a dodge IF the dash was executed successfully.

The last step is Setting bDashBegun to false at the start of pressing R1 (along with any other state machine vars) so the logic can be reset with each press of the button and doing a dash successfully once doesn’t prevent future dodges from working.

I really appreciate you taking the time to lay out this step-by-step in the detail you have, RhythmScript. I’ll try and work through this later tonight and post back with my results over the weekend.

One thing’s for sure, looking at that I would not have figured this out on my own, so thank you for sharing!