Yeah, that makes sense, thanks. And what you’re trying to do seems completely reasonable.
I don’t think there’s a better way to do what you want without some kind of code customizations. The basic problem is that we don’t track the number of times an animation has looped on a sequence player. So essentially, you need some logic somewhere to:
- Know when the animation has looped (using GetDeltaTimeRecord()->GetPrevious() and GetAccumulatedTime())
- Store that as state data somewhere (this could be in the custom struct I included in the example, or maybe on a custom sequence player node but that’s a more invasive approach since it requires more changes than a custom blueprint library implementation)
- Trigger a transition based on the looped value stored in the state data (this could be based on a bool set by a function, like in my example, or it could be custom transition logic added to the state machine code - again, more invasive)
So there are many ways that you could do this. But the custom logic in a blueprint library method is probably going to be the least invasive vs custom animation node and/or custom transition conditions. Another option entirely would be to do this with notifies that would mark the end of each idle animation, but again I wouldn’t recommend that since it would be error prone if someone left a notify off of one of the sequences.