Hi all ,
I read somewhere that State Machines can be troublesome with bugs etc.
I’m using ENUM in my BP scripting. Am I better off using Blend Poses Overall?
Is this best for a lot of different types of animations?
Thanks!
I haven’t noticed any issues with State machine, but it would really depend on what you’re doing. Both have benefits. Typically you would use a combination.
thank you @TorQueMoD
Is it ok to say have a state machine do a set of actions and plug it into a Blend By Enum as per my picture below?
I don’t know that it’s wrong to do it that way (I’ve never tested it myself), but think normally you save the locomotion to a cache and then use that in your bool. Here’s an example of how I’m using it:
Not so much as being troublesome but rather limited in scope. Sate machines work great as to poses that needs to operate with the same sequence. Lets take a simple jump where a state is needed for when the player leaves the ground. When the player is at it’s apex the animation state cycles through the required animation as to being <inair?> for the duration until the player is no longer inair and is allowed to exit from the state.
At first all things tend to work as expected but the more complex the state machine becomes the more difficult it becomes to scale the migration pathway “ON DEMAND” as to exit the state requires an exit statement, argument, that has to be filled first. In some cases this could be an argument that requires the animation to “wait” until a percentage of the animation is played out.
The other issue is state machines are difficult to scale as the need is added as part of the iteration process and the more complex the connection requirements the more, as you said, troublesome it becomes and breaks the rule of keeping complexity of design simple, aha KISS. 
“I’m using ENUM in my BP scripting. Am I better off using Blend Poses Overall?”
In my opinion using an ENUM to change the current state “ON DEMAND” is a logical approach as it isolates “context” based animations in a way that small, compact, and simple as well can scale when the need is presented as you only have to add the state changes to the migration path and switch to what is required as already decided via the use of the movement component.
In Technical Animation terminology this is called a animation tree, or simple tree, which uses the same pathway distribution as a state machine but does not need an exit statement, requiring the player state to wait.
I use the same Tree logic as to the need to change context based animations locomotion wise as to say run > Walk >Jump, Sprint as these are states that the controller has already determined so you only have to cast for the current state logic an plug it in with out having to play 20 questions which is generally used to make a state machine work as expected.
Tip. A blendPose is a general description of the current pose and not a means to describe how the pose is packaged as to the pathway migration.
In the end Trees work more or less the same way as state machines but are far more easier to follow pathway logic or adding details and there are more than a few benefits that goes beyond the scope of a forum topic.
Opinion wise I say trust your gut as I’ve come to the conclusion a long time ago that overuse of a state machine is not required and I usually look for ways to avoid using them.
P.S. I use state machines as a wrapper as to context animation logic. IE one for run one for walk one for idle ect.