When you attack with a Greatsword in Battle mode and before the first strike completes, if you perform a dash attack (i.e. CTRL + Attack button), the attack animation is glitched before the dash attack is performed.

The animation glitch appears to be similar to the one recently fixed in #1145.

This glitch does not occur when you perform the dash attack during the second attack animation.

Could you provide footage or something?

Sorry, I forgot to mention that I was pressing the forward key (i.e. 'W' key) during the attacks. I think its to do with the changes made in version 18.3.x which allow the character to move immediately after attacking animations.

I have attached a GIF.

What is the exact version of your epicfight?

I'm using EpicFight-18.3.3-beta.

Idk how you created the bug but this is when I tested in 18.3.3

That is strange..

I do see the glitch consistently in my current system by holding the "W" key (even before start of the first attack) and then issuing the dash attack just before the first attack animation completes. It appears as if the delay between the first and the second animation gets cancelled and the animation gets reverted in the opposite direction.

One thing for sure is this glitch did not occur in version 18.2.5 and the only thing that I have changed since then was updating Epic Fight version to 18.3.3 and Forge version (to run the latest Epic Fight).

I will try to test in various different setup/environments and see if I can also replicate the issue and get more precise details..

I have now tested with my laptop (using builtin keyboard and touch pad) and it was much difficult to replicate than using a mechanical keyboard and a mouse. However I can still replicate the issue consistently in the laptop environment by doing the following:

1. Remap sprint key to "\" and attack button to "Enter". I have chosen the keys to ease spamming in my laptop with my right hand. I guess any remapping could work.
2. Press and hold "W". Character will start moving forward. Do not release the "W" Key.
3. Hit (i.e. press and release) "Enter". Character will perform its first attack animation with Greatsword (I have used diamond Greatsword for testing)
4. Following immediately, spam "\" and "Enter" Keys alternatively, i.e. "\" >> "Enter" >> "\" >> "Enter" >> .. etc. to issue dash attack continuously.
5. Animation glitch will occur when the first attack animation completes. You may have to try few times to get the hang of it..

SOME NOTES:

• I don't needed to spam the dash attack when using a keyboard and a mouse but with a laptop, it was hard to get the timing consistent.
• I use HOLD Sprint (not Toggle Sprint).
• I don't use long press counter for Special moves (I have seperate key mapped for it)
• The workaround I use in my normal setup is to wait for the first animation to finish completely, give a slight delay and then issue the dash attack.
• Interestingly, I do not notice this issue with other weapons. Only with Greatsword, which is the main weapon I use.

Hoping you can replicate the issue and fix it..

Hi,

Just adding bit more details to the bug report:

I have traced the elapsedTime inside the method tick(LivingEntityPatch<?> entitypatch) of the AnimationPlayer class (src/main/java/yesman/epicfight/api/animation/AnimationPlayer.java) and have noticed the following:

When the 1st attack animation (id=96) from Greatsword transitions to dash attack animation (id=98) at elapsedTime 0.90 or 0.95+, I do not notice the glitch. However, when it transitions earlier, at elapsedTime 0.85, I see the glitch as described in the bug report.

Hi,

I have narrowed down where the issue is occurring.

It appears pose interpolation from near end of GREATSWORD_AUTO1 animation to beginning of GREATSWORD_DASH animation yields frames that rotates the character "backwards".

The bug is not easily noticeable as:

1. There is only about 0.20 seconds of window from GREATSWORD_AUTO1 attack recovery until animation completes.
2. The character may "move" or "sprint" before executing the dash attack, cancelling the GREATSWORD_AUTO1 animation.

This bug was not apparent in versions previous to 18.3.0 as executing an attack between recovery state and animation end was not possible.

To easily see the interpolation issue, you can switch around GREATSWORD_AUTO2 and GREATSWORD_DASH.
i.e. under /src/main/java/yesman/epicfight/gameasset/Animations.java

Version 18.3.3 has:

GREATSWORD_AUTO1 = new BasicAttackAnimation(0.2F, 0.4F, 0.6F, 0.8F, null, "Tool_R", "biped/combat/greatsword_auto1", biped);
GREATSWORD_AUTO2 = new BasicAttackAnimation(0.2F, 0.4F, 0.6F, 0.8F, null, "Tool_R", "biped/combat/greatsword_auto2", biped);
GREATSWORD_DASH = new DashAttackAnimation(0.11F, 0.4F, 0.65F, 0.8F, 1.2F, null, "Tool_R", "biped/combat/greatsword_dash", false, biped)
                .addProperty(AttackAnimationProperty.LOCK_ROTATION, true)
                .addProperty(AttackPhaseProperty.FINISHER, true);

You can swap GREATSWORD_AUTO2 and GREATSWORD_DASH, and also give high convertTime for GREATSWORD_AUTO2 (if you want to see the interpolation issue more clearly),
i.e.

GREATSWORD_AUTO1 = new BasicAttackAnimation(0.2F, 0.4F, 0.6F, 0.8F, null, "Tool_R", "biped/combat/greatsword_auto1", biped);
GREATSWORD_DASH = new BasicAttackAnimation(0.2F, 0.4F, 0.6F, 0.8F, null, "Tool_R", "biped/combat/greatsword_auto2", biped);
GREATSWORD_AUTO2 = new DashAttackAnimation(3.11F, 0.4F, 0.65F, 0.8F, 1.2F, null, "Tool_R", "biped/combat/greatsword_dash", false, biped)
                .addProperty(AttackAnimationProperty.LOCK_ROTATION, true)
                .addProperty(AttackPhaseProperty.FINISHER, true);

If you recompile the mod and perform continuous attack (constantly clicking left mouse button) with diamond greatsword, you will see the character is rotating backwards (anti-clockwise) instead of forward (clock-wise).

I can think of various workarounds but I am not sure what would be the best way to fix it.. Just hoping you can patch it in the next version in someway.

I really enjoy using this mod and I appreciate all your effort put into this mod.
Thanks

Thanks for your detailed instruction. It was really helpful.
But this problem is basically related to the animation transformation, not the game logic itself. So I don't think this is a bug but a little glitch that can be enhanced in the future. Maybe I can rework the greatsword animations in motion update.
Anyway, thanks again for your deep inspection!