Thanks @Jamez0r for the help!

@RA31596 Please keep in mind that using SkeletonMecanim with the Mecanim state machine instead of SkeletonAnimation can still benefit from arranging your player game logic code into states. To be able to handle complex behaviour easily, game logic code should contain the high-level game state of your player which then triggers lower-level visualisation changes - your animations. Then every player state will handle only events relevant in the current state (let's say jumping or reloading in state InAir is not possible for example), and transitions only to possible other states. When it collides with the ground it transitions to a Landing state for example. Starting LandingState starts a landing animation. When landing animation is complete it transitions to Standing state, and so on.

It then does not matter whether an animation is started via setting a Mecanim trigger or by calling SkeletonAnimation.SetAnimation() or SkeletonAnimation.AddAnimation(). Perhaps that's a bit too much for now, but just keep this option in mind when your nested if() {} else {} branches are getting more and more complex and ugly and are no longer easy to maintain.