How come demon warlock favor mastery so hard in the BIS section when it comes to m+
it is the highest stat priority even over crit. and haste being left at only 8%
when it comes to all other sites recommendations its always listed as a 3rd priority
It’s hard to tell without trying your specific case. Press the green “help” link next to the big Best in Bags section header, and copy the generated 32-digit code here. With that we can try your exact setup, settings, talents, etc. and look into it further.
bf6db005699248c28bbad413ca1079a3
In the stat display, you are seeing the final percentage you get from what you have on gear. If you mouse over the stat numbers, you will see the rating you have on your gear. In this case the breakdown is:
crit: 1259
haste: 254
mastery: 672
vers: 377
So, we are definitely favoring crit as the top stat, which I think is in line with most other sources of information out there. The difference is that we don’t place as much value on haste.
This is almost entirely a function of the default fight length for the simulation. We use 270 seconds as our default fight length. Simc uses 300 seconds. If you go to customize and change the fight length to 300 seconds, you will get a result with more haste than mastery. If you extend the fight length out to 500 or 600 seconds, you’ll get an even more “average” result. It appears our simulator is finding that this 270 sec fight length lands in some sort of particularly bad duration for demonology where the haste on gear gets less value.
We have some code we wrote to make the simulation less sensitive to particular fight lengths. We use this for specs with high burst damage windows to avoid jumpy results. It appears we need to apply this code to demonology as well to get a less jumpy result. You see this because there are multiple long-ish cooldowns like demonic tryant, grimoire pets, and doomguard. If the simulation ends right before you use those again, you can get different results than if it ends right after they do all their damage.
This is a difficult nuance of simulation to deal with. IF you are doing exactly 270, 330 second fights, you’d probably want to use the results from our defaults as-is, crit > mast > haste. If your fights are ending at totally random lengths, you might want a more “average” result which would be crit > haste > mastery. If your fights always end “on the minute” like 300, 360, you would want a lot more haste, something like crit = haste > mastery.
I will endeavor to make this fight length smoothing configurable in the settings.
Try it now. I put in our code which effectively “randomizes” when the fight will end. These changes in haste were primarily tied to the apex talents. Those demons do a lot of damage and suffer from haste plateaus both in how many you can summon and how many spells each will cast in their duration. This can lead to “noisy” results in simulation around fight length.
We smoothed this out by tracking the damage while tyrant/dominion demons are up during the simulation and the damage while they are not up. Then, we can extrapolate an “average” result that does not favor ending a fight exactly on a peak or exactly between peaks.
**be7b503ef53c4b60bfc2e709fe08372f
**
while i guess with the changes you get more haste, its still 446 from gear. on top the it seems to like to throw in random vers items such as gems.
this is with a 300 sec sim timer over the usual 270
Try this again now since we updated the site today - make sure to reload the page before you optimize. You may need to change something to get it to un-cache the result. You don’t need to worry about the fight length, I was able to smooth all of that out as well.
1 Like
**682a804e695846cf8debe6fb10e600a7
**
tried again, cleared cache, everything set to default, haste is now back down to 254
Weird. Mine is haste (30%), crit (26%), mastery (20%) for BIS stats on my demo warlock
We just posted an update with some tweaks and hotfix data. I think that it should resolve any issues with this, for real this time!
Yes, sorry, there was a very specific timing bug in the simulator for the diabolist tree, which I was able to locate and fix using this snapshot.