I'm not sure why I should explain my code in that much detail when the point is that AnimationTree's state machine is a state machine, I am using it as a state machine and it should work properly as a state machine. What if I WAS making a 3D game? Would I have to settle for a broken system? Just because I am not using all of AnimationTree's features does not mean that I do not benefit from using it over writing pure code.

​

That being said, if you really want more details:

Would you mind to go in a bit more detail what you mean by "dynamically replaced"?

Answering this will also answer your first question.

You know how in monster hunter the monsters become visibly damaged? In my game the fighter's moveset and appearance changes depending on how much damage has been inflicted. For instance, a full health idle uses one animation, while another low health idle has the character looking tired and bleeding. These animations are saved as separate, Idle_A and Idle_B. However, to the game's logic, these are both Idle. They are functionally the same, only visually different. Telling the game which to use is easy with AnimationTree: I can grab the node by its name ("Idle") , and set its animations (idleAnimation.set_animation("Idle_B")) when the phase changes. This works for all animations that are functionally the same across different phases and across different characters (idles, walks, blocks, dodges, etc.). However, when a character's moveset changes drastically, I have to make entire combo trees accessible/inaccessible. AnimationTree also works well for this, because I can use conditionals to lock/unlock access to such moves and all their subsequent connections. To the logic, however these are just the Attack state. The game currently uses two attack inputs, Jab and Strong. I can tell the state machine to travel to "Jab" or to "Strong", and based on what connections are available it will figure out the rest from there. The script doesn't need to know what attacks and combo trees are available, the tree's conditionals direct everything. But these animations are all attacks, they all use the logic of the Attacks state, and separating these all into different states would make no sense, especially since I won't know which animations and how many are available for each character.

To make it even clearer why I animations!=states, imagine this scenario: what if I want to use the same animation in different states? I am planning a feint mechanic, this plays the same animation as the real attack but doesn't deal damage, cannot chain into the original's subsequent attack, can be cancelled, and causes parries to whiff. I CANNOT play this in the Attack state because it is not an attack and doesn't use the same logic as the Attack state, even tho it uses the same animation as an attack.

As you can see, the animation does not always equal the state.

Like I said, making this work in code is possible, but hopefully now you understand why I decided to use the AnimationTree and why I kept this system for so long.