[Melee Combat] How does Flurry Work? - Page 3

Disquette · 06/08/07, 1:59 AM

Yeah, in the example you showed, it's pretty clear that the Offhand hit is flurried even though the server message happens later. To pull just the interesting lines:

6/6 11:09:44.609  You crit Servant of Allistarj for 580.   MH
6/6 11:09:45.437  You hit Servant of Allistarj for 103.   OH
6/6 11:09:45.812  You gain Flurry.
6/6 11:09:46.828  You hit Servant of Allistarj for 271.  MH (2.22 second delay)
6/6 11:09:47.531  You hit Servant of Allistarj for 111.  OH (2.09 second delay) <- 2.8 speed weapon

So tired, bedtime.

Wandre · 06/08/07, 3:20 AM

Originally Posted by Disquette

The part that I don't see working with that theory is that when you have a single proc, you don't get just that hand sped up (I think). For instance, in that same combat log, check this part out from the very first flurry in the combat log:

6/6 11:06:54.125  You hit Servant of Allistarj for 98. (OH)
6/6 11:06:54.187  You hit Servant of Allistarj for 296. (MH)
6/6 11:06:56.734  You hit Servant of Allistarj for 237. (MH)
6/6 11:06:56.734  You crit Servant of Allistarj for 198. (OH) <-- flurry!
6/6 11:06:57.515  You gain Flurry.
6/6 11:06:58.781  You hit Servant of Allistarj for 290. (MH) - 2.047
6/6 11:06:59.062  You hit Servant of Allistarj for 104. (OH) - 2.328
6/6 11:07:00.031  You hit Servant of Allistarj for 269. (MH) - 1.250
6/6 11:07:01.187  You hit Servant of Allistarj for 101. (OH) - 2.125
6/6 11:07:02.140  Flurry fades from you.

(after that there are a bunch of regular hits with "normal" weapon delay)

In this example, Flurry is clearly evident on both hands (and wow @ that 1.25 delay main hand swing), even though only the off hand crit proc'd it.

This is from your first example.

The first problem with this is that your MH and OH attacks are both hitting/critting at exactly 11:06:56.734 whent he Flurry procs. This will cause the buff to be applied to both weapon swings and you will gain flurry on both weapons even though the Offhand procced the Flurry. Assuming that Flurry affects swing cooldowns any weapon connecting before the Flurry proc dissipates should gain the Flurry speed on subsequent attacks. This could mean Flurry would fade server side and apply to the cooldown of the OH before Flurry is actually unflagged by the code loop. It would easily account for the 4th fast swing. No idea where that 1.2 second attack came from though.

You should be able to see that the weapon that causes the crit will always be the first hasted weapon attack unless a crit occurs at the exact same time as the other hand hits in which case both swing timers will begin at a faster rate.

Another case to back up my previous swing cooldown theory is the fact that here:

Originally Posted by Universal

6/6 11:09:42.312  You hit Servant of Allistarj for 281.
6/6 11:09:42.687  You hit Servant of Allistarj for 107.
6/6 11:09:43.109  You cast Healing Stream Totem.
6/6 11:09:43.531  Flurry fades from you.
6/6 11:09:43.921  Servant of Allistarj hits you for 103.
6/6 11:09:44.609  You crit Servant of Allistarj for 580.
6/6 11:09:45.437  You hit Servant of Allistarj for 103.

You will note that the last hit before Flurry fades from the Main hand and refreshes still attacks at the same sped up swing time between the flurrys. There is a small error margin of 0.078 seconds between the two which is probably a lag issue in the client process. This reinforces my beleif that Flurry begins hasting swing "cooldowns" at the exact moment of of the crit and only after the buff (or code flag most likely) is removed will it stop the swing cooldowns from being reduced. That would mean the tooltip does not only haste 3 extra attacks but it puts haste on all swing cooldowns until the buff is removed.

Could this bring extra DPS to the table? Sure thing but you'd have to be lucky and all swings would have to be simultanious. Since the debuff is removed after the 3rd attack that swings you'd essentially have to have both hand swings connect at exactly the same time 3 times in a row and the offhand would have to crit on the first double swing because it seems to be processed after the MH.

Example (these are just random numbers but this is what it would look like):

00:00:05 You hit Servant of Allistarj for 207.
00:00:05 You hit Servant of Allistarj for 107.

00:00:07 You hit Servant of Allistarj for 207.
00:00:07 You crit Servant of Allistarj for 167. <=== Flurry actually starts here
00:00:07 You gain Flurry.

00:00:08.8 You hit Servant of Allistarj for 207.
00:00:08.8 You hit Servant of Allistarj for 107.

00:00:10.7 You hit Servant of Allistarj for 207. <=== Last Flurry charge used here. Swing timer refreshed before flurry is gone. Swing cooldown for MH is going at hasted rate.
00:00:10.7 You hit Servant of Allistarj for 107. <=== Would the swing timer resolve and restart before the Flurry flag is removed? Hard to test.
00:00:10.7 Flurry Fades from you.

