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
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
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 hal 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
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