I know I'm super late but just wanted to add this. Another advantage with AnimNotifyStates is that once the Begin trigger has fired, the End trigger will always fire, even if the animation is interrupted.
While only mildly related, this video helped me solve a problem that no one on any platform/forum has been able to help with (changing weapon trail colors based on user variables). Subbing and liking. Great info here.
you'll have to cast every time, which is why it's important to try to make this function use a cast for a class that's as wide as possible ( like using the character class itself, then anything that's a child of character can use this). the casting itself takes not a lot of compute power, it's mostly a memory thing which isn't an issue in this case
@@thegamedevcave oh yes of course that makes perfect sense. Thanks so much for that tip, really interesting. Would love to see more content like this. Thank you 🙂
@@thegamedevcave no better would be to cast once, make a reference of your character and then call the getter and make a "is valid node" you will save yourself every time a cast, which is not bad on memory until you do it often. BP is not code, the thing with BP is even disconnected nodes count as hard reference/Dependency which will be loaded into the memory even if not used, unlike C++. Just something to remind yourself. Now casting is not the worse thing, but it's design flaw specially when it can be avoided and here it's easy to avoid. Make a reference on begin play (so cast to), then call the reference, check if it's valid and you have no cast to do, easy peasy ;)
Issue is that the anim notify state is a class all by itself so every time it runs it needs to get that value. You could store that to prevent the 2nd cast but when the notify ends it doesnt stick around for the next time the animation plays, thats a whole new instance which needs ti get that refernece again. An interface may be a better option though
very clever use for it! 100% would work, waiting for 2ndacry input or combing during an animation. honestly didn't think of that (my head is so deep in the Gameplay ability system , which has other solutions for that XD)
it would work better on anim notify though, if the button is not triggered before this notify then end the attack otherwise the attack is saved and you go on to the next. Anim notify state is more for a duration, something ongoing. For instance during that time you don't want the player to be able to perform anything you use a state, let's say like jump, during the anim notify state anything pressed during the jump is returned false so if the player smashes the button nothing happens until the anim state ends and then it can be triggered again, for instance.
Thats also a good point. Thoygh i suppose if you want a input to only count during a certain portion of the animation (not right from the start) the notify state becomes more relevant again. Since you probably dont want to allow the next input to be registered until a certain part of the animation (depending on the type of game of course)
Okay, I will play advocate's devil here, just to give some material for debate. So I do agree that anim notify states are more interesting for some specific cases, I don't think using anim notifies are wrong. The issue here is the way everything is set up. The fact that the particle is called on the notify when it could be hardcoded instead, why not have the play play on the death of the character and then the notify is the only thing that stops it. I personally don't call my particles on the animation, same if you are using a particle let's say shoot you don't need to activate in the beginning and then deactivate it on the end you can just call it once. Now I know in your example it's about keeping the animation going for a set of frames and the anim state notify is the better way in this case, but then you are casting twice which isn't also good practice (sure you can get away with but it's not good practice). So there's much to think about :). So I'm just playing advocate's devil, the title of the video is click bait because using anim notifies is not wrong it's situational.
The title and thumbnail refer to using 2 notifies for turning off and on instead of using a sinlge notify state. Also, casting isnt as bad as you think here. Casting is bad because it creates hard refernces to other classes which can be bad for memory because if you cast to a class which also casts toother classes, you are loading all those classes into memory without neesing them. But nothing is ever going to cast to this notify so that never becomes a problem. The actual computing cost of a cast is fairly low "casting is vad practice" is generally true but its important to understand why so yoy know where to not use it and where its ok to :)
@@thegamedevcave Dynamic casting is bad because it needs to check the type on the runtime. That's the only reason why it is bad for computing performance
I disagree on always needing to avoid casting when you can, you have to understand what is bad about it, amd how that impacts your preformance on a case by case basis. Its good to avoid casting when you can generally but its revelant to think about the reason why and if that applies to the situation, whuch is this case it doesnt really. You may be able to replace it with an interface though which would be a bit better but in this case it really doesnt matter.
Loved the video! How would you feel about using an interface call to a master actor of enemy types instead of casting to any particular enemy? You could send the interface call from the anim notify state as needed. You only have to code the interface on the master actor and let the children use the inheritance.
if youre going to only have 1 implementation of the interface on a parent class, you may as well jsut make it a normal function honestly. especially if it's being called from an animation. because whenever that animation plays, the character (and it's class/ parent class) are loaded in memeory anyway so the cast doesn't realyl have any significant cost to it. Now, using an interface is more flexible of course if down the line you decide you also want to be able to use a notify on an animation that runs on something that doesn't inherit from that parent enemy class. So the question would be how likely do you think that you'll end up wanting to be able to do that? if the answer is " i'm not sure" an interface is the safe option. if the answer is "very unlikely" you can just stick to a cast and it'll be fine.
This is great! Do you know is there a easy way to bulk edit all my existing notifies of a given type to use my new notify state bp so I don't have to manually open up every animation?
not really. either way it doesn't make much, if any real difference honestly. If anything, making essentially the same function on a bunch of animation blueprints is worse than having a blueprint notify that you can reuse. It's godo to make them as generalized as possible though, so dont go making a notify which then casts to a specific character class so you can only use it on animations for that character. Those are best left to just inside the anim blueprint. but things that can run any sort of more general code, or an interface you're probably better off using a blueprint notify that you can re-use.
casting in classes like this isn't' a big issue, the danger with casting is that you cast to classes that cast to even more classes. With this, you're simply casting to a class that is already loaded anyway so there really isn't much of an issue. Of course, if you want to use this notify on animations for different characters that are different classes, that's where doing this with an interface will probably be better and easier to work with.
yeah as far as I know flipbooks are mostly meant for particle materials in unreal. if youre trying to use them for 2D rendering or sprites you're gonna have a bad time XD unreal dropped official support for it's own 2D plugin a while ago even so it's going full in on being a 3D only engine
I know I'm super late but just wanted to add this. Another advantage with AnimNotifyStates is that once the Begin trigger has fired, the End trigger will always fire, even if the animation is interrupted.
While only mildly related, this video helped me solve a problem that no one on any platform/forum has been able to help with (changing weapon trail colors based on user variables). Subbing and liking. Great info here.
Glad i could indirectly help!!
I didnt have that problem yet, but I sure am glad to have found a solution.
That's very interesting, do you have to do a cast each time to the owner of the mesh or is it possible to inherit it?
you'll have to cast every time, which is why it's important to try to make this function use a cast for a class that's as wide as possible ( like using the character class itself, then anything that's a child of character can use this). the casting itself takes not a lot of compute power, it's mostly a memory thing which isn't an issue in this case
@@thegamedevcave oh yes of course that makes perfect sense. Thanks so much for that tip, really interesting. Would love to see more content like this. Thank you 🙂
@@thegamedevcave Could you not use a blueprint interface?
@@thegamedevcave no better would be to cast once, make a reference of your character and then call the getter and make a "is valid node" you will save yourself every time a cast, which is not bad on memory until you do it often. BP is not code, the thing with BP is even disconnected nodes count as hard reference/Dependency which will be loaded into the memory even if not used, unlike C++. Just something to remind yourself. Now casting is not the worse thing, but it's design flaw specially when it can be avoided and here it's easy to avoid. Make a reference on begin play (so cast to), then call the reference, check if it's valid and you have no cast to do, easy peasy ;)
Issue is that the anim notify state is a class all by itself so every time it runs it needs to get that value. You could store that to prevent the 2nd cast but when the notify ends it doesnt stick around for the next time the animation plays, thats a whole new instance which needs ti get that refernece again. An interface may be a better option though
A good use case might be for combo animations? On tick wait for an input, if no input, finish combo. Very cool vid!
very clever use for it! 100% would work, waiting for 2ndacry input or combing during an animation. honestly didn't think of that (my head is so deep in the Gameplay ability system , which has other solutions for that XD)
it would work better on anim notify though, if the button is not triggered before this notify then end the attack otherwise the attack is saved and you go on to the next. Anim notify state is more for a duration, something ongoing. For instance during that time you don't want the player to be able to perform anything you use a state, let's say like jump, during the anim notify state anything pressed during the jump is returned false so if the player smashes the button nothing happens until the anim state ends and then it can be triggered again, for instance.
Thats also a good point. Thoygh i suppose if you want a input to only count during a certain portion of the animation (not right from the start) the notify state becomes more relevant again. Since you probably dont want to allow the next input to be registered until a certain part of the animation (depending on the type of game of course)
Okay, I will play advocate's devil here, just to give some material for debate. So I do agree that anim notify states are more interesting for some specific cases, I don't think using anim notifies are wrong. The issue here is the way everything is set up. The fact that the particle is called on the notify when it could be hardcoded instead, why not have the play play on the death of the character and then the notify is the only thing that stops it. I personally don't call my particles on the animation, same if you are using a particle let's say shoot you don't need to activate in the beginning and then deactivate it on the end you can just call it once. Now I know in your example it's about keeping the animation going for a set of frames and the anim state notify is the better way in this case, but then you are casting twice which isn't also good practice (sure you can get away with but it's not good practice). So there's much to think about :). So I'm just playing advocate's devil, the title of the video is click bait because using anim notifies is not wrong it's situational.
The title and thumbnail refer to using 2 notifies for turning off and on instead of using a sinlge notify state. Also, casting isnt as bad as you think here. Casting is bad because it creates hard refernces to other classes which can be bad for memory because if you cast to a class which also casts toother classes, you are loading all those classes into memory without neesing them.
But nothing is ever going to cast to this notify so that never becomes a problem. The actual computing cost of a cast is fairly low "casting is vad practice" is generally true but its important to understand why so yoy know where to not use it and where its ok to :)
@@thegamedevcave Dynamic casting is bad because it needs to check the type on the runtime. That's the only reason why it is bad for computing performance
@@Sk4Le3was going to say. The debate got more added to it :)
@@thegamedevcavewhat I mean by "bad practice" it's always best to avoid it when you can.
I disagree on always needing to avoid casting when you can, you have to understand what is bad about it, amd how that impacts your preformance on a case by case basis. Its good to avoid casting when you can generally but its revelant to think about the reason why and if that applies to the situation, whuch is this case it doesnt really.
You may be able to replace it with an interface though which would be a bit better but in this case it really doesnt matter.
Loved the video! How would you feel about using an interface call to a master actor of enemy types instead of casting to any particular enemy? You could send the interface call from the anim notify state as needed. You only have to code the interface on the master actor and let the children use the inheritance.
if youre going to only have 1 implementation of the interface on a parent class, you may as well jsut make it a normal function honestly. especially if it's being called from an animation. because whenever that animation plays, the character (and it's class/ parent class) are loaded in memeory anyway so the cast doesn't realyl have any significant cost to it.
Now, using an interface is more flexible of course if down the line you decide you also want to be able to use a notify on an animation that runs on something that doesn't inherit from that parent enemy class. So the question would be how likely do you think that you'll end up wanting to be able to do that? if the answer is " i'm not sure" an interface is the safe option. if the answer is "very unlikely" you can just stick to a cast and it'll be fine.
My files is so horrible I have to color code them in order to know where things are
I feel your pain 😭
This is great! Do you know is there a easy way to bulk edit all my existing notifies of a given type to use my new notify state bp so I don't have to manually open up every animation?
Hmmm not that i know
Incredible video perfect timing for me thanks!
Yes but doing it in every anim blueprint is better for memory no ?
not really. either way it doesn't make much, if any real difference honestly. If anything, making essentially the same function on a bunch of animation blueprints is worse than having a blueprint notify that you can reuse. It's godo to make them as generalized as possible though, so dont go making a notify which then casts to a specific character class so you can only use it on animations for that character. Those are best left to just inside the anim blueprint. but things that can run any sort of more general code, or an interface you're probably better off using a blueprint notify that you can re-use.
Didn't know about that. Thank you
Don't cast. Use interfaces. I see in the sidebar that this guy has a video on that too
casting in classes like this isn't' a big issue, the danger with casting is that you cast to classes that cast to even more classes. With this, you're simply casting to a class that is already loaded anyway so there really isn't much of an issue. Of course, if you want to use this notify on animations for different characters that are different classes, that's where doing this with an interface will probably be better and easier to work with.
Can you make a tutorial on this part of the editor? Animation? Like keys, stuff, etc? Pleeeeeeeeeeease! There's nothing valid on the web!
what exactly is it you want me to cover?
Damn it! There is no same feature for flipbook, why epic, why!?
flip books dont have any sort of anim notifies right? i'm not super familiar with using them though i'[ll be honest XD
@@thegamedevcave Yes, nothing for flip books, Unity has the whole package for 2D animation though.
yeah as far as I know flipbooks are mostly meant for particle materials in unreal. if youre trying to use them for 2D rendering or sprites you're gonna have a bad time XD unreal dropped official support for it's own 2D plugin a while ago even so it's going full in on being a 3D only engine
@@thegamedevcave With C++ in hand, we can make one for ourselves, can't we?
@WeirdGoat you're gonna need paper Zd