I heard, that i need Notifies. If it’s right version, can u describe code in C++?))
YMMV, but notifies are nice for anything internal to the a specific animation but bad for anything generalized that is always needed outside the thing being animated:
Animation Notifies in Unreal Engine | Unreal Engine 5.1 Documentation
We have a basic C++ system comprised of these general functions:
- PlayAnimation() - plays a specified animation
- OnAnimationBegin() - event when an animation starts playing
- OnAnimationEnd() - event when an animation ends playin
- GetIsAnimating() - return true if an object is currently animation
How you implement those is quite game or framework dependent. But with those basics you know when an animation starts, ends, or is in progress. Use that to change states or head off any unwanted inputs.
Notifies/NotifyStates are just frame data. They trigger at animation frames. They’re not ideal candidates for game logic because animations blend and cancel, and how they blend and cancel changes how notifies trigger, which can make them somewhat unreliable, especially in a variable-framerate environment (there are ways around this that UE doesn’t expose natively which let you limit the game’s lowest frame rate so that you can be sure frame data is not skipped, but often that’s overkill unless you have a HEAVY reliance on frame data in your game). If you tie game logic to animation playback, you run the risk of anything unexpected that interferes with that animation playback interfering with game logic too. That’s a situation to avoid if you’re able to.
Say you were to call a “got knocked down” animation on a character in the middle of a reload animation; well, now that animation is overriding the reload, so the notifies at the end of the reload won’t fire. But if you’ve shut off all other player inputs until it sees the notify at the end of the reload animation, now you’ve got the player stuck where no inputs work because those notifies are never coming. It takes a lot of planning to use notifies well for logic because of all these sorts of cases (if you do, NotifyStates help a lot since they are guaranteed to end).
My controversial opinion: You still kind of can’t get around using notifies for event logic, if you need that event logic to be tied to the animation at specific frames.
As Shmoopy mentions above, if all you care about is “I am in an animation”, there are better ways (and better ways than that, if you’re using montages, you can use Montage_IsPlaying/OnMontageBlendingOut to check for active anim montages, which will exclude ones in the blend-out stage). What you CAN’T do with that is, say, give an animation an “exit phase”, so that if you remain idle, the character, for instance, slowly transitions back to an idle animation, but you can interrupt it early by moving as long as you are past the active frames of the animation. You can’t set up a reload animation so that if you press weapon switch after the magazine has been discarded but before the new one is in-hand, you cancel the reload with no ammo in the gun, but once the magazine has been inserted, if you press weapon switch the gun has full ammo.
To do that you either need to use timers that call game logic events and sequential animations simultaneously, so that the game logic is fired independently of the animation but happens-to-be-in-sync with it (which works but can be a mess, especially with animations getting cancelled)… or use notifies so you can have the animation report “I have reached frame 71, even though I have another 32 frames left you can unlock the inputs now” or “I have reached frame 45, even though there are still 28 frames of animation left the gun can now be considered back at full ammo”. It can be frustrating to an end-user to see that a magazine is in the gun, get knocked down afterward, and find that he still has not “completed the reload” because his character did not fully finish moving his hand back to the grip so the game hadn’t yet sent the OnAnimationEnd call.
So, depends on your use case. But to my way of thinking the rule-of-thumb that says “only use notifies for stuff that’s animation-specific like particles or blends and don’t tie game logic to it” only holds up where game events and animated behavior are not intended to be synchronized. If you have an animation that runs for XYZ frames, and you need specific stuff to happen halfway through, and other stuff to happen 2/3rds of the way through, etc., even if it’s gameplay related (character can’t jump, character can’t switch weapon, character gets ammo refilled, character regains health, projectile is spawned, whatever), and ESPECIALLY if you want that behavior to go away if the animation goes away (i.e. if the player presses the dive button in the middle of the giant laser cannon windup firing animation, you don’t want the giant laser cannon to fire even though the firing animation is no longer playing), you’re best served using notifies.