How to stop player input from cancelling animations?

I want to make animations like attack and reload non-cancellable, how should i do it? I tried Disable Input but it just stops all controls which is not what i want. I also have a boolean that checks if the gun can be fired but it doesn’t stop the gun from firing during reload, and the reload animation can be interrupted by pressing reload again, how do i fix it? Please help!

Using a montage? You can place a couple of anim notifies in the animation sequence or montage. Call them something like lock and unlock. In you animation BP add two custom events to look for the anim notifies and set a boolean, LockAnimation for example which you can use to lock any player controlled input from triggering any other animations until the notify is cleared with the unloc.

My approach to this has been to use notify states. Define a bunch of notify states which do nothing but set bools on the character for disallowing certain inputs on start and reallowing them on end (and create a subsequent set of bools for bCanReload, bCanMelee, bCanShoot, whatever you want to disable).

There are a few advantages to this approach. For one thing, using Notify States means that you never have to worry about wayward bools disabling things (i.e., you set the player’s inability to fire some place and through a difficult-to-track chain of animation blends and state changes, you manage to skip unsetting it and now the player can never ever fire) because a Notify State, by its very nature, will ALWAYS fire its NotifyEnd event, no matter how the animation is exited. If you are seeing the reload animation, you cannot fire, and when you stop seeing it, you can fire, and that reality is tied to the animation itself no matter how you get to it.

For another, by using Notify States, you can actually tune/balance your game with active frames. For example, you may want to disable the player from shooting during the portions of the reload animation when he’s actually reloading, but allow him to resume shooting as soon as the magazine is reinserted or the charging handle is slapped or whatever. With a standard check, you’d have to make sure your reload animation ended as soon as that occurred, which might make it look clunky or abrupt if the player was just reloading and NOT immediately resuming the act of shooting. Using a Notify State for disabling firing lets you cover the important frames of the reload animation with your “shoot mute”, but keep any number of extra flavor frames at the end which will only be visible if no action is taken that interrupts the reload. This way, your reload animation can naturally transition back to an idle pose over multiple frames, without this extra animation information getting in the way of responsive inputs where you want it to.

Finally, you can use notify states as a way of creating a sort of cobbled-together input buffer. It works like this:

  • If shoot is pressed and hits the bCanShoot branch and comes out false, instead of doing nothing, you set a new bool on the character; bBufferShoot.
  • in the Notify End function call of your “shoot mute” Notify State, you can hit a branch; if bBufferShoot is true, you can call the shoot function on the character (and then unset bBufferShoot), otherwise you can just unset bBufferShoot.

This way, if the player presses the fire button midway through the reload animation and holds it down, instead of that input being totally consumed by the reload, the action of shooting will be buffered; as soon as the reload reaches the end of the “shoot mute” frames, the “ignored” shoot command instantly comes out and behaves as normal.

The disadvantage to this approach is it means you have to design every animation in your game like a fighting game or action game designer would; you have to consider what the “active” frames of each animation will be for each context (maybe you want the player to be able to cancel a reload with a melee attack, even if you don’t want him to be able to cancel it with shooting or a new reload attempt) and manually set the frame data for each of them with notify states. The upshot is the system is robust and naturally primes you to develop your game in a way that feels very responsive to the player.

Thank you for the detailed explanation! I managed to lock the animations by having another boolean check if the player is reloading, so when either shooting or reloading it will set and check “can shoot” and “is reloading” accordingly.