00:00:12.6 You hit Servant of Allistarj for 207. <=== This hit resolves at faster swing speed because is was cooling down at a hasted rate.
??:??:?? You hit Servant of Allistarj for 107. <=== Depending on when the code refreshes the swing cooldown, this will hit at increased speed or not.

Further testing could be done to check this theory. It should show that you can obtain 4 hits at increased speed before Flurry fades rather than 3 swings as indicated in the tooltip.

If their code is actually checking on a per swing basis the data shown so far hasn't indicated that is the case, unless it's really a server process to client lag issue.

Disquette · 06/11/07, 4:32 PM

More testing, confirming some of what Wandre said above.

Here we have a 2.8 speed weapon which I'm single handing (with shield in offhand), which flurries to 2.15 speed. Please see attached screenshot. This is just one section of a great many that act the exact same way. Flurry rules (for one hand) are:

On a crit, immediately hasten the next 3 attacks.

While hasting the attacks, show the flurry buff on screen.

After the last of the 3 attacks is made, take off flury from the screen and reset swing to the regular speed.

In short, this acts exactly as we think it should on a one hand scenario. There is nothing ground breaking here, but since things are a bit wonky with dual-wielding, I figure I'd post proof establishing that the baseline of a one-hand encounter is done correctly.

Disquette · 06/11/07, 10:31 PM

Finally I took the time to fraps an encounter, and frame by frame it to see what the flurry buff was doing, and meshed that in with the combat log. Now, here's *exactly* how the client sees the data. Any takers on how it works?

EDIT: Ok, so i've been looking at this some. It's like the server will send messages and the client responds to repeats of the same message as superfluous:

51.02 Server says - give him 3
51.28 Server says - take away 1
51.88 Client says - Ok, he's got 3, going to start hasting the swings
53.20 Server says - take away 1
53.20 Server says - take away 1
54.20 Client says - Ok, I've taken away 1 charge, we have 2 left now, swings still hasted
(ignoring that it should have done it 3 times and been out of flurry right now)
55.03 Server says - give him 3
55.39 Server says - take away 1
55.76 Client says - Ok, he's got 3, swings still hasted
57.02 Server says - take away 1
57.59 Server says - take away 1
58.19 Client says - Ok, got it, I've taken away 1, we have 2 left now, swings still hasted
(even though, again, he should have taken away 3 in this period)
... skipping a few...
59.81 Client says - 1 charge left, this is the last swing I'm hasting, and proceeds to do normal attacks thereafter

Next up - test out this theory on the other data sets...

Disquette · 06/12/07, 2:25 AM

And, last message for the night. I think it's pretty clear that lag is responsible for the flurry chaining longer than it should be. Two attachments this time, one with a single crit, the other being a crit chain. The way of interpreting it is exactly as above. The client won't process more than one charge being used at a time. Even when you should see 2 flurry charges disappear with no hits registered in between them, it doesn't happen.

In the first attachment, the crit chain, you can see that sometimes a single hit will get back to your client in time for it to reduce the flurry charge before the next hit happens (lines 41.031 and 42.062). So, it's not a definitive "you get 2 hits for each flurry charge", especially since the hands were alternating hits nicely.

