Hi, there are definitely some things we can improve here. First of all delay nodes are evil, try not to use them. Since we work with animations and states, I’d move all logic into the Animation Blueprint and give the State Machine full control over when state “attack” starts and ends. Then you wouldn’t need to mess with delays in the first place. The correct steps would be :
- Player presses button : attack > sets a bool on the animation blueprint to “AttemptAttack”
- The animation state machine moves into state “Attack” on AttemptAttack
- An animation plays. when the animation is nearly finished it goes back to idle automatically. You can get this bool by doing (“Get relevant anim time remaining *” < 0.1) which gets the remaining duration of your attack animation dynamically.
- If required, any state transition or event of entering/leaving a state can trigger an event on the EventGraph of the Animation Blueprint so you can put more logic in there as well.
That way you keep all logic in one place and no delay will ever mess up your intention.