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

Wandre · 06/07/07, 7:24 PM

Perhaps if a swing cooldown starts while your flurry buff is active but before the last charge is consumed it will continue at it's "hasted" rate.

This would prove more likely as this happens with spellcasting and slow. If I cast a spell while slow is up but slow then dissipates before the spell is over I still retain the slowed casting time.

That would explain an extra attack from an opposit hand. I'll put good money on the fact that you'll never see 2 swings from the same hand connect at a faster speed when you see 4 hasted hits. Maybe using 2 same speed weapons would help prove this theory.

Edit: This would also mean that you will always score 3 attacks when using only 1 weapon but generally score 4 attacks at hasted speed with dual wield as long as your weapons start a swing cooldown before the last charge is used.

• Disquette · 06/07/07, 7:29 PM

Originally Posted by Wandre

Perhaps if a swing cooldown starts while your flurry buff is active but before the last charge is consumed it will continue at it's "hasted" rate.

I like this theory.

Slant, I'm just having trouble with reconciling what you saw (the strings of six, as I highlighted) when the single-hit versions only show 4 hasted attacks. I'm going to get more data after lowering my crit rate. There's too much noise in the data currently, but with a 5% crit rate or so it should be easier to identify different scenarios clearly.

Wandre · 06/07/07, 7:40 PM

If this is true then a swing cooldown in progress would never be altered, ergo the first swing to be hasted would be any swing cooldown that starts after the crit lands.

So yellow attack crits would normally proc flurry and the white attack that follows would have to connect once before it's hasted cooldown began. This could actually reduce the effectiveness of Flurry if you crit yellow attacks right after a white attack fired. That would probably be the cases of 3 hasted hits rather than 4 when using 2 weps.

White hit (start normal cooldown)
Instant Yellow crit (Flurry 3 charges)
White hit (start hasted cooldown and eat charge)

That's an example of what would happen if you yellow crit with an attack. Heroic strike would actually be a better attack because it uses the swing timer and you'd achieve the 4 hasted swings when DWing. Attacks like Stormstrike and Hamstring which fall outside the swing based attacks would eat charges prematurely.

slant · 06/07/07, 8:35 PM

Wait, you show 4 hasted attacks with only one weapon equipped? So much for my theory, then. I guess it was just client/server latency.

Universal · 06/08/07, 1:38 AM

I am pretty sure that slant's 2 procs theory isn't the explanation. For one thing, the example explanation shows OH crits refreshing the MH counter. I tried 15ish rules for how to decrement from the different procs, but none of them were consistent with both the long sequences Disquette originally posted. Furthermore, consider this sequence:

6/6 11:10:10.890  You crit Servant of Allistarj for 512.
6/6 11:10:11.171  You crit Servant of Allistarj for 202.
6/6 11:10:11.671  You gain 18 health from Healing Stream Totem VI's Healing Stream.
6/6 11:10:11.968  Servant of Allistarj misses you.
6/6 11:10:12.781  You hit Servant of Allistarj for 268.
6/6 11:10:13.296  You hit Servant of Allistarj for 102.
6/6 11:10:13.765  You gain 18 health from Healing Stream Totem VI's Healing Stream.
6/6 11:10:13.968  Servant of Allistarj hits you for 81.
6/6 11:10:14.890  You hit Servant of Allistarj for 279.
6/6 11:10:15.703  You hit Servant of Allistarj for 109.
6/6 11:10:15.703  You gain 18 health from Healing Stream Totem VI's Healing Stream.
6/6 11:10:15.984  Flurry fades from you.
6/6 11:10:16.000  Servant of Allistarj attacks. You dodge.
6/6 11:10:17.296  You hit Servant of Allistarj for 269.
6/6 11:10:17.687  You gain 18 health from Healing Stream Totem VI's Healing Stream.
6/6 11:10:18.093  Servant of Allistarj hits you for 84.
6/6 11:10:18.406  You hit Servant of Allistarj for 106.

A pair of crits generates only 4 procs and then fades well before any further attacks.

I also believe that the various lag based theories are incorrect. Look at Disquette's two original examples. Even if we allow that lag may allow some extra flurried hits (which seems plausible), the flurry buff itself is fading far too late. The buff fades 3 full seconds after the last hit which "should" have been flurried. Furthmore, at least in the data we have, this only happens after flurry chains. Unless chain flurries are themselves creating some sort of processing lag, it seems unlikely that no one would have noticed regular 3 second lag in other contexts before.