In the second attachment, the lone crit, you see a single crit providing 4 or 5 (I can't tell) flurried attacks.

So, now that we know this, the next question becomes... how do we model this?

Kiklion · 06/12/07, 2:29 AM

Thought id throw in old rapid fire didn't use its haste effect until after a shot was fired.

say 3 seconds until auto shot fires, use RF, its still 3 seconds and also 3 seconds wasted.

Use RF right before an autoshot and you optimize the RF.

drats · 06/12/07, 3:08 AM

I'm not trying to stop the theory-crafting, but if it seems like flurry is misbehaving in our favor should we continue trying to figure out the cause of it? When we (Nite_Moogle?) figured out and exposed the WF bug it eventually got nerfed/fixed. That ended up costing us a decent amount of dps. If they decide to 'fix' flurry, could the same thing happen?

Disquette · 06/12/07, 4:19 AM

Hm, maybe I'll never get to sleep. It's late, and I'm probably covering ground people already know, but I want to get this in writing so that you can correct me if I understand things incorrectly.

I started thinking about how the flurry strings can continue, and it seemed important to know if the game is set up such that swing timers can be altered mid swing. The obvious way for me to check this is with parry. I've heard it's 40% faster on your next swing, but when i used a 40% haste, that didn't work. However, if you interpret 40% faster to mean "take 40% off the swing time", that works out pretty well.

This means a 2.8 speed weapon, fully benefiting from parry would swing at 2.8 * (1 - 40%) = 1.68 speed. This is very different from normal haste formulas.

Anyway, check out what happens if you look at the following with a 2.8 speed weapon

Time      What         Result
0.00       Swing        Hit
1.00       MobParry   recalc swing timer
xxx        Next swing

What should xxx be?

If swing timers can be recalculated on the fly, xxx should be 2.8 - 1.0 (when the parry happened) * 60%. In other words, prorate the amount of speed increase due to parry based on how much of your swing is left.

If the parry happened at 2.70 seconds, there should be almost no haste (2.7 + .1*.6 = 2.76) . If it happens at 0.1 seconds, there should be almost total haste (.1 + 2.7*.6 = 0.1 + 1.62 = 1.72).

The graph lets us see how that formula matches up with swing speeds from my test usiing a single 2.8 speed weapon. In short, I do believe that weapon speeds can be altered mid-swing depending on events. This means that you really could have crit strings that are continued by a crit even when you're at 0 charges left on flurry. That is, it should run out, but the crit that happens while the flurry buff is still running and turns a 2.8 speed swing into a 2.15 speed swing, if the crit happens before the 2.15 from the last charge fading is up.

Anyway, on to the projected vs actual swing-delay-after-a-parry graphs (it's a beautiful name, isn't it). They're the same data, just the independent / dependent variable switched. The second one in particular looks pretty convincing to me, but as they say, there's lies, damn lies, and statistics.

panny · 06/12/07, 5:18 AM

It seems to me the easiest way to check whether haste can affect auto-attack mid-swing is to use a slow 2her and active an Abacus (or Bloodlust) mid-swing. I'm not sure why you went into the parry haste mechanics? (though it is interesting).

To rule the effects of dual wielding out in your lag theory, you could use a fast weapon under the effects of as much haste as you can find (Abacus + Haste Pots + Drums of Battle + Bloodlust + Flurry = 0.45 speed), and see if you get similar results of excess Flurry charges. What is the maximum delay that you have observed to not subtract Flurry charges? Sounds like perfect PTR work!

P.S. Thanks for all your hard work. It's much appreciated.

Disquette · 06/12/07, 5:48 AM

Originally Posted by panny

It seems to me the easiest way to check whether haste can affect auto-attack mid-swing is to use a slow 2her and active an Abacus (or Bloodlust) mid-swing.

I don't have any on-use haste trinkets, and I happened to have that pretty clean combat log lying around with the parries in it. The only haste-effect item i have is dragonmaw, and that would either only haste itself (so garunteeing a full swing's worth, *assumedly*), or I could dual-wield and see how it affected the other weapon.

That seemed like a much messier proposition to parse out, however. So I took the easy road of using a good test that I already had the log for ^-^

Originally Posted by panny

To rule the effects of dual wielding out in your lag theory, you could use a fast weapon under the effects of as much haste as you can find (Abacus + Haste Pots + Drums of Battle + Bloodlust + Flurry = 0.45 speed), and see if you get similar results of excess Flurry charges. What is the maximum delay that you have observed to not subtract Flurry charges?

I'm guessing a fast weapon would let even more attack slip through the lag, and be even more flurried, but I don't know that for sure. I know a couple 0.9 delay single attacks took away a flurry charge, and a couple 0.8 attacks got through without being charged. So, with my lag, somewhere around .8 or .9 seconds is the grace period, as far as I can tell.

Or maybe I have the mechanics wrong, I'm not entirely sure.

panny · 06/12/07, 10:00 AM

Originally Posted by Disquette

I don't have any on-use haste trinkets, and I happened to have that pretty clean combat log lying around with the parries in it. The only haste-effect item i have is dragonmaw, and that would either only haste itself (so garunteeing a full swing's worth, *assumedly*), or I could dual-wield and see how it affected the other weapon.

That seemed like a much messier proposition to parse out, however. So I took the easy road of using a good test that I already had the log for ^-^

You don't have Bloodlust? ;D

Disquette · 06/12/07, 12:39 PM

Heh, I truly hadn't thought of that. However, with server lag, you can see how often data is off of the expected value, and you get the most benefit by having a larger sample. I don't think I'd want to test one swing, midswing, every 10 minutes!

Bufford · 06/12/07, 5:21 PM

Originally Posted by Disquette

Heh, I truly hadn't thought of that. However, with server lag, you can see how often data is off of the expected value, and you get the most benefit by having a larger sample. I don't think I'd want to test one swing, midswing, every 10 minutes!

I have really enjoyed this thread, and have tried parsing my own combat logs, but have not come up with anything substantive to add. Maybe it is the math minor in me, but I will be really disappointed if all these discrepancies simply come down to "Server Lag".

Disquette · 06/12/07, 6:45 PM

I agree bufford, once i get up the energy to run "yet another set of tests" with fast weapons, we'll be able to see if it's server lag or not. I did this with a 2.6 and 2.8 weapon, so there should be a pretty pronounced effect if I use a couple of 1.4's

Machinator · 06/12/07, 7:00 PM

As far as parry goes do you have a link to anything showing its a 40% reduction? Searching for it turns up evidence it could be a 50% reduction or a flat time so that your next swing is at T+X or reduces T to a certain value if not lower such as .5.

Are the time left of swings held all server side? That seems a lot of traffic if the server has to tell the client each time a swing should take place, but if there is some client prediction that calculates swing time, if for nothing but animations it could be a clue.