[Enh] Windfury Weapon Cooldown - Page 5

Protico · 01/23/09, 2:18 PM

Originally Posted by Rounced

More then likely that Flametongue hit is actually due to a previous melee hit and not that hit. I'm guessing you are using WF/FT which would also prove that point since for a glancing hit to do 705 damage it has to be a mainhand hit not an offhand hit. For an offhand glancing (25% less damage) blow to hit for 705 damage, even with a 156dps 2.5 speed weapon, it would require 8344AP which seems a bit out of reach even with full raid buffs.

Here is a combat log entry from a patchwerk where the weapons happened to hit basically at the same moment (2.6 mainhand and 1.6 offhand) and the mainhand windfuried.

The Flametongue and the Windfury attacks arrive at the same moment even though the mainhand attack that procced the windfury hit 0.2seconds before the offhand attack.

I was looking at the Lightning Shield hit which ended my snippet, I and it agree with you.

Rouncer · 01/24/09, 11:59 AM

There was a strange comment from Ghostcrawler regarding Windfury Weapon and I was wondering what other people think he means.

World of Warcraft - English (NA) Forums -> Killing machine bugged (GC plz review)

We originally talked about letting the MH and OH both proc but at different rates (Windfury does something like this). Then we became convinced that dual wielding by DKs would probably sitll be good even without the OH procs from Killing Machine. Now it is just main hand procs at a frequency of 5 per minute.

I know my tests of the new Windfury glyph using just Lava Lashes (offhand attacks) gave results consistent with the expected but is there any way that Windfury Weapon is programmed to favor the mainhand even beyond the concept that it checks mainhand before offhand when weapons are synced or when Stormstriking? or could that be what he is talking about?

Pitbuller · 01/24/09, 12:12 PM

Maybe he's talking higher proc rate when using wf at both weapons.

Atren · 01/24/09, 12:30 PM

I noticed that weird wording too. It might be about dual WF, cooldown or combination of the two. I also thought maybe it was something their planning for future, but the wording indicates it is in effect now.

Protico · 01/24/09, 6:21 PM

Did anyone ask him for clarification? Sometimes that actually works with GC.

Saliik · 02/10/09, 4:20 PM