I don't have any answer myself. My wild guess was going to be some sort of variable overwriting but where 2 swings only use one charge if they hit close enough together. But this doesn't mix with only chain flurries going all the way to six. I do have one observation that may be useful though:

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.
6/6 11:09:45.609  You gain 18 health from Healing Stream Totem VI's Healing Stream.
6/6 11:09:45.812  You gain Flurry.
6/6 11:09:45.828  Servant of Allistarj hits you for 96.
6/6 11:09:46.828  You hit Servant of Allistarj for 271.
6/6 11:09:47.531  You hit Servant of Allistarj for 111.
6/6 11:09:47.734  You gain 18 health from Healing Stream Totem VI's Healing Stream.
6/6 11:09:47.953  Servant of Allistarj misses you.
6/6 11:09:48.562  Flurry fades from you.

This is an example with only 2 flurried swings. Note that in this case there is actually another hit before the flurry buff appears. So it seems like whatever mechanism is used, this hit is charged to flurry even though it happened before flurry occurred! This would be consistent with some sort of queueing mechanism. If, for example, it queues a ProcCritEffects() for the crit followed by a ProcHitEffects() for the hit, then this outcome would make sense because by the time the hit effects are examined flurry will have procced, even though the hit occurred before flurry procced.

• Disquette · 06/08/07, 2: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, 4: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, 5: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, 11: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, 3: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, 3: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, 4: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, 5: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, 6: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, 6: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, 11: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, 1: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, 6: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, 7: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, 8: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.

slant · 06/12/07, 8:04 PM

Originally Posted by drats

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?

That's certainly a pragmatic view, but it's one that I can't subscribe to. If you truly feel that the developers are actively working against the best interests of the game, you should stop supporting this behavior by cancelling your subscription. It's naive to think that they're unaware of these things; it's not 1999, everybody is running tests and theorycrafting these days, and blizzard is not verant. We may not agree with many of their decisions, but they do appear to be informed ones.

As far as flurry goes, I really liked my theory. It was elegant. Pity it turned out to be simple server lag, something that's very difficult to model programmatically.

• Disquette · 06/12/07, 8:13 PM

Originally Posted by Machinator

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.

No link other than the one in slant's faq, and i remember reading it somewhere. It also happens to match the test data in those graphs *really well*. I had thought it'd be a flat reduction or something like that until i started seeing swings after parries that were almost a full timer. The only explanation I could think was a prorated swing haste. The correlation with a prorated model (the blue line in the graphs) to the observed data seems way too high to be just chance. Evidence of a 50% reduction seems to me like an average of a prorated scenario.

After all, If I simply took the average of the swing times in the combat log, it would indeed look like a 50% or so reduction. That really doesn't tell the same full story that the testing does.

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.

My current theory is that the swing time is held client side and then sent up to the server, which can over-ride it if an event occurs and the message from the server gets sent back to the client in time. Also, I've learned not to watch animations for help, as watching my combat log shows that the events take place way far off from the animations some times.

Originally Posted by slant

That's certainly a pragmatic view, but it's one that I can't subscribe to. If you truly feel that the developers are actively working against the best interests of the game, you should stop supporting this behavior by cancelling your subscription. It's naive to think that they're unaware of these things; it's not 1999, everybody is running tests and theorycrafting these days, and blizzard is not verant. We may not agree with many of their decisions, but they do appear to be informed ones.

I agree completely with this response. I'd rather we know how stuff works. The only way developers wouldn't know about this "issue", if it really is lag-driven, is if they only doing testing on 0 (or close) latency networks with a server that responds near instantly.

As far as flurry goes, I really liked my theory. It was elegant. Pity it turned out to be simple server lag, something that's very difficult to model programmatically.

I'm not saying it's definitely the case, just that it's my working theory for now. I like your solution a lot better too ;-) When I do the fast weapons test we'll have a much better reason to believe or throw out the server-lag explanation.

• Vulajin · 06/12/07, 8:30 PM

Quick summary of the "facts" as I see them...hopefully this will help:

