[Solved] Issue with Real Time Attacks animation + input

Kirb

I've been trying for a while to debug an issue I've been having with inconsistent attack input in real-time combat; where pressing input to attack will do nothing. It is almost like an action queue that is temporarily backed up and doesn't trigger until you attempt again.

This is the setup:

I have a Control Map that has 'Attack with X Equipment Part' linked to an input button.

The Weapon in that equipment part has an Attack Override, so that it always uses an ability: 'Melee Attack'.

'Melee Attack' can be used constantly, over and over again. The Reuse Time is set to zero. So far, so good.

However, now I want to add a .4 second Wait Node inside of the Animation Battle Event for the Ability, so that I can give time for the attack animation to complete before completing the ability. In theory, this would add .4 seconds to the amount time it takes for the ability to be considered complete. (?)

If I try it once, or push it once every 1-2 seconds, it works perfectly. It is when I try to spam it over and over again where things begin to get a little inconsistent. Eventually, it will get into pattern of attacking twice in a second, then a full second or two of not responding to the attack button input at all. Rinse, repeat. There are no timeouts on any of the input buttons.

Any ideas? It feels like there's some weirdness or a bug somewhere caused by the wait node inside of the ability's Animation battle event.

Here's a video example of me spamming the attack button nonstop. You'll see how instead of a constant barrage of attacks, that there are awkward pauses where attack does nothing at all. I very rarely manage to get 3 attacks in a row, but usually I end up getting just 2 before an input fart.

http://spacejunkarlia.com/Test/attackdelay.mp4

Klep

It may be an issue with the Mecanim conditions you set in the Animator not resetting correctly. Does the timeout of each attack animation reset the bools/triggers when it returns to an Idle state? Each time you use an attack animation by using a Mecanim conditional, you need to consider when and where it returns to a state that is non-attacking but also attack-ready.

If that doesn't help, post some screenshots of your events and the Animator on your player object.

Klep

Another thing you'll want to check is whether your attack events are blocking each other. If you try to spam a blocking event it could be ignoring your input.

Otherwise you could be setting the Mecanim conditions out of order. So if pressing an attack button makes an Attack condition Bool true, then either the Ork event or Mecanim timeout might set it to false, THEN because you're spamming the button it would set it to true again prematurely before the events and/or animation timeouts are complete. That would result in a severe break in your event logic.

Kirb

Good ideas!

I actually don't use Mecanim, and even if I disable all of the animations, the problem persists. Only removing the wait node inside the battle animation event ensures that there are no strange gaps between attacks. (but having no timed animation is undesirable obviously!) None of the events are blocking, so that wouldn't be a problem.

Although... at the beginning of each Battle Event for the attack, I set 'PlayerIsAttacking' = True, and at the very end, 'PlayerIsAttacking' = False. Then I set a condition on the Control Map, where the player cannot attack unless PlayerIsAttacking = False. (This makes sure that the player doesn't use a ranged attack in the middle of a melee attack, etc).

While experimenting, I also tried setting the Attack Button input to HOLD only, so that I could just hold down the Attack button and see how it reacted. Resulted in the same behavior, two attacks followed by a small pause, and then another two attacks. Not quite sure what could be causing the break in the continuous attacks, but it does seem to be related to the wait nodes.

gamingislove

Did a quick test and not happening here. Think you can toss me a small Unity test project?

The PlayerIsAttacking flag shouldn't be needed, because a combatant can't fire another action while being in action anyway (i.e. control maps don't check for input at all when the player is in action). A combatant is in action as long as the action's battle events are running.

Kirb

Thanks! Didn't realize that, so removed the flags.

Not sure how easily I'd be able to shave down the project, though. Would the Project File and the Battle Event suffice in the meantime?

Here's another, better look at the weirdness. It is a bit more easy to see the same problem with the ranged attack. I am spamming the ranged attack button as fast as I can.

Here it is WITHOUT a single .1 second wait node in the animation battle event. It performs as expected: http://spacejunkarlia.com/Test/withoutwaitnode.m4v

When I enable a single .1 second wait node within the battle event, this is the result: spacejunkarlia.com/Test/WithWaitNode.mp4

This is me spamming at the same speed as the first video. A .1 second wait SHOULD be negligible, but something else seems to be happening, as is seen in that long gap at :04 where nothing happens despite button spam.

gamingislove

No, I'll need a ready to use test project - e.g. set up a new Unity project with your ORK project and the battle event with just a single scene and the used prefabs/assets instead of scaling your project down. The moment I have to set up or change stuff can already influence the test case.

Kirb

Gotcha, will work on getting you a repro case.

Kirb

Found the issue! Will tell everyone here just in case somebody catches themselves in the same trap. I was stripping down the project to create a repro case for GiL, and found that when I deleted a particular set of events, the problem stopped.

I had completely forgotten that I had Auto Global Events that check every 1 second if you are in an Event and not in control; and then Control Maps are disabled/enabled. (So that in every given not-in-control event, Control Maps are always disabled.)

I completely overlooked that it would also treat battle events the same way, so that 1 second would occasionally lock and unlock my control map, resulting in the inconsistent attacks! Stupid, but problem solved! :P

SIDWULF

Awesome :)