I apologize for the length of this, but I have found this issue needlessly frustrating and I knew this was going to be too long for the general feedback page. As this is something that generally belongs there, if this is ignored I will not take offense. I just want to get this out there; though a reply would be appreciated.

In this game, there are some major issues with user input (at least with controllers, I am not using mouse and keyboard, though I would bet the issues I'll lay out are the same). As far as I can tell, all of them (with the exception of any caused by multiplayer lag) break down into issues in not checking the state of a given input. I'll give some examples here so that means something. I'll be using Xbox controller inputs in these examples.

1. Aiming down sight:
   While aiming (something you do more with Catti than anyone), moves in your list still apply. So while aiming down sight (holding left trigger) then pushing left stick forward and hitting right bumper, you will do the "Viper Fang Kick" move. It appears when detecting that move from the inputs, it does not check to see if the left trigger is down and it should. If this is by intent, fair enough, there are more examples here. I would contend that while aiming down sight, the moves (considering there are none that state to hold left trigger down) should not apply. If this is the intent, I highly recommend adding that check and giving the user the option to disable moves while aiming down sight.

2. Hold button attacks
   Between the characters, there are several attacks for holding a particular input (right trigger or right bumper with default controls). From what I can tell, the detection of these attacks starting is based on when the button or trigger moves from neutral to down. That would normally be fine, but, this game (rightfully so) has code to mitigate the input of button mashers, so inputs will be ignored when an animation is playing. (EX: if you hit right bumper 3 times, then right trigger, then right bumper before the first animation plays, you will do 2 right bumper attacks back to back, ignoring the other inputs).

Because of the code that will ignore additional input, what will happen very consistently is that you hold right trigger, then release to do the attack, then hold right trigger again a little too early and your character does nothing. For a hold button or trigger attack, the attack detection should be able to start with both "right trigger neutral to down" and "right trigger is down". Right now in my testing it clearly appears to be the former alone which leads to ignored inputs and frustrated players.

1. Button combination attacks This one is a little more foggy as I would need to see the actual input detection to know this 100%, however, I think my guess is close and this is something that needs to be addressed whether I'm right or wrong in the reason behind the flaw.

Button combination attacks (Y+B or A+X) are VERY finicky. A lot of the time instead of doing the attack that is triggered by A+X, you will just jump (just A). Same for the team attacks (Y+B) where you will often dodge (B) or use an ability (Y). I've played many a game that uses combination inputs, but they are generally much better at giving some leeway in the timing. If I were to guess, for an A+X attack, when one or the other goes from neutral to down, the game checks right then in the same cycle if the other is down. I'm not sure if you guys call the internal refresh rate of the game a cycle, that's just how I was taught long ago. Generally speaking a cycle is a very small amount of time so unless the user input is tiny fractions of a second precise, the game will take one button or the other instead of the combination as the desired input.

My recommendation here is to give multiple cycles instead of the one (or more if the game is already using more than one) to give some timing leeway so users are less frustrated.

Alright, that's the end of my lengthier than planned note. If you want any logs, please let me know, but given the subject being addressed, I figured those probably wouldn't be looked at regardless. If you have any questions my email is there and I'd be happy to demonstrate any of the issues I stated above.

Thank you very much for your time and my apologies for the long read,
Jay