That's really weird, in this post by Mavanas, according to his researches, nHAT is doing less damage than vHAT.
Any idea why?
I'm afraid I had a hard time parsing his post....... but I believe that the 23/5/43 .simcraft file uses a different priority scheme. In our setup, envenom is only used to maintain the buff...... and only executed with 5CP.
We don't have any Envenom-spam setups....... both HAT profiles make use of Evis.
Does it seem odd to anyone for mutilate to still out DPS the combat build? Blizz spent all this time on changing the Combat Spec and yet mutilate still out DPSs Combat by almost 400 dps. I know that all this is in theory but just wanted to throw it out there as everyone have been raving about combat being number 1 on the charts again. Basically I was wondering if there is something that other people are not catching that is inherent in the sims.
Does it seem odd to anyone for mutilate to still out DPS the combat build? Blizz spent all this time on changing the Combat Spec and yet mutilate still out DPSs Combat by almost 400 dps. I know that all this is in theory but just wanted to throw it out there as everyone have been raving about combat being number 1 on the charts again. Basically I was wondering if there is something that other people are not catching that is inherent in the sims.
Both this model and the spreadsheets are just approximations based on ideal circumstances. That makes them good for evaluating builds and the relative value of talents... to a point. You have to remember that circumstances are never ideal. Generally speaking Combat does better on fights with adds, down-time, target switching, etc than Mutilate. Combat also has several cooldown abilities that are often pivotal during certain points in encounters. That theoretical 400 DPS difference can be nullified by any of that.
And that's just with current BiS. Until things are on farm, you won't have BiS and your own highest DPS build may not be the same as the theoretical model.
Good points Tin, I guess I'm just a little surprised at the results...meaning I expected Combat to be ahead of mutilate even if it wasn't by much, but to have it be the other way around is curious as Mutilate did not really get any sort of real help besides the Glyphs and the change in HFB itself and master poisoner. Combat received a whole slew of changes, LR being the most noticeable one. Was combat that far behind that it couldn't catch up to mutilate in 3.1?
Also has anyone tried to put some of these theories in practice on the PTR? I know gear wise its hard to match exactly what is on the Sims but just curious as to how the real thing shakes out. I've ran some prelim tests and it favors combat. anyone else?
Well, you can't relly look at the SampleOutput and say Mutialte is still better. The sample output results are actully a best case for mutialte and kinda worst case for combat.
1. The fight length is 5 minutes.
2. The target is murderable.
Remove #2 (by adding target_race=undead) and combat already surpasses *new* mutilate. Fiddle with #1 and the gap will be even more.
Also, about some assumptions. While looking at the overall charts (comparing rogues with other classes) keep in mind that rogues are trading Tricks with each other. And even when you run only 1 rogue profile it's still assumed that this said rogue trades Tricks with some other rogue. If you want to stop that (like I do for myself as I'm the only rogue in the raid) you have to remove tricks from the action queue.
I got a couple of questions:
In the current live build the best Mutilate spec is this with Webbed Death/Webbed Death, IP/IP, SnD/Rupture/Evisc glyphs and using Eviscerate instead of Envenom (if the target is not poisoned by other classes, applying Wound Poison still outdps's the regular WB/SR, envenom spec) according to all the spreadsheets. Have you tried comparing that spec to the spec in your config on PTR or did Envenom become that much better in 3.1?
I also noticed that your Mutilate PTR config you only use 2 glyphs (Rupture and Slice and Dice), but I could imagine Glyphs of Hunger for Blood/Mutilate would increase your dps :P
I also noticed that your Mutilate PTR config you only use 2 glyphs (Rupture and Slice and Dice), but I could imagine Glyphs of Hunger for Blood/Mutilate would increase your dps :P
You did notice that there are T7 (3.0.9) and T8 (3.1.0) profiles? ;>
Hello.
Light the fuse.
For all my homies.
Do not run, we are your friends.
SimulationCraft Druid Guy
Your first and third specs are the same, I assume one of them was supposed to be MP. Regarding the one in the report using Quick Recovery, that talent is an inverse-benefit talent, i.e. the better your gear gets (and therefore the closer to expertise cap you get) the less DPS those talent points are worth. Since expertise capping is relatively easy to obtain (and expertise is the premier EP stat to gem for as mutilate), I would consider the build with improved eviscerate to be optimal.
Yeah, I've editted my post and it's got the right links now, but my question wasn't about Quick Recovery talent, I just put two points into it if the target is non-Murderable, my question is:
WD/WD, IP/IP, Eviscerate build vs WD/SR, IP/DP Envenom build with Master Poisoner (provided that there is an elemental shaman putting totem of wrath) vs WD/SR, IP/DP Envenom build with Turn the Tables.
Last edited by MentalPROblem : 03/25/09 at 6:39 PM.
I just noticed a bug in the implementation of the new 3.1 PPM poison increase from the envenom buff. I was comparing the output of equivalent rogue specs between T7 and T8, and noticed that the IP was applying far more often in the 3.1 model than 3.0.9.
The PPM is being multiplied by the envenom modifier of +75%, instead of adding it. This results in IP having a 52.5% chance per hit for a 1.4 speed weapon instead of the correct 45% chance.
I just noticed a bug in the implementation of the new 3.1 PPM poison increase from the envenom buff. I was comparing the output of equivalent rogue specs between T7 and T8, and noticed that the IP was applying far more often in the 3.1 model than 3.0.9.
The PPM is being multiplied by the envenom modifier of +75%, instead of adding it. This results in IP having a 52.5% chance per hit for a 1.4 speed weapon instead of the correct 45% chance.
Thanks for the catch. This is fixed in version r1976. I'll put out another release later tonight.
EDIT: New binary available for download. SampleOutput and SampleOutputPTR wiki pages have been updated.
Last edited by dedmonwakeen : 03/28/09 at 10:19 PM.
I guess this concerns scaling factors and hard caps in general, but I'm using expertise rating as an example here.
I'm not sure that I interpreted the code correctly, but I think that the scaling factor for expertise rating is calculated in the following way:
scaling_factor_for_expertise_rating = (dps(exp_p) - dps(exp_x))/(exp_p - exp_x)
where:
exp_p denotes the actual expertise rating listed in the config file.
exp_x is some other value, with exp_x < exp_p.
dps(y) is the dps from a simulation using y expertise rating.
I think that the scaling factors are also normalized as a group in some way, but that doesn't really matter here.
My point is that exp_x should be close enough to exp_p, so that when exp_p is clearly over the expertise rating cap, the scaling factor for expertise rating ends up being ~0. Right now this isn't the case, which leads me to believe that currently, exp_x is a very low number (I'm not sure what the current implementation actually uses as value for exp_x, maybe zero).
While that isn't wrong in general, it can give some confusing results. For example, when going from 217 to 317 expertise rating, simulations show that the DPS gain is 0, but the expertise rating scaling factor is still far from zero (~0.76 at 317 expertise rating). In other words, the effect of the expertise rating cap is currently not accurately represented in the expertise rating scaling factor.
To fix this, I think exp_x should be chosen close enough to exp_p (within 5-10 rating?). That way, not only will the effect of the expertise rating cap be more accurately represented, but also the calculated scaling factor would become more useful as a whole, since it would better represent the actual effect that adding/removing expertise rating has, assuming a certain amount of expertise rating from gear.
To fix this, I think exp_x should be chosen close enough to exp_p (within 5-10 rating?). That way, not only will the effect of the expertise rating cap be more accurately represented, but also the calculated scaling factor would become more useful as a whole, since it would better represent the actual effect that adding/removing expertise rating has, assuming a certain amount of expertise rating from gear.
Unfortunately, you run into the #1 drawback of using RNG simulation: Variance
Run the sim once, and it will give you a "right" result.
Run the sim again, and it will give you a different "right" result.
The smaller the delta, the larger the number of iterations....... To use a rating delta of 5-10 rating, it would require an immense amount of cpu-time before the variance in results drops below the benefit/loss of such a small delta.
This is one of the strongest reasons for using formulation to determine weights for various stats.
SimulationCraft now uses a 2-roll system for all special attacks.
While performing this conversion, I noticed that the HAT watcher was triggering off of "may_glance" to determine if an attack was from a "special". The problem with this is that Hunter ranged auto-shot has may_glance=false....... which resulted in too many HAT procs in the Raid_T7 and Raid_T8 configs in which there are two hunters in the party with the HAT Rogues.
To atone for my mistake, here is some analysis that I have done.....
I became curious about the effectiveness of each class in "donating" CPs to HAT Rogues so I added a "honor_among_thieves_donor" proc. Classes with pets have both player and pet data rolled into the owner's report.
I created a party including everyone in the Raid, filtered out the "honor_among_thieves_donor" proc, and then sorted them by frequency. The data in the following list is the number of procs over the course of the fight and the average time between procs. (Both numbers are themselves averages of many simulation iterations.)
Note that in order to properly calculate this, I needed to make sure there was only one HAT Rogue in the raid, and his "donor" rate was ignored. The values for the two HAT Rogues were taken from a generic Raid_T8 profile so they would not be skewed by the massive influx of HAT procs given the 30-player party.
For reference, the T8 raid profile uses the following party setups for the HAT Rogues:
# Since honor_among_thieves_interval=0 the HAT Rogues must be in a party
party=Rogue_T8_08_20_43/Hunter_T8_06_14_51/Hunter_T8_15_51_05/Mage_T8_57_03_11/Mage_T8_18_00_53
party=Rogue_T8_23_05_43/Hunter_T8_53_13_05/Warlock_T8_00_40_31/Mage_T8_53_18_00/Shaman_T8_57_14_00
SimulationCraft now uses a 2-roll system for all special attacks.
While performing this conversion, I noticed that the HAT watcher was triggering off of "may_glance" to determine if an attack was from a "special". The problem with this is that Hunter ranged auto-shot has may_glance=false....... which resulted in too many HAT procs in the Raid_T7 and Raid_T8 configs in which there are two hunters in the party with the HAT Rogues.
To atone for my mistake, here is some analysis that I have done.....
I became curious about the effectiveness of each class in "donating" CPs to HAT Rogues so I added a "honor_among_thieves_donor" proc. Classes with pets have both player and pet data rolled into the owner's report.
I created a party including everyone in the Raid, filtered out the "honor_among_thieves_donor" proc, and then sorted them by frequency. The data in the following list is the number of procs over the course of the fight and the average time between procs. (Both numbers are themselves averages of many simulation iterations.)
Note that in order to properly calculate this, I needed to make sure there was only one HAT Rogue in the raid, and his "donor" rate was ignored. The values for the two HAT Rogues were taken from a generic Raid_T8 profile so they would not be skewed by the massive influx of HAT procs given the 30-player party.
For reference, the T8 raid profile uses the following party setups for the HAT Rogues:
# Since honor_among_thieves_interval=0 the HAT Rogues must be in a party
party=Rogue_T8_08_20_43/Hunter_T8_06_14_51/Hunter_T8_15_51_05/Mage_T8_57_03_11/Mage_T8_18_00_53
party=Rogue_T8_23_05_43/Hunter_T8_53_13_05/Warlock_T8_00_40_31/Mage_T8_53_18_00/Shaman_T8_57_14_00
Most of these results line up with empirically tested rates posted in the HaT thread except for shadow priest. 0.27 crit per second is about twice the HaT rate of a shadow priest. Make sure mind flay crits do not contribute to HaT procs.
Most of these results line up with empirically tested rates posted in the HaT thread except for shadow priest. 0.27 crit per second is about twice the HaT rate of a shadow priest. Make sure mind flay crits do not contribute to HaT procs.
Ah, I didn't know that about Shadow Priests.
Mind Flay has much in common with Arcane Missiles. Can AM ticks proc HAT?
Note that Sample Output must be run separately to be updated. In this case, it hasn't been updated since 4/02 (Simcraft build 1998) and many changes have gone in since then (build 2052 is current).
Before you start to drift, and your soul begins to scream.
I just wanted to tell you, that you're listening to a dream.
03/18/09, 2:37 PM
Similar Threads