This is kinda 3 pages ago (and on top of that the thread's been dead for a few weeks), but when Wraithlin said something about the WF procs ranging from 0.5 to 1.1 seconds later than the generating swing, and talked about the normal distribution preventing a sharp drop-off at any speed, it got me thinking. (Post 34, Post 36). So I threw together a quick sim program to see the effects this latency would have if it effected weather the attack was in the CD.

It's very simplistic, I basically simulate auto-swings, WF procs, and WF CD; no miss, no crit, no flurry, no damage, etc. It generates an auto-swing every X seconds based on a specified weapon speed. On each auto-swing, it schedules a WF check for a random interval in the future (0 for no delay). At that point it checks if the WF CD is up, if it's not, it checks Rnd() < 0.2 to see if WF procs. If WF procs, it flags that WF CD is up and schedules an event 3 seconds later to drop the CD flag. Because of the nature of the queue I use for my events, collisions are handled in such a way, that whichever event was scheduled second, happens second, this is probably slightly different than wow, but shouldn't have a major effect. Eg. with no delay, a swing speed of 3.00 would land inside the WF CD, but 3.01 would not. While this distinction would be important in game, it doesn't affect the shape of the graphs very much.

I ran this for attack speeds from 0.30 to 3.20 (at a granularity of 0.01) for 300,000 seconds (83hrs) each, and kept track of the PPM of WF. Then I threw the data into Excel and generated a couple graphs. I took a fixed weapon DPS of 143.3 and multiplied it by each attack speed and then by 2 to get "WF Damage" (granted this ignores AP, but the damage shouldn't matter, as long as it's consistent). Then I multiplied that damage by the PPM and divided by 60 to get the "WF DPS." Note: This is not including any damage from white hits

Here's the graph with 0 delay in WF procs (like we see in typical simulators):

My code could be missing something big, but it seems that WF DPS is independent of weapon speed in each given range, but as you get to different factors of 3.0 (3.0, 1.5, 1.0, 0.75), you take a drop in WF damage. I'm sure flurry, heroism, moving out of range of WF, and any other effect that causes variable haste would smooth out the graph a bit favoring weapons more toward the slow end of each segment.

However, if WF can proc when the delay causes WF to land outside the CD, even though the white hit that generated it landed inside, the graph looks like this. I used a 0.5 to 1.1 range for the WF delay as that's what was observed in the prior post.

The DPS and PPM follow the same general shape as the other graph, but there's no hard drop off points. From about 1.7 to 1.3 speed WF DPS slowly drops off then levels out again, begins to drop off near 1.0, etc. This is basically just proof of concept of what Wrathlin said in Post 40, for those who had a hard time visualizing what he was talking about (like me).

The question is which case matches what is seen in game. Is the 3s CD from procing swing to procing swing, or from WF generation to WF generation. If it's the latter, then haste won't have a sharp drop off point, however, it will still be somewhat counter-productive in the ballpark of 1.5 (though probably still a DPS increase). The question of why the delay happens (server processing, client lag, intentional delay to prevent a haste chasm) is important to know if the delay actually exists in terms of WF CD calculation, or if it only shows up in combat logs. But beyond that, if it does show up in the CD calculation, does it behave like the simulator (top graph), or like Wrathlin describes in post 40 (bottom graph)?

Torodo · 02/11/09, 1:58 PM

FWIW, resurrected my old log proc analyzer and modified it for the "new" combat log format.

I could not see any meaningful WF procs closer than 2.9s apart over a sample of 205 procs.

Details:

1.6s OH weapon, empty MH, auto-attack on level 60 dummy with wf totem and popping in and out of combat to drink potions of speed. Was able to sustain swing rate of ~1s.

They theory behind this test is that if one wants to notice consecutive events that occur closer than 3s apart, then the triggering event must occur a lot faster than 3s apart to see any statistically meaningful information.

The log analyzer measures times between WF procs. It makes no attempt to latch onto the triggering swing because I believe the logs are unreliable when it comes to stamping events in the order and the time they are resolved on the server.

If latency is an issue with reporting WF procs, then by focusing on only the wf stamp times some average latency is subtracted out of the results. This would leave only the deviation in latency to affect results.

In Org, latency was pretty much rock solid at 350ms throughout the test. If your latency varies wildly, it is unlikely the logs will reveal anything useful in the time ranges we want to observe.

Here is a copy of the analyzer in case someone wants to run it with a bigger sample:

'*******************************
' wfproc: windfury proc analyzer
'
' by Torodo of Garrosh
'*******************************

'*** force explicit typing because my brain runs faster than my fingers
Option explicit	

'*** point to WoW log file
Const LOGNAME = "C:\World of Warcraft\Logs\WoWCombatLog.txt"
Const DATNAME = "wfproc.txt"

'*** minimum possible time between wf triggering events
Const DTMIN = 0.87 '*** wf totem + flurry + haste pot with a 1.6s weapon

'*** stores
Dim fso, logfile, datfile
Dim tLastWF, cntWF, f(1000)
Dim t, dt, dtAvg, s1, s2, tStamp, line, isWFProc
Dim i

'*** open the WoW log file for reading
Set fso = CreateObject("Scripting.FileSystemObject")
Set logfile = fso.OpenTextFile(LOGNAME)
Set datfile = fso.CreateTextFile(DATNAME, true)

tLastWF = -1.0

'*** initialize frequency table 0s to 100s in steps of 0.1s
For i = 0 To 1000
	f(1000) = 0
Next
cntWF = 0
dtAvg = 0.0

'*** procwess log file a line at a time
Do Until logfile.AtEndOfStream
	'*** fetch next combat line
	line = logfile.ReadLine()
	isWFProc = (InStr(line, "Windfury Attack") > 0)
	If isWFProc Then
		'*** get the time stamp
		s1 = Split(line, "  ")
		s2 = Split(s1(0), " ")
		tStamp = Split(s2(1), ":")

		'*** time of this proc in seconds
		t = 3600*cdbl(tStamp(0)) + 60*cdbl(tStamp(1)) + CDbl(tStamp(2))

		'*** first time through?
		If tLastWF < 0.0 Then
			tLastWF = t
			datfile.WriteLine "1:" & line

		'*** new proc?
		ElseIf tLastWF < t Then
			'*** compute elapsed time between procs
			dt = t - tLastWF

			'*** violates min triggering time?
			If dt < DTMIN Then
				'*** probably reporting lag for the two swings of the same wf event
				'*** throw into the first frequency bucket
				f(0) = f(0) + 1
				datfile.WriteLine "?:" & line
				datfile.WriteLine ""

			'*** decide which bucket to throw this proc into
			Else
				dtAvg = dtAvg + dt
				dt = CInt(10*dt)

				'*** bump frequency counter
				If dt < 1000 Then
					f(dt) = f(dt) + 1

				'*** anything more than 100s gets thrown in last bucket
				Else
					f(1000) = f(1000) + 1

				End If
				
				tLastWF = t
				cntWF = cntWF + 1
				datfile.WriteLine "1:" & line

			End If
			
		'*** ignore the second swing of a proc
		Else
			datfile.WriteLine "2:" & line
			datfile.WriteLine ""

		End If
	End if
Loop

'*** eject average time between wf procs
dtAvg = dtAvg / cntWF
datfile.WriteLine "Total WF Procs = " & cntWF + 1
datfile.WriteLine "Average time between procs = " & dtAvg & "s"
datfile.WriteLine "WF events under minimum possible triggering time of " & DTMIN & "s = " & f(0)
datfile.WriteLine "WF events over 100s = " & f(1000)

'*** eject the frequency table
For i = 1 To 999
	If f(i) > 0 Then
		datfile.WriteLine Right("          " & Round(i/10.0,1) & " " & f(i),10) & ":" & String(f(i), "X")
	End If
Next

logfile.close()
Set logfile = Nothing

datfile.close
Set datfile = nothing
Set fso = Nothing
MsgBox "Done"

• Disquette · 02/21/09, 5:51 PM

I seem to remember some sort of testing being done about windfury cooldown rates a while ago...

:p

Snarkiness aside, you don't have to unplug your internet connection to see that the combat log stamps are client side and that most of the calculations are server side.

If you do enough testing you can see this pretty easily just by alt tabbing out of wow, or have antivirus scans hit your hard drive in a hard burst, etc. In my testing I'd occasionally see multiple seconds of no combat data and could very confidently match those times to when my computer was doing other stuff.

Anyway, I haven't been following WoW mechanics very closely these days - is there any precedent for haste supposedly lowering the WFCD when Flurry wouldn't? This could very well be the case, like I said I haven't followed this for a year or more, but it would be nice to know how other classes' abilities do or don't affect the GCD, and see if that extrapolates nicely to WFCD.

It's not that I'm partial to my own testing (which was in a much earlier patch version of WoW), it's just that due to Occam's razoring and basic statistics, about the only thing that would convince me of haste affecting windfury cooldowns would be a graph showing a shifting distribution when comparing large amounts of item-borne haste to no haste.

As for 3 seconds vs 2.9 vs 3.1, etc... well, with the amount that network lag and computer lag affects the combat log, g'luck. I'm sure someone very clever with enough time could prove it one way or another.

The best way to do this would be to prove out dps on a target dummy with .1 speed increment weapons of the same dps/stats on a dummy just autoattacking with windfury. When you see the WF damage fall off, you then get a few other people to test as well (you have to do this to account for the remote possibility that some of this is client-side determined). If they get the same results as to where the fall off is, then we have an answer. If they get different results, then we can start looking for sims where we input our computer/connection's lag-coefficient :p

Janathema · 04/01/09, 6:47 AM

Originally Posted by Rounced

You can also just push past that haste cap and then it regains it's full value again. My real issue with updating the TTT is that the "haste cap" is such a narrow band and honestly I have never seen true proof that the WF cooldown is actually 3 seconds and not some value like 2.8 or 2.6 or 3.1 and I even recall someone running a long series on those immortal guys by the portal using a mod like procwatch that had the shortest time between windfuries as something like 2.79 or some other such value.

We know the cooldown is 3.0 seconds to the same degree that we knew that patchwerk's hateful strikes were purely based on health back in Vanilla. I could be wrong and would be happy to look over evidence to the contrary but I know I haven't seen it yet.

(e) Your post got me curious so I just went through my WWS parse for Sarth+3 10 man from the other day and I found this one.

16:35'36.750 Rouncer Windfury Attack hits Tenebron #9 for 1748 Physical.
16:35'36.750 Rouncer Windfury Attack hits Tenebron #9 for 3859 Physical. (Critical)
16:35'39.625 Rouncer Windfury Attack hits Tenebron #9 for 3314 Physical. (Critical)
16:35'39.625 Rouncer Windfury Attack hits Tenebron #9 for 1621 Physical.

Notice the timestamps. That's 2.875 seconds between Windfury attacks. I'm thinking we really do need more testing to determine the exact cooldown.

Maybe it's 2.875 seconds cause of the haste rating provided by your gear. Just was checkin your armory profile where you got 102 (3,11%) haste rating (I know you're wearing some PvP gear right now, but just take it as an example).

3,0s (supposed to be the wf cd) * 0,9689 (100% - your haste rating in percent) = 2,9067s

Rouncer · 04/01/09, 8:54 AM

Haste does not affect the Windfury Cooldown. The Windfury Cooldown apparently has a bit of a fudge factor built in most likely due to server processes that ends up making it function like 3 seconds +/- 0.3 seconds.

OnosKT · 04/01/09, 10:17 AM

As Rounced said, and as it has been determined in (I think) the 3.1 changes thread (I'll look for a link) haste has no effect on the WF CD.

Edit: Here are the links - posts 333 and 334 show that haste has 0 or negligible effect on the WF CD:

[Enhancement] 3.1 changes - new rules in place

Darknessss · 04/22/09, 10:12 AM

So considering all that has been said, which is the best choice between WF/FT with WT Glyph and FT/FT with FT Glyph?

OnosKT · 04/22/09, 10:22 AM

The answer is Sim it. Enh DPS has too many variables based on your gear/spec to be able to give a definitive answer.