I mean how you have the box for the player, then the player's sprite? Add another box that's attached to an image point where it's always in front of the player. This makes it SO much easier for detecting direction.
As for animations, you need to make sure the event "animation idle is NOT playing" etc to ensure your animations are in tact. Idle should be the lower most point of animations. Imagine the "idle" animation as if it were a rubber band. any new animation playing is like popping that rubber band, but it HAS to be back in place when it's over. Computers don't know to put things the way they were, just the last way you told them. So if you tell it "it should be this way" then you have it do something else, make sure "that way" isn't active, and when the new way is done, ensure the old way is back in place.
It's so hard to explain, which is why I'm not a teacher, but it works in my mind to think of animation and game states as rubber bands that get popped here and there, but after the popping is done it goes back to a general state (ie: idle, health restoration, enemies walking, etc). The state the game is in with ZERO input from the user is the default state you want, and any other state must be told "idle state is not playing" (and idle state should have "walking is not playing, attacking is not playing, jumping is not playing" etc.
I think comprehending the theory of game design is far more important than the code (with Construct 2 at least) but at the same time there are good practices no matter how one codes it. Just remember the computer isn't smart, you are.