I have a simple input function that works like this:
{
cooldownTimer -= Time.deltaTime;
if (cooldownTimer <= 0)
{
if (Input.GetButtonDown("attack")
{
//fire off attack animation in mecanim
}
if (input.GetButtonUp("attack")
{
//toggle charge value to false (unrelated)
cooldownTimer = 0.53f;
}
}
}
This works fine if I only press the button every 1 second or less. However, if I mash the button OR use the turbo setting in my controller, the attacks become sporadically unresponsive. My hero will attack maybe 2.3rds of the time, but occasionally freeze for a second or two – WAY longer than the cooldown – then attack semi regularly again.
Expected behavior is that the hero will attack at the exact same controlled pace no matter how quickly I mash on the button. The odd thing is, I can SEE the debug script and I can see the box I set up for (cooldownTimer <= 0) checked very, very quickly, and then turned off, during the times he does not attack. So the attack input is being accepted and doing nothing during those random periods.
Another interesting stat is that I logged the attack and release code segments and the longer I hold down turbo or mash the button, the more frequently the release code is called than the attack code.
Turning off the cooldown and not using it fixes the issue completely, but then of course the attack animation resets too quickly.
Is this a bug in Unity’s traditional Input interface? Or is there some edge case I’m being an idiot and missing?
Probably because your key upkeep resetting the timer. Change your logic so the GetButtonDown resets the timer and don’t worry about the get-up event. I’d probably move the cooldown if statement into the KeyDown event as well.
Thanks, but that didn’t fix the problem. Erratic seconds of non-attacking still happen during the mashing, and removing the if statement fixes it, so I know the issue is directly tied to this cooldown method and not the animation itself. Hmm.
Did you retype that? Because lowercase input isn’t actually a thing, plus you have mismatched parenthesis in both of the if clauses… in other words, the code above is not running, I assure you.
Just checkin’ … Unity has a fairly common state it gets into where it fails to notice files changed and won’t recompile, and runs with the previous assembly DLL.
as mentioned above, your keyup is resetting the cooldown timer
you should also pay attention to your animator state machine. Im not sure exactly how you’re firing off your attack animation, but transitions between states have durations, and depending on your settings the transitions may only be able to happen at certain parts of the animations.
Thanks, but I tried moving it to keydown and it didn’t fix the issue, and it’s tied to the cooldown, not the animation, because removing the cooldown fixes the issue 100% (Except for the animation resetting too quickly, which is why I wanted a cooldown to begin…)
Okay, this is kind of weird, but I had to work around the issue by removing the cooldown altogether and making sure the animations looped. Evidently there was a second problem much like the first problem, where even though I had an exit time of 1 and a transition time of 0 from “attack/charge” to “idle”, there was a teeny, teeny gap of time where the attack/charge animation would occasionally get stuck at the end while I was mashing buttons and not transition for a few seconds. Looping the animation (but keeping the exit time and not allowing it to transition to itself) fixed the issue.
I was clearly not 100% correct in assuming the animation itself had nothing to do with it. I hate mecanim. I should have just rolled my own 2d animator.