Zealot Flail heavy 1 delay (continued)

[Saryk]

Continuing the discussion from Zealot flail heavies delay :

I have identified the problem for the flail.
I do not think this is a bug because it is working as the code is written, but I do not know whether the code is written the way it is intended to feel (I think it isn’t).

For an explanation of what the images below mean, you can watch j_sat’s video, though I’ll do my best to explain the basics.

In the top left, you can see the current state we’re in, which is default. This is the standard situation you’re in when you are holding your weapon and not pressing any input ; a default state is also a state from which the game branches to attack states depending on inputs.

On this picture I’m holding LMB. At the bottom there is a time frame, and the white bar (at 0.28s on the screenshot) corresponds to the time since I entered the input - or since we switched states. The blue segment is the time frame during which, if I had released LMB, a light attack would have been initiated. Since I was still holding LMB past that 0.28s time frame, we skipped it.
When the white bar reaches the yellow segment on the 4th line, we switch to the Heavy 1 loop state, which is default_charge. Note that we can still block and switch weapons while we haven’t yet entered that state (second line represents an RMB input and third line any weapon switch).
Also note that I can release LMB at the point shown on the screenshot : nothing will happen. We are past the LMB release trigger that would have resulted in L1, and in the absence of any input that would change the state (namely RMB or a weapon swap), we follow the auto_chain link that sends us to the default_charge state.

Here’s the Heavy 1 charge loop :

You can see here that we are in the default_charge state. If I’m still holding LMB at 0.46s, the third line will trigger and loop us back to the beginning of that same state. Also note that we cannot switch weapon anymore : there is no action_wield trigger.
Now the interesting bit is coloured : the blue time frame is the one when, if LMB is released, you enter the Heavy 1 attack state. Therefore, if LMB is released during the red time frame, you have to wait until the white line enters the blue segment to trigger the attack animation, so up to 0.28s.
Releasing LMB before that blue segment begins effectively buffers the input until we reach that LMB release trigger.

Now here is the actual attack state :

The large red area represents the frames during which the attack is calculated and the hitbox ‘active’ so to say. You can see there is another 0.28s before it happens.

So if you release LMB during the initial default state represented in the first image, you have to wait 3 x 0.28s (this is actually 0.3, modified by my attack speed), so almost a second beween the release and the actual attack if you release as soon as possible, and up to 0.6 seconds if you hold it and have it spin.

This also brings some inconsistencies in the behaviour of the weapon, as sometimes you’re releasing LMB during the blue portion of the default_charge state and the attack is pretty much instant ; other times during the red part and the attack can take almost half a second longer.

Now that this has been said, let’s take a look at H2’s loop :

As you can see, the LMB release trigger’s time frame covers the entire duration of the loop. This means that, whenever you release LMB during the Heavy two spinning animation, the attack will hit 0.3s later, which feels reactive and consistent - and I’m pretty sure that H1 used to be this way.

All I’m saying is, change the LMB release event trigger’s time frame in the chained actions of the default_charge state from 0.3s - 0.5s to 0s - 0.5s to both match heavy 2 and fix the weird inconsistent behaviour depending on where in the loop you release.

This would result in a slight buff of the flail’s H1 because it would hit 0.3s earlier if you release LMB as soon as possible during the default state.
This is fine by me as I find that attack to be incredibly slow as it is (0.9s from release in default state as of right now) : 0.6s (from release in default state) seems reasonable.
If you count from the time you click and hold LMB, the delays are actually 1.2s right now and would be 0.9s after the change.

If the delay as it is implemented right now is intended in the design, you could tweak it by delaying the transition from the default state to the default_charge state from 0.5s to 0.8s, which would keep the charge time the same, but still fix the inconsistent behaviour when releasing LMB while the attack is “charged”.

Thanks for bearing with me through the long post.
Next up (probably tomorrow) : the bretsword Light chaining block-cancelling problem

[Saryk]

I have to check in game if this issue still persists, but this very long time during which the LMB release can be buffered if you release it in the default state could be the cause of the infinitely spinning flail bug when setting the input buffer to a lower value than 0.5.
I’ll have to also check the bretsword, which has a similar problem, but the flail should work properly (as there is an auto_chain trigger in default_charge that switches to heavy_attack, and that should trigger in the absence of a held LMB.
I’ll enquire tomorrow.

[xscyther]

They went about it in a weird way to keep the 2 attacks the same speed and as you said can cause the first heavy attack to be delayed if you released after the second auto chain. The second heavy avoids this by having a charge time of .8s instead of .5s + the .3 release delay. Either way, the attacks feel too slow and they don’t visually sync very well with the current timings as it looks like after you start swinging the ball in front of yourself, you rear the weapon back and swing right away which would make it lose all the momentum the ball had. Similarly with heavy 2, the attack starts when the charging animation has the ball swinging upward.

[Saryk]

Yes, you can see in the heavy_attack state that holding LMB goes to the default_left state, which is this one :

The delay before entering the default_charge_2 state is upped to 0.8s and it does feel alright to use.
Animations-wise, I agree, but it is less of a deal to me.