My understanding of the auto-attack system is that the game maintains a swing timer which simply contains the time remaining to your next attack (if you have two weapons, it keeps two swing timers). When one of your swing timers reaches 0, you can swing with that weapon, and will do so the next time you are within melee range of your target and have your auto-attack turned on. When you swing, your swing timer is reset to the swing delay of that weapon at the moment of your swing.

There are two situations for haste effects. One is parry-haste. This effect can definitely be applied mid-swing. You can easily see this by equipping a nice slow two-hander and fighting something from in front of it. When you parry an attack, your next swing will occur noticeably faster. The second situation is haste rating/other haste effects. These do not apply mid-swing. You can see this as a rogue by equipping a single slow main-hand weapon and popping Slice and Dice partway through a swing. Your ongoing swing will still take the normal amount of time, but the swing after that will be hasted.

----

Now, here's how I think Flurry works with one weapon. You crit, and gain a Flurry buff with 3 charges. The buff provides 30% haste while active. The buff applies immediately, so your swing timer is reset to the 30%-hasted value.

You then swing with haste (count: 1). Your hasted swing eats up a Flurry charge (remaining: 2). The Flurry buff is still up, so your swing timer is reset to the 30%-hasted value.

You swing with haste again (count: 2). Your hasted swing eats up another Flurry charge (remaining: 1). The Flurry buff is still up, so your swing timer is reset to the 30%-hasted value.

You finally swing with haste again (count: 3). You eat up the last Flurry charge, and the buff wears off. Since the buff is gone, your swing timer is reset to the normal value. One Flurry proc, 3 hasted swings.

----

Now, as for Flurry with two weapons. Let's say, for the sake of argument, that you start with a crit from your main hand. You gain the Flurry buff (remaining: 3), and your next main hand swing gets the 30%-hasted timer.

Now, your ongoing offhand swing lands without haste (count: 0). It eats a Flurry charge (remaining: 2) and gets the 30%-hasted timer.

Now, your hasted main hand swing lands (count: 1). It eats another Flurry charge (remaining: 1) and gets the 30%-hasted timer.

Your hasted offhand swing lands (count: 2). It eats your last Flurry charge and gets the normal timer.

Finally, your hasted main hand swing lands (count: 3). Flurry's already gone, so it gets the normal timer. One Flurry proc, three hasted swings.

Even in unusual situations, for example where your main hand attacks twice at the start of the Flurry, it should still provide three hasted swings. Let's say your main hand crits. You get the Flurry buff (remaining: 3) and your main hand gets the hasted timer.

Now your main hand's hasted attack lands (count: 1) and eats a Flurry charge (remaining: 2). It gets the hasted timer.

Your offhand's attack lands without haste (count: 1). It eats a Flurry charge (remaining: 1) and gets the hasted timer.

Your main hand's second hasted attack lands (count: 2). It eats the last Flurry charge and gets the regular timer.

Your offhand's hasted attack lands (count: 3). One proc, three hasted swings.

----

In conclusion: the charge behavior of Flurry should guarantee that no more than three swings [which wouldn't have already been hasted] get hasted, regardless of how many times you crit while already having Flurry up. It should be independent of how many weapons you have equipped, as well. During my time playing a dual wield enhancement shaman, I observed the behavior of Flurry in-game to be consistent with my above model. It is likely that the unusual behavior experienced by Disquette is a result of lag.

• Disquette · 06/12/07, 8:36 PM

That's a good piece of insight on slice and dice as a testing mechanism for verifying that flurry wouldn't haste an attack mid swing. I also agree with you on the single wielding weapon situation.

For the dual wield, however, how would you reconcile what you wrote with the chart shown here: http://elitistjerks.com/attachment.p...5&d=1181629064

Note that the MH is a 2.6 weapon (hasted = 2.0 speed), and the OH is a 2.8 weapon (haste = 2.15 speed).

• Vulajin · 06/12/07, 8:50 PM

Hate to ask, but were there any parries in there? ;-)

Seriously though, I wouldn't reconcile it with what I wrote. It's very curious. One Flurry proc, five hasted attacks. It's consistent with Flurry not affecting ongoing swings from the other hand when it procs, but it's not consistent with...well, just about anything else. Do you have any other instances of that happening?