On topic of BS hammers: from
[Warrior] DPS Spreadsheet 2.3 and beyond

|
Originally Posted by Shha
As for BS 1h hammers:
- They dont have hidden cooldown and i said in posts above. I did personally had countless occurances of the buff overlapping each other.
- Im currently running several hour long test in blasted lands:
Conditions:
- Mob attacked from the front - noone to tank it . My parry is at around 31%, something to take into account.
- Tanking gear (need to do something else lol).
- UM and combatlogging.
- No flurry or other haste procs.
- No instants - just autoattack.
So far the uptime for it oscilates around 21%, and has not changed for few hours. this suggests around 1.2 PPM with following problems:
Overlapping procs can lower a bit the result (although not much).
Parry speeds up weapon speed considerably. Out of every 10 swings 3 are hasted (if i recall the haste averages to making your weapon speed 0.4 of normal - im not 100% sure on parry mechanics, someone can probably correct me). If so the 10 swings take only 8.2 time of normal one, so we can say the proc shows 1.22 times more. Taking that into account, Id say the PPM is just 1.
Conclusion - current 16.6% uptime model in your spreadsheet is too low. How much its debatable. However even without haste effects uptime is at the 16.6%. That doesnt count instants, or haste effects.
Speculation. From my other tests, it seems that the proc follows rules of noncooldowned procs like executioner/mongoose aka:
- Extra procs from instants.
- Haste/Flurry doesnt affect proc rate - its calculated from base weapon speed.
- Proc can override itself.
Probably similiar modelling to mongoose/executioner can be applied, however the proc duration is 10 sec as opposed to 15, so the uptime will be lower.
Interesting values - according to combat log
Haste buffs =601
Executioner buffs = 463
That doesnt take into account refreshing buffs, so i think higher number for haste, is simply because executioner overwrites itself a lot more due to longer buff duration.
|
There's a lot of conditions there that seem funky. That and also the whole thing of measuring PPM of something that procs a good amount of haste throws the whole thing off too. I'm biased towards things being either 1.0 or 1.5 ppm, but I guess I can remove the hidden CD. That being said I will probably have to bump it down to 1.0 instead of 1.5 ppm after that to make the uptime at all reasonable.