Haters Gonna Haste

*Tap Tap* Is this thing still on?

I’ve been very busy lately between holidays, preparing for classes, and recovering from the plague. I’ve barely had time to play, let alone write blog posts. In fact, I really don’t have time to write this blog post, but it felt important enough that I made some time. But only enough for a quickie.

By now you’ve probably heard about today’s hotfixes, specifically the three affecting us the most:

Secondary Stats
  •  The Haste stat is now 11.1% more effective. For example, characters at level 100 now receive a 1% increase per 90 Haste (up from 1% per 100 Haste).

Paladin

The third change there is just a DPS nerf, which is probably warranted simply because Alabaster Shield was far and away the best DPS glyph we could use while tanking (Harsh Words is an even larger gain, but not really advisable while tanking anything relevant). Not much point discussing that change further.

The first two are big though. If you’ve been following this blog, you’ll recall what I said in November about why haste was underperforming:

I think the biggest reason haste is weak this expansion is entirely unrelated to class mechanics. It’s actually fairly simple: the rating conversion got nerfed, hard.

….

A simpler fix would be to modify that rating conversion for prot paladins, either directly in the game data or (more likely) indirectly by increasing the rating boost granted by Sacred Duty. If Sacred Duty suddenly increased haste from gear by 30% rather than 5%, haste would be back in business.

In later tests on Maintankadin (with a significant amount of assistance from Ashaton), we determined that even 30% wouldn’t quite be enough on its own. Sacred Duty would need to be around 40% to push haste ahead of mastery under all circumstances.

It seems like Blizzard agreed. Haste must have been underperforming for a lot of classes to warrant an 11.1% buff to the rating conversion. Combining that with a 30% Sacred Duty is effectively the same as a 44.44% Sacred Duty, more than enough to push haste up to be our most preferred stat. So our attunement finally matches the stat we want.

How to Homebrew A Sim

To illustrate that, I ran some sims for the six currently-viable talent combinations – any combination of Seraphim or Holy Shield with any of the level 75 talents. The first sim here is pre-hotfix. In the second sim, I applied a spell data override to artificially buff Sacred Duty to 44%. In case you’d like to know how to do this yourself, here’s a quick tutorial. First, here’s the spell_query entry for Sacred Duty:

Spell Query for Sacred Duty

Spell Query for Sacred Duty

This tells us that the 5% bonus to haste is stored in effect #1, which is effect id 233413. If we want to change that to 44%, we can override the base value using the code:

override.spell_data=effect.233413.base_value=44

This can be placed anywhere in the simc file or the text of the Simulate window.

Results

Here are the two reports:

Pre-Hotfix (Sacred Duty at 5%)
Post-Hotfix (Sacred Duty at 44%)

And here are the scale factors generated from each sim:

Scale Factors pre-hotfix.

Scale factors post-hotfix.

As you can see, haste performs much better post-hotfix than before, at least according to scale factors. That said, scale factors are notoriously unreliable because they rely on the assumption of local linearity, which isn’t often obeyed. For example, we’ve seen before that haste’s value can be all over the place with Seraphim because of odd breakpoint interactions. It’s far more reliable to look at scaling plots, which is why both of those sims contain said plots. Let’s look at those.

(As an aside, I have plans to implement a more robust scale factor algorithm in SimC some time soon-ish, but that takes time, which it’s clear by now I don’t have!)

From experience, we know that haste performs better in HS_DP than in HS_SW. In fact, HS_SW is generally the absolute worst case for haste, so let’s look at that first. Here’s what the scaling plot looks like for HS_SW before the hotfixes:

Scaling plot for Holy Shield + Sanctified Wrath, pre-hotfix.

To read this plot, you have to understand what the sim is doing. It’s running a bunch of simulations with +X of each stat and plotting the result. Thus, the line for bonus armor represents the result of a bunch of sims with -500, -450, -400, …, +400, +450, +500 bonus armor artificially applied. It plots the results of those sims as a continuous line. Since adding bonus armor reduces your TMI (making you more survivable), this line has a negative slope – in other words, it goes down from left to right. The steeper that slope, the better the stat is at reducing TMI and thus the better it is at helping you survive.

So in summary, the closer to horizontal the line is, the worse the stat is; conversely, the steeper the line is, the better the stat is.

It’s clear here that bonus armor has the steepest slope, which is why it generates really large (negative) scale factors. That’s why we covet bonus armor items so much. The yellow line for mastery is the next-steepest, and as we know by now mastery is our dominant stat when we’re using Holy Shield. The rest of the stats have slightly shallower slopes, and the absolute worst of them here is haste.

This is how we know haste is the worst, even if the scale factor calculations occasionally suggest otherwise. Local fluctuations can cause an anomalously high scale factor when you’re only looking at ranges of +/-175 stats, but if you generate a plot like this you’ll see the long-term behavior of each stat very clearly. Generally speaking, that long-term behavior is what you care about, because a variety of factors (variable latency, player reaction time, player error, having to break rotation to do other things, time off target, etc.) tend to smooth out the local fluctuations you see in simulations.

Now let’s look at that plot from the post-hotfix sim:

Scaling plot for Holy Shield + Sanctified Wrath, post-hotfix.

We actually see a local fluctuation in the haste curve immediately to the left of zero, which would lead you to believe that haste is still bad. But if you look at the whole plot, you can easily infer that’s not the case. Above zero, the slope of the plot is much steeper, second only to the bonus armor line. And if you keep looking farther in the negative, you see that the haste line gets steeper again. If we continued this plot for more negative values, we’d see the haste line catch back up to (and overtake) mastery.

And remember, this is the worst-case scenario for haste. HS+SW generates the weakest haste values. If we instead consider something like HS+HA:

Scaling plot for Holy Shield + Holy Avenger, post-hotfix.

The haste line is very clearly the second-steepest here, putting it solidly ahead of the other secondary stats (except bonus armor, of course).

The Seraphim plots are a little weirder thanks to a few factors. For example, if we look at Seraphim+HA, we get this plot:

Scaling plot for Seraphim + Holy Avenger, post-hotfix.

It looks like haste is great on one half of the plot and terrible on the other.  On the other hand, if we look at Seraphim+DP, we get a different story:

Scaling plot for Seraphim + Divine Purpose, post-hotfix.

Haste is pretty clearly ahead of the pack here. Again, I think this long-term behavior is what we care about with Seraphim simply because it fluctuates so much based on somewhat questionable breakpoints (i.e. how many GCDs or ticks of X or whatever else happens during the fixed 15-second Seraphim buff).

Stat Priority

In any event, this change pretty clearly accomplishes what it set out to do. Haste is going to jump from last-place into first-place amongst the non-bonus-armor secondary stats. For pretty much every talent selection, you’ll want to prioritize haste. What you go for after that will depend on your talents – with Holy Shield, you may favor mastery, with Seraphim you may favor critical strike. Though a haste/mastery focus won’t serve you poorly for any talent combination, so if you want to be able to swap back and forth between talents freely that may be the most versatile strategy.

DPS values may be worth considering as well. To give you some idea of how that works out, here are the DPS scale factors for HS+DP (the most popular spec) and Sera+HA (arguably the most common spec for mythic progression):

DPS scale factors for Holy Shield + Divine Purpose, post-hotfix.

DPS scale factors for Seraphim + Holy Avenger, post-hotfix.

As you can see, this change also vaults haste to the front of our DPS priority.

So my summary of stat valuation here is

Bonus Armor > Haste (to 50%) > Crit (Seraphim) >= Mastery > Crit = Vers > Multistrike > Haste (above 50%)

That “to 50%” is important now that we’re getting so much haste from Sacred Duty, so it’s worth considering that 50% haste cap in more detail.

The 50% Haste Cap

Because the GCD is capped at 1.00 seconds, there’s a limit to how much haste is useful. After we reach 50% haste, it stops reducing the GCD of abilities affected by Sanctity of Battle, though the cooldowns of those abilities are still reduced. However, the majority of haste’s value comes from that GCD reduction. This means we only want enough haste to get us up to 50%, because anything after that is better off as a different stat.

There are two raid buffs that increase our haste multiplicatively. The first is the 5% haste raid buff, and the second is Heroism/Bloodlust, which gives 30%. To figure out how much haste we want, we need to account for both Sacred Duty and those buffs.

If we have X haste rating on our gear, it will turn into 1.30*X haste rating on the character sheet. So for example, 1000 haste rating from gear (or from Seraphim) will show up as 1300 rating on the character sheet. We’d divide that by 90 to figure out how much percentage that gives us – in the case of Seraphim, it’s 1300/90, or 14.44% haste.

To figure out how much haste we have after raid buffs, we’d have to convert that to 1.1444 and multiply by the value of the raid buff, which is 1.05. So if we started with no haste on gear and just Seraphim active, we’d end up with 1.1444*1.05=1.2017, or 20.17% haste. If someone popped Bloodlust, it would take us to 1.1444*1.05*1.3=1.5621, or 56.21% haste, well over our cap.

For us, it’s more useful to work backward from 50% overall haste to figure out what rating we want to stop at. Since the bonus from Sacred Duty is included in the character-sheet values, I’ve given both “raw” and “character sheet” rating values on the table below.

Unbuffed Haste Rating Required to Hit 50%
Configuration Character Sheet Raw
No Buffs 4500 3462
Raid Buff (5%) 3858 2968
Emp. Seals (15%) 2740 2108
RB+Seraphim 2883 2218
RB+ES (20.75%) 2181 1678
Heroism Only (30%) 1385 1066
Hero+Seraphim 410 316
Hero+RB (36.5%) 891 685
Hero+ES (49.5%) 31 24
Hero+RB+Seraphim 0 0
Hero+RB+ES (57.0%) 0 0

Note that the Seraphim values on the table are just 975/750 less than the associated buff value. For example, if it takes 3858 character sheet haste rating to hit 50% with just the Raid Buff active, it takes 975 less (or 2883) to hit it while Seraphim is also up. So if you want to hit 50% during Seraphim in that case, you’d stack 2883 and be below the cap the rest of the time.

The raid buff is active in these sims, so we really only need 3858 haste rating on the character sheet to hit the cap. The profile only has 688 character-sheet haste, so we’re well below that. Even with Seraphim active, we have plenty of headroom for more haste. However, we’ll always be over the cap during Heroism, with or without Seraphim active.

What this table really tells us is that we should stop stacking haste when we hit 3858 character-sheet haste rating, or about 42.87%. That’s a pretty steep target, so it’s not clear we’ll be able to reach it even in Tier 18. We’ll have to see how much ilvl inflation takes place from T17 to T18 and beyond to see for sure.

This does, however, mean that you’d be well over the cap during Seraphim or Heroism. Note that TMI is fairly insensitive to that – your worst spikes tend to come when you don’t have either of those active, so it’s going to value haste highly if it’s helping you stay alive outside of those buffs. I think this is the more useful valuation of survival, though, because you don’t plan around the periods of the fight that can’t kill you.

That said, if it offends your sensibility to be “wasting” (and I use that term very loosely here) haste rating during Seraphim, the table tells you what targets to aim for. Between 2883 and 3858 rating, you’ll be “wasting” some of the haste rating granted by Seraphim, so you could stop at 2883 and start focusing on other stats.

Again, I don’t think we’ll get there any time soon, but worth throwing  out there, primarily for those that are considering ways to push their DPS higher. If you’re going over the cap during Seraphim, then that haste is wasted from the perspective of doing more damage.

Note, however, that the DPS scale factors provided earlier in this post automatically include the reduction inherent from heroism. In other words, haste is still our best DPS stat despite the fact that it provides almost zero extra DPS during heroism in this gear set.

TLDR Summary

1) Even a “quickie” Theck blog post is 2300 words.

2) Haste rules the roost. Stack it up to 50%, being aware of the haste-cap limits provided in the table earlier in the thread.

Happy hasting!

Posted in Tanking, Theck's Pounding Headaches, Theorycrafting, Uncategorized | Tagged , , , , , , , , , , , , , , | 58 Comments

The Trouble With Haste

Yesterday, we were informed of a few hotfixes that were being applied to protection paladins. From the hotfixes blog:

  • Protection
    • Mastery: Divine Bulwark now increases Shield of the Righteous’ damage reduction by 0.5% per point, down from 0.75% per point.
    • Grand Crusader now also has a 30% chance to trigger its effect from Crusader Strike and Hammer of the Righteous.
    • Shield of the Righteous now reduces physical damage taken by 25% (up from 20%).

As I tweeted at the time, these certainly appear to be targeted at “fixing” haste. The logic for why they appear to do that is pretty straightforward.

What Should’ve Happened

If you recall, Grand Crusader originally procced from successful Crusader Strike and Hammer of the Righteous hits. It was later changed to include avoidance (and later to proc only from avoidance) specifically to reduce haste’s value. So this seems like an obvious way to add value back into haste.

Likewise, one of the things we noticed in MoP was that haste got stronger as SotR mitigation increased. When SotR mitigates a large percentage of damage, it ends up being more important to increase the uptime than to further increase the mitigation, favoring haste. In fact, one of the targeted nerfs to haste in MoP patch 5.3.0 was to reduce SotR’s base mitigation from 30% to 25%, which was further nerfed to 20% during WoD beta. So this change makes sense as well – increase SotR’s base mitigation to make it more valuable by default, and reduce mastery’s value by reducing its contribution to SotR. Seems straightforward.

So of course, I expected that when I coded the changes into Simulationcraft (version 603-12) I’d be greeted with stat weights that told me haste was suddenly back in the limelight.

Unfortunately, that isn’t what happened.

What Really Happened

First, for a baseline, I ran a sim with version 603-11 to show how haste was really performing. Here is that simulation, along with the stat weight and scale factor plots it produced:

Pre-hotfix Results

Stat weights before the 11/26 hotfixes.

Scaling plot before the 11/26 hotfixes.

Scaling plot before the 11/26 hotfixes.

If you look at the html file, you’ll see that I’m using a fairly default configuration here. Sanctified Wrath, Light’s Hammer, and Holy Shield are chosen as talents, and the gear setup being used is heavily mastery-biased. That heavy mastery bias should help boost haste a little bit. As we can see on the plot though, haste and multistrike are both pretty weak, and performing below versatility, crit, and mastery, with bonus armor being far-and-away the best stat. Also note that since I’m running plots here, I’m only running for ~12k iterations, so the data is a little noisier than a full 25k iteration sim.

If we repeat this with version 630-12, which represents the post-hotfix mechanics, we instead get this:

Post-Hotfix Results

Stat weights after the 11/26 hotfixes.

Scale factors after the 11/26 hotfixes.

Scaling plot after the 11/26 hotfixes.

Scaling plot after the 11/26 hotfixes.

The first thing you’ll probably notice is that haste is solidly at the back of the pack now. In other words, these changes reduced haste’s value more than they increased it. So much for conventional wisdom! On the other hand, they did successfully weaken mastery – it dropped in value a bit, as evidenced by the lower scale factor and the shallower slope on the scaling plot. It’s still ahead of the other secondaries, but not by as much.

What Went Wrong

First, I obviously went back and double-checked that I had implemented everything properly. But I was disappointed to find that I hadn’t made any mistakes – Grand Crusader was now proccing from Crusader Strike and Hammer of the Righteous, and the mitigation value being calculated for Shield of the Righteous matched what it ought to be based on a hand-calculation. So we can eliminate “programmer error” as the cause of these seemingly-erroneous results.

So what did cause it?

Looking at our assumptions with the benefit of hindsight (and data), it’s clear we overlooked some things. For example, let’s consider the SotR changes. Lowering the mastery contribution certainly weakens mastery, there’s no question about that. At low levels, when you don’t have much mastery, the buff to the base mitigation value of SotR should be more than you lose from the mastery contribution, resulting in a stronger SotR and (in theory) a stronger value for haste. But at higher gear levels, it’s actually a net loss in SotR mitigation, which could cause haste to get even weaker.

To illustrate that, our T17H profile here has about 28% mastery.  That contributed 21% mitigation to SotR pre-hotfix for a total of 20% + 21% = 41%. But post-hotfix it only gives 14% mitigation, for a total of 25% + 14% = 39%. As you can see, this makes SotR a little weaker, which subsequently makes haste a little weaker.

Which raises the obvious question, “Exactly how much base mitigation must we add to SotR in order to make haste an attractive stat?” So I took my working copy of the code and tweaked the coefficients a bit to try and find out. Here’s what it looks like if you buff the base value to 30%, and keep the +0.5% per point of mastery:

Theoretical Results – 30%+0.5%

Scale factors with SotR base mitigation buffed to 30% (+0.5% per point of mastery).

Scale factors with SotR base mitigation buffed to 30% (+0.5% per point of mastery).

Still behind. Let’s try buffing it to 35% base:

Theoretical Results – 35%+0.5%

Scale factors with SotR base mitigation buffed to 30% (+0.5% per point of mastery).

Scale factors with SotR base mitigation buffed to 30% (+0.5% per point of mastery).

Nope. Not enough yet. Maybe…. 50%?

Theoretical Results – 50%+0.5%

Scale factors with SotR base mitigation buffed to 50% (+0.5% per point of mastery).

Scale factors with SotR base mitigation buffed to 50% (+0.5% per point of mastery).

Well, that helps… but it’s clearly not enough. 70%?

Theoretical Results – 70%+0.5%

Scale factors with SotR base mitigation buffed to 70% (+0.5% per point of mastery).

Scale factors with SotR base mitigation buffed to 70% (+0.5% per point of mastery).

Success! Well, sort of. Haste isn’t the dump stat anymore, but it’s only tied with crit and versatility and multistrike. To push it up a little further we’d need to do something else, or nerf the other stats somehow. Also note that we’re easily hitting the 80% cap on SotR mitigation here, so mastery’s not giving us any extra mitigation through that vector, meaning that this is its value just due to block and attack power.

What this tells us is that SotR mitigation is a really inefficient way to buff haste’s value. It’s taking extreme amounts of change to get any significant bump in haste’s value. We might be able to get to a good spot if we allowed SotR to mitigate 70%+ baseline and removed the mastery component entirely. You could imagine buffing mastery a bit to compensate by increasing its contribution to block chance. But we’re talking about a pretty extreme changes to how SotR works, which is not something to be done lightly.

I also ran one sim with a base mitigation of 25% and the original 1% per point of mastery, just to see how that changed things. Here’s what that looks like:

Theoretical Results – 25%+1%

Scale factors with SotR base mitigation buffed to 25% (+1% per point of mastery).

Scale factors with SotR base mitigation buffed to 25% (+1% per point of mastery).

Mastery gets inflated a lot in this, of course, but haste still doesn’t really recover. That tells us something else: it’s not just the SotR change keeping haste down. The Grand Crusader change is actually having a negative impact as well.

To figure out why, we just need to consider what adding Grand Crusader procs to Crusader Strike and Hammer of the Righteous accomplishes. No matter what gear you’re wearing, this means more holy power income, and subsequently, more SotR uptime. We assumed that this would logically make haste stronger, as we’re now amplifying our HP income more.

But while this change does make each point of haste give us more HP generation, it also increasing the natural uptime on SotR as well due to the extra Grand Crusader procs. In other words, we simultaneously made haste give us more HP generation per point and removed some of the reason we’d want that HP generation in the first place. As it turns out, the latter is the larger effect.

I should add that talents have some impact on this. Sanctified Wrath gives us extra holy power generation from Holy Wrath, which leaves less room in the rotation to make use of those Avenger’s Shield procs. Switching to Divine Purpose does inflate haste’s value a little more:

Post-Hotfix Results – DP talented

Scale factors after the 11/26 hotfixes, using Divine Purpose.

Scale factors after the 11/26 hotfixes, using Divine Purpose.

But it’s not enough to make it a viable competitor with crit or versatility, let alone mastery. Ironically enough, haste was better off before these hotfixes.

Why Is Haste So Bad?

At this point, it’s worth considering why haste is performing so poorly, especially given how well it performed in Mists. Based on these results, it’s clearly not just a simple issue with Shield of the Righteous or Grand Crusader. So where do we point the finger and place blame? The answer is that it’s complicated. It isn’t just one thing dragging haste down. It’s really a combination of several different effects.

First, there were some changes to the damage model. Mists gave us relatively hard-hitting bosses that could easily kill you in 3-4 seconds if your healer looked away. That has slowed somewhat with Warlords, with bosses being a little more deliberate. Whereas taking two back-to-back melees was a serious danger in Mists, it’s a little less fatal in Warlords, in part because of large increases in baseline effective health. As a result, there’s less emphasis on maximizing the uptime of SotR via haste (and the now-defunct hit and expertise) than there was in Mists.

Mechanics also shoulder some of the blame. Many of the changes to spells in Warlords ended up buffing other stats, either directly or indirectly, without appreciably affecting haste. It’s not hard to come up with some examples of this:

  • Improved Block makes mastery more valuable, but has almost no effect on other stats.
  • Similarly, Holy Shield buffs mastery, but nothing else (well, crit/ap/etc. for DPS obviously, but we’re just considering defensive value here).
  • Mastery now grants attack power – this is a huge change that significantly buffed mastery. It already gave us some solid survivability through more blocks and more Shield of the Righteous mitigation, but now we also get the value of a chunk of attack power with every point of mastery.
  • Sacred Shield can now crit and multistrike, and benefits from mastery indirectly through attack power. It had none of those synergies in Mists. In addition, with the absence of huge piles of attack power through Vengeance, the value it grants to haste has diminished. In short, in Mists it gave haste a lot of value and nothing to the other stats; in Warlords it now grants some moderate value to all of the stats.
  • Likewise, Seal of Insight now benefits from crit, multistrike, and mastery, unlike in Mists. As with Sacred Shield, this mechanic changed from being a primarily haste-focused effect to something that gives a little value to everything.

That’s a lot of buffing to other stats and a fair bit of nerfing to haste.

But that’s not the worst part, in my opinion. No, in fact, I think the biggest reason haste is weak this expansion is entirely unrelated to class mechanics. It’s actually fairly simple: the rating conversion got nerfed, hard.

Consider that in Mists, it took 425 haste rating to get 1% haste, while it took 600 mastery or crit rating to get 1% of either of those stats. Now, of course, we can’t directly equate 1% haste to 1% mastery and say they’re of equal value. But we can draw inferences from relative worth of 1% mastery and 1% mastery, even if we don’t know exactly what that ratio is.

So let’s assume you have 600 points of stat to allocate. In Mists, this gives us either 1.00% mastery or 1.41% haste. Even if 1% mastery is stronger than 1% haste, we get more haste to work with from that 600 points. In fact, as long as 1% haste is at least 71% as effective as 1% mastery is, the haste “wins” from the point of view of itemization (and thus scale factors).

So in short: because we get a lot more haste percentage than we do mastery percentage from equal amounts of rating, gearing for haste can outperform gearing for mastery, even if 1% mastery is more effective than 1% haste.

Now fast-forward to patch 6.0.2. The rating conversions got squished along with everything else. Haste now took 20 points of rating to produce 1% haste, while mastery took 23 points to produce 1% mastery. If we repeat our thought experiment with 23 rating, we get to choose between 1.00% mastery and 1.15% haste. Even in the absence of mechanics changes, that’s a big nerf to how effective haste can be. Numerically, it dropped to 1.15/1.41 = 0.816, or 81.6% of its pre-squish effectiveness. The rating conversion alone just knocked almost 20%  off of haste’s value.

Fast-forward to level 100, and the conversion gets even worse. It takes 100 points of haste rating and 110 points of mastery rating to produce 1% of each, respectively. So if we start with 110 points of rating to allocate, we can have either 1.00% mastery or 1.10% haste. Again, the margin just got slimmer, and haste just got weaker. All told, it’s now giving us 1.10/1.41 = 0.780, or 78% of the amount it did in patch 5.4.8. That’s a pretty substantial nerf to the raw power that haste can produce, and it has nothing to do with mechanics.

Just to see how important that is, let’s look back at the original scale factors we calculated pre-hotfix. The table below contains those scale factors, along with an “adjusted” scale factor for haste. To get that adjusted scale factor, I’ve multiplied it’s scale factor by 1/0.78 = 1.282 to represent the value it would have if the rating conversion (relative to mastery) had been similar to the one in Mists. Note how that changes the results:

Scale Factors
Stat Scale Factor (pre-hotfix)
Mastery 5.60
Haste (adjusted) 4.69
Versatility 4.16
Crit 3.98
Haste 3.66
Multistrike 3.28

That alone puts haste nearly at the top of the heap. The only thing that still beats it is mastery, which we can attribute to the smorgasbord of buffs it got through mechanics changes. Even without further changes, this would be a better state for haste, and we could start looking into ways to reduce mastery’s overly-high value to put it at it’s rightful(?) place atop our priority list.

But I think this nicely illustrates the point: fixing haste isn’t going to be easy. It’s being kept weak by a slew of changes, both mechanical and “numerical” (in the case of the rating conversion), that have just made all of the other stats better.

Where Do We Go From Here?

I’d be remiss if I didn’t give my own suggestions about how to help fix haste. Though, I’ll give them with an obvious disclaimer: both of these hotfixes were changes that I’ve suggested before as ways to improve haste, and we now see how well that turned out!

First, I think it’s clear that Shield of the Righteous isn’t the answer. Unless the devs are willing to fundamentally change how SotR works, it’s just not an effective way to boost haste relative to the other stats.

A fundamental change, like giving it a very large amount of mitigation with no mastery effect, might work at the expense of mastery. Another even more radical change would be to make haste increase its mitigation directly just like mastery does. For example, maybe it mitigates 20% + 0.5% per point of mastery + 0.5% per 1% haste (or more simply, 20% + half of your mastery percent + half of your haste percent).

Likewise, Grand Crusader might not be the right avenue. Maybe if the avoidance-proc portion was removed it would be less detrimental to haste (and would certainly reduce the value of crit and strength). But I’m not certain of that, and we’ve already seen I was horribly wrong about the CS proc portion of the ability.

Despite being a big portion of haste’s value in Mists, Seal of Insight isn’t a great candidate either. Buffing it would simultaneously buff haste, crit, mastery, and multistrike. However, as with SotR, you could imagine some more radical changes that would shift value out of crit, mastery, and multistrike and into haste. For example, if Seal of Insight healed for a fixed percentage of health rather than being based on attack power and spell power. That would make crit, mastery, multistrike, and versatility irrelevant and thus reduce their scale factors. If the fixed percentage of health was higher than the equivalent amount is right now (after accounting for Resolve), that could be a net gain for haste.

I think the smarter avenue at this point is to try and focus on things that affect only haste, or affect haste more directly than other stats. For example, we’ve already seen that a large part of haste’s value was lost to the rating conversion. A simpler fix would be to modify that rating conversion for prot paladins, either directly in the game data or (more likely) indirectly by increasing the rating boost granted by Sacred Duty. If Sacred Duty suddenly increased haste from gear by 30% rather than 5%, haste would be back in business.

Another route is Sanctity of Battle, since that’s where the bulk of haste’s defensive value comes from. Right now it reduces cooldowns by your haste percentage. If it reduced cooldowns by 1.3% for every 1% haste, that would give haste a large boost, much like a rating conversion change would.

You could imagine adding an entirely new effect. For example, something that procs off of melee hits could selectively add value to haste if done right. However, there are a few issues with this. First, it means designing (and re-balancing around) a new effect. The proc effect itself has to be very specific as well – it can’t benefit from mastery, crit, or multistrike, so it would have to be something like a fixed-percent heal or an armor (not bonus armor) buff. And at this point, we’ve basically come up with a slightly redesigned version of Seal of Insight, so the question becomes “is this significantly different enough to warrant making a separate effect?” Still, a random armor proc from melee hits can only help haste’s value, inelegant as it might be.

If we’re going for new effects, though, I think we’re more likely to get something useful if we think about it from a different perspective. Earlier, we discussed the slew of changes that made mastery so much stronger this expansion. Arguably the biggest factor is that it now grants attack power. In other words, we took a stat that was (relatively) weak and added value to it by piggybacking another stat onto it. Riposte does exactly the same thing for crit, in fact. It takes crit, which is weak for survivability on its own, and bolts on a bunch of value due to avoidance.

It isn’t hard to think up ways to do this for haste. The simplest example, perhaps, is to blatantly copy Riposte. Riposte gives you 1 parry rating for every point of crit rating (from gear, anyway, let’s ignore the current issue with buffs). The new “Divine Riposte” could give you 1 point of dodge rating for every point of haste rating. This should give haste extra value without tweaking much in the way of mechanics, and without significantly altering the value of other stats.

There are any number of ways to do this, in varying degrees from “ok I’ll buy that” to “completely breaks immersion.”  “Momentum – increases your armor (or bonus armor) by a percent equal to your haste” is on the more logical end. “Shake it Off – reduces the damage you take by half of your haste percentage” is a little less defensible (though obviously, quite effective!). If you want to go to the extreme end of the crazy train, you could tack haste’s effect on to Shining Protector (what sense does that even make?) or cause it to increase your stamina (because sprinting is exactly like long-distance running…).

In any event, my point is that I think the solution to our haste “problem” lies not in a raw mechanics change, but in a subtle, “tack some extra value on to haste” change.

Or Maybe….

Of course, we should also talk about the elephant in the room. Is the problem that haste is bad, or is the problem that our attunement says we should like haste? Maybe we’re looking at this in entirely the wrong way.

Why not change our attunement to mastery and be done with it? It’s clearly the dominant stat with the current mechanics. We’re going to extreme lengths here to try and shift value around to make haste better to match our attunement, potentially causing a lot of collateral damage in the process. It might just be easier to switch our attunement, not to mention less disruptive. Plus, many of us remember the days of Cataclysm when we loved mastery to death, so it’s not like we don’t have a precedent for being a mastery spec.

I think this highlights one of the problems of the attunement system, which is something I pointed out in several conversations during beta. The attunement system puts an additional (and in my opinion unnecessary) constraint on class design. You might have a great set of mechanics cooked up for a class, only to find that it shifts their stat priority and makes their attunement “wrong.”

This is problematic even for the simple case of a DPS class. I say “simple” because DPS is a fairly robust metric – easy to calculate, easy to test, and fairly reliable. But even within DPS, we find that the effects of crit, haste, and mastery (and other stats) are multiplicative. In other words, let’s say haste, mastery, and crit are perfectly balanced when you have 0% of each, such that each gives exactly the same amount of DPS. If you stack 20% haste (and no mastery or crit), you will find that mastery and crit are now stronger than haste, and this will be reflected in scale factors. Likewise, if you stacked 20% crit, mastery and haste would be the strong stats.

The details vary from class to class due to mechanics, but in the most basic model you would want an equal mix of haste, mastery, and crit (by percent, of course, not rating). This isn’t news to anybody who’s theorycrafted a DPS class. If you played Retribution in Mists at all, you may have heard the advice “stack haste to 40%, then crit/mastery” – this was the reason for that advice. Stack enough haste, and you make crit and mastery strong enough to overtake it.

Which means that no matter what, at some point your attunement “advice” is going to be wrong. Especially if you start with very close stat weights, which was the stated intent this expansion.

Now consider how much  harder your job gets as a designer if you want to do this for tank classes. First of all, how do you even decide which stat is strong? We looked only at TMI here, but we could have considered DTPS or DPS. Which is correct? Or do we look at a mix? If so, what mix?

Furthermore, TMI is a fairly arbitrary metric, all told. You could devise a different metric for measuring smoothness and get slightly different results. In fact, you see this if you change the window size on TMI; the default TMI with a 6-second window (aka TMI-6) may give you different results than a TMI-4 or TMI-8 measurement. Which is correct?

There’s no good answer to that question, which is one reason I was skeptical of the attunement system for tanks. If they had designed the class such that haste is our best DTPS stat but horrible for TMI, and TMI turned out to be the more relevant metric for tanking in the first tier, then the majority of the community would be ignoring that attunement anyway.

And then there’s the question of tank balance – will we keep up with other tanks if they’re getting 5% more of their favorite stat and we’re trying to get rid of as much of our attuned stat as possible? Of course, the other tanks  could have exactly the same problem….

I think what we have here is a prime example of where the attunement system goes wrong. Instead of just developing cool mechanics and letting the stats fall where they may, it’s acting as a constraint. Instead of just making sure that play is fluid and mechanics are solid, we’re tweaking things in an attempt to satisfy this “haste>all” edict. It’s worth pausing to reflect on whether this is a smart idea or not before proceeding with further changes.

This is one reason I wouldn’t mind a bit if the attunement system disappeared in the next context patch. I get the point – to guide newer or inexperienced players. But I think that it’s more likely to end up being a trap than a help. I’d rather see the system removed and a small bit of text added to the “Core Abilities” tab of the spellbook. Something like, “As a protection paladin, you benefit greatly from Strength, Stamina, and HasteMastery.” That way, it can be updated based on how the stats shake out rather than acting as a constraint on design.

Disclaimers

As usual, there are limitations. I’ve only simmed a small subset of the possibilities, particularly choice of talents (Holy Shield, Sanctified Wrath) and gear (mastery-heavy). It’s always possible (if unlikely) that in a different gear set or talent configuration, haste gained some ground. I’d love to be able to sim a larger swath of configurations, but there’s only so much CPU time available, and it’s the night before Thanksgiving, and I’d rather be playing the expansion than simming it at the moment.

It’s also possible that I’ve missed something, which is why I try to provide as much of the data as I can. If you see an egregious error or something that looks fishy, please don’t hesitate to write a comment and ask about it. The goal of this blog was never “Theck tells you how it is and shouldn’t be questioned.” It has always been an independent place for me to host my work so that it can be subject to peer review and community discussion.

Posted in Simcraft, Simulation, Tanking, Theck's Pounding Headaches, Theorycrafting, Uncategorized | Tagged , , , , , , , , , , , , , , , , | 61 Comments

Paladinning in Warlords of Draenor

Once again, we’re on the eve of a new expansion. Tonight, many of you will be logging in and starting the grind from 90 to 100. For the first time in a long time, many of you will actually be doing it in protection spec. But regardless of how you get there, at some point you’ll hit level 100 and want to know how to optimize yourself for raids.

When patch 6.0 dropped on live servers, I posted a Survival Guide focused on what has changed at level 90. This post is the complement to that, containing details on how things change at level 100. Some things are obviously the same, like the stat squish and changes to abilities, so I won’t be going over them again. I’m only going to talk about things that I either haven’t covered in that post, or have changed significantly from level 90 to 100.

Level 100 Talents

You may recall that I made a qualitative post about our level 100 talents a little more than a month ago. Now let’s look at them qualitatively. Below are the results of a multi-actor simulation containing a bunch of paladins with slightly different L75 and L100 talents. The specs should be easily inferred from the names, but there are a few minor tweaks I should explain.

Empowered Seals gives you a fairly wide range of options. For example, you can sit in Seal of Insight for maximum survivability, or you can ignore Insight and twist Truth and Righteousness for maximum DPS. Twisting all three seals gives you a middle-of-the-road option, which is what the default APL is set up to do. So to give a proper representation of Empowered Seals, I’ve added “_DPS” and “_SUR” actors. The “_DPS” actor twists Truth and Righteousness to maximize DPS, and the “_SUR” actor just sits in Seal of Insight to get maximum survivability.

However, that’s also not terribly fair to Seraphim and Holy Shield. After all, you could swap to Seal of Truth while using either of those talents for a significant DPS boost. So to show that, I’ve added two “_SoT” actors which use Seal of Truth, but are otherwise identical to their companion actor (e.g. SS_SW_Sera_SoT is identical SS_SW_Sera except for using Seal of Truth).

With that out of the way, let’s look at the data.

DPS rankings for different L100 talents.

DPS rankings for different L100 talents.

TMI rankings for L100 talents.

TMI rankings for L100 talents.

Holy Shield performs pretty well in these sims. It gives the best baseline survivability of the three by a slim margin. “Survival mode” Empowered Seals can match it, but at a hefty cost of around 3000 DPS. That said, it lags in single-target damage a bit compared to either of the other two options. It will lag even further if you spend time not actively tanking things.

Seraphim performs very well. With Seal of Insight, it produces higher DPS than the other talents (including the default Empowered Seals APL) at a small TMI cost (around 3k). With Seal of Truth active, it’s the flat-out highest DPS talent available. And the on/off nature of the buff can make it strong for tank swaps, provided the timing is right.

I think the balancing of these two talents is pretty solid. Neither is head and shoulders above the other, and both perform close enough to one another that they’re both perfectly viable. Seraphim gives you a little DPS edge when played perfectly, and gives you more control over when you get that DPS, but takes more concentration and makes you a little squishier while the Seraphim buff isn’t active.

Empowered Seals though… well, in short it just doesn’t keep up. It’s versatile, but that versatility doesn’t seem to pay major dividends. You can sit in “survival mode” at a large DPS cost, but your survival is no better than if you took Holy Shield. Likewise, you can sit in “DPS mode,” but you’re actually about 1k DPS behind using Seal of Truth with Seraphim.

The benefit is supposedly that you can do this all within a single encounter, without changing specs. But I think you’re probably actually better off with Holy Shield in that situation. Switching to “survival mode” costs you a large chunk of DPS compared to either of the other talents, but while in “dps mode” you’re only about 1000 DPS ahead of Holy Shield with Seal of Truth active. Unless you spend about 2/3 of the fight in “dps mode” and only 1/3 in “survival mode,” you’ll actually produce more DPS and have better survivability by just taking Holy Shield and swapping from Seal of Insight to Seal of Truth based on what you care about at the moment.

In other words… Holy Shield does seal twisting better than the “seal twisting” talent does.

The other thing I should mention is how each talent performs in AoE situations. In short, Holy Shield excels here as well. With as few as two targets, it’s nearly caught up with Seraphim in DPS and out-performs everything else for survivability. For three or more targets, it just plain dominates in both DPS and TMI. I won’t belabor that point with loads of plots, but if you’re curious here are some sims with two, three, and four targets so you can see for yourself:

2 Targets 3 Targets 4 Targets

So, with that said, my advice regarding level 100 talents is:

Take Holy Shield or Seraphim.

Holy Shield will be a solid choice on most encounters, especially cases where you have to tank multiple targets at once, and has the benefit of taking literally no attention away from the encounter. This makes it a perfect choice for learning a new boss fight, since you can pay more attention to the encounter mechanics that you need to learn rather than micromanaging your rotation.

Once you have the mechanics down, you may decide to shift gears to take Seraphim if the encounter suits it. It gives you better burst DPS, and more control over the timing of that DPS. Be aware, however, that the longer you delay Seraphim, the less effective it is. The DPS gains may disappear if you’re not casting it at regular 15-second intervals, so this talent is much more susceptible to sloppy play or mismanaged timings.

Also remember that you’re most vulnerable in the ~5 seconds before you re-apply Seraphim, because you need to be pooling Holy Power during that period to recast it. This is a good time to use Divine Protection, especially with Unbreakable Spirit talented. Another trick you can use is to sit on a Divine Purpose proc and consume it during that 5-second window, since you can’t use it for Seraphim anyway.

If you really enjoy seal twisting, it doesn’t hurt much to take Empowered Seals. It just isn’t really overly strong in any particular category, and it’s hard to justify the extra attention required to maintain multiple seal buffs. I could see this talent being more effective if we had a much emptier rotation, like some of the other tank classes now have. But without culling some of our rotational spells, that just isn’t going to happen.

You’ll note that I only used Sacred Shield in these sims. You can see the version with Selfless Healer and Eternal Flame included here. It doesn’t really add anything though – EF and SH are uniformly worse for TMI, and the small DPS gains that you achieve by not spending GCDs refreshing Sacred Shield aren’t really worth it.

Stat Priorities

One of the big changes is in our stat priorities. If you recall from the Survival Guide, at level 90 mastery was king, with bonus armor right behind it, and then versatility, haste, and critical strike rating trailing a little behind. The gap between the stats was not that large though, and even the lowest stat (crit) was still 2/3 the value of mastery.

All of that changes at level 100 though. Ten levels and a bunch of gear upgrades make a pretty big difference, but there are plenty of other factors that affect the stat weights as well. For example, at level 90 it took 20 haste rating to increase your haste by 1%, compared to 23 rating for crit or mastery. At level 100, it’s now 100 haste rating vs. 110 crit or mastery rating, which should weaken haste relative to the other two stats.

Level 100 talents can also have a fairly significant effect. Holy Shield favors mastery slightly because you’re blocking spells now, and the reactive damage adds to mastery’s DPS contribution. Seraphim and Empowered Seals will likewise favor certain stats more than others.

Finally, the gear set we use can make a difference. The T17H profiles, which use Holy Shield, have been optimized around that choice and heavily favor mastery. So to start with, let’s look at that situation. Below are scale factors calculated using the T17H profile against a T17M TMI boss:

TMI scale factors for the T17H profile.

TMI scale factors for the T17H profile.

Let’s analyze these results in a little more detail.

      • Bonus Armor is head and shoulders above everything else in this sim. It’s just flat-out awesome, giving solid effective health against physical attacks and increased healing by increasing your attack power.
      • Stamina and Strength are also strong. Stamina’s value is obviously dependent on how much you have and how willing you are to trade survivability for DPS, so YMMV there. Strength performs well thanks to granting a combination of AP and parry.
      • Mastery commands a solid lead over the remaining secondary stats. Unlike at level 90, where it had several stats nipping at its heels, the next closest secondary stat is nearly a full 30% weaker. That said, this sim is using Holy Shield, which makes mastery a little stronger than usual.
      • Crit and Versatility are roughly tied for the next place. The order in which these two show up depends a lot on the specifics of your gear, though I think that versatility tends to be a little stronger overall. This is one of those things you’ll just have to sim for yourself if you want more accuracy for your own character.
      • Multistrike and Haste bring up the rear, with multistrike generally leading haste. Also note that this is a solo sim, so the effect of Shining Protector is underrepresented compared to a real situation. How much is one of those subjective questions that is hard to answer.

In summary, at level 100 the stat priority for survival seems to be

Bonus Armor > STR > Mastery > Versatility / Crit > Multistrike > Haste

I’ve left off armor and stamina since they’re not something we can actively choose in most cases, but the numerical values are there in case you want them.

In addition, note that the gear set I’m using here is already heavily biased towards mastery. In other words, even in a high-mastery gear set, stacking mastery instead of other secondary stats is a solid bet for survivability. At level 90, haste had finally managed to catch up to mastery once you stacked 55%-60% of it. It’s possible we will once we have T18+ gear and higher mastery percentages, but we’re not there yet in T17.

This is only half of the story though. Those are stat weights for TMI, but we also produce respectable DPS now, so in Warlords raids we may very well care about how each stat affects DPS. Those stat weights are below:

DPS scale factors for the T17H profile.

DPS scale factors for the T17H profile.

The obvious take-away here is that strength and bonus armor are great. They’re also two of our best TMI stats, which is convenient. With Holy Shield selected, mastery gets a slight edge over versatility, haste, multistrike, and crit, but they’re all pretty close to one another. Obviously stamina and armor provide no DPS contribution, hence they come out as zero (or close enough to it, within error) in this plot.

So to summarize, at level 100, the stat priority for DPS is

Strength > Bonus Armor >> Mastery > Versatility / Haste / Multistrike / Crit

I would be remiss if I didn’t address some of the earlier disclaimers I threw at you. For example, I mentioned that the choice of level 100 talent can affect the stat weights. Here’s what you get if you take this profile and swap Holy Shield out for Empowered Seals or Seraphim:

TMI scale factors for the T17H profile with Empowered Seals selected.

TMI scale factors for the T17H profile with Empowered Seals selected.

TMI scale factors for the T17H profile with Seraphim selected.

TMI scale factors for the T17H profile with Seraphim selected.

On the Empowered Seals plot, mastery drops a bit compared to armor, as does strength. But both still command a healthy lead over the remaining secondary stats. Versatility swaps places with crit, but otherwise the order is basically unchanged.

Seraphim works a little differently, in that mastery’s value drops, falling in line with the other secondaries. There’s a fairly good reason for this, which I mentioned a little earlier in the post. While Seraphim is up, you’re in very little danger, because you have lots of excess stats. But your most vulnerable time is the 5-second window right before you recast Seraphim, while you’re pooling holy power. That’s where your big spikes come, and unfortunately, that’s a period you are almost never covering with Shield of the Righteous, taking a lot of the wind out of mastery’s sails. We’re also simming with a very mastery-heavy gear set, which further reduces mastery’s value.

If we take these stat weights and re-optimize the gear set somewhat, we get completely different stat weights:

Stat weights after re-optimizing the T17H gear set using Seraphim.

Stat weights after re-optimizing the T17H gear set using Seraphim.

Suddenly haste is back in the spotlight! How does that even work?

This highlights one of the major problems with calculating stat weights. This sort of calculation is based off of the assumption of linearity. In other words, we assume that the increase due to each stat is extremely linear, such that our quick sampling accurately reveals the overall trend.

Unfortunately, that assumption of linearity isn’t always very good. One way to test it is to use one of SimC’s other features, called scaling plots. This sim takes longer, but generates a graph showing how your TMI changes over a range of values. To illustrate that thought, let’s look at the scaling plots for Holy Shield and Empowered Seals:

Scale factor plots using T17H gear set and Empowered Seals.

Scale factor plots using T17H gear set and Empowered Seals.

Scale factor plots using T17H gear set and Holy Shield.

Scale factor plots using T17H gear set and Holy Shield.

Since we’re looking at TMI, the stat that has the largest negative slope on these plots is the best, because it reduces TMI by the most per point. Both of these plots tell the same story that the scale factor bar plots did: bonus armor is far and away the best stat, followed by mastery, and then followed by the other secondary stats, which all clump together.

However, this is what the Seraphim plot looks like:

Scale factor plots using T17H gear set and Seraphim.

Scale factor plots using T17H gear set and Seraphim.

Kind of crazy! We see some of the features shown on the scale factor bar plots. Bonus armor is still awesome, and mastery is now back in the clump of other secondary stats. But the haste plot is all over the place, making it tough to trust values generated from just a single scale factor simulation.

What’s happening here is that we’re hitting haste breakpoints with Seraphim. It’s a little complicated, because it’s a mix of interactions due to the rigid 15-second cycle, the reduction of the GCD, the 5-second lockout period during which we pool HP, and a few other factors. I think that in practice, none of this is worth worrying about, as a real player will make enough errors to smooth this curve out.

What you should take away from this graph is that despite haste being much less linear than the others, over the course of the graph it doesn’t actually outperform the other secondary stats. Haste might sim above or below the other secondaries in any single scale factor simulation, but on average it just oscillates around the others as you increase the amount of haste you have. Here’s the associated plot from the alternate gear set, showing the same effect. So in practice, I think that the secondary stat weights for Seraphim should probably just be “Bonus Armor > everything else,” possibly with a slight bias towards versatility and crit since those do seem to consistently outperform mastery and multistrike.

Finally, it may be worth talking briefly about the DPS stat weights for Seraphim and Empowered Seals. There isn’t a lot of difference, but here are the plots:

DPS stat weights for the T17H gear set with Empowered Seals.

DPS stat weights for the T17H gear set with Empowered Seals.

 

DPS stat weights for the T17H gear set with Seraphim.

DPS stat weights for the T17H gear set with Seraphim.

As you can see, both Empowered Seals and Seraphim favor haste, crit, and multistrike a little in terms of DPS. That said, again, we’re in a mastery-heavy set, so this is sort of expected.

With all of that in mind, I recommend you follow the survivability priority we came up with for Holy Shield. Strength and bonus armor don’t generally compete for itemization, so you’ll still be maximizing both of those regardless of which you choose. Mastery is your next-best stat in both as well. For the remainder, the small differences in stat value really aren’t going to make or break your performance. If you want a quick-and-dirty rule of thumb, it would be:

Bonus Armor > Strength > Mastery > everything else

If you’re using Seraphim or Empowered Seals and want to eke out some more DPS, you can shift itemization into haste, multistrike, and crit and de-emphasize mastery, but the DPS gain isn’t going to be that great.

Now that we have stat weights, let’s talk about how this affects our gearing.

Gear Choices

The stat weight results have some important, if subtle, implications for how we gear.

First, note that most of the time we aren’t going to be making tough decisions between gearing for DPS or gearing for survivability. Higher-ilvl gear has more of everything, but most importantly it has higher strength, stamina and armor. This means that a higher-ilvl piece will almost always be preferable to lower-ilvl piece because of the innate defensive boost from stamina and armor, and the boost to everything from strength.

Secondary stats are all similar for DPS, so we can almost ignore that aspect and select pieces based on which gives better defensive bonuses. In general, that means taking pieces with mastery on them, but again, it will usually still be a gain to take a higher-ilvl piece without mastery than a lower-ilvl piece with mastery just due to the huge value of strength, stamina, and armor.

I say almost above because it’s clear that bonus armor is an outlier here. It’s got a massive lead in both departments. There’s almost no reason you should ever pass up a bonus armor item as a result. Even a lower-ilvl item with bonus armor can trump a higher-ilvl piece without it. Bonus armor is the one stat you should be drooling over and hoarding. Luckily, only other tanks will want that gear, so competition should be low.

This manifests itself quite noticeably in one particular slot: trinkets. About a week ago, I ran a fairly comprehensive set of tests for the trinkets in tier 17, first individually and then in combinations. The two plots that most clearly summarize these results are below:

DPS and TMI results for different trinkets, simulated alone.

DPS and TMI results for different trinkets, simulated alone.

The top few DPS trinkets are either strength (Horn of Screaming SpiritsTectus’ Beating HeartForgemaster’s Insignia) or bonus armor (Evergaze Arcane EidolonBlast Furnace Door, Tablet of Turnbuckle Teamwork). The top few TMI trinkets are stamina trinkets (Pillar of the Earth, Petrified Flesh-Eating Spore, Battering Talisman), but they’re followed closely by the bonus armor trinkets (BFD, EAE, and Pol’s Blinded Eye) and strength trinkets (HoSS, Bottle of Infesting Spores).

This is a bit of a departure from what we’re used to. For the first time in a long time (at least for 25-man raiding), there isn’t a huge survivability gain to be had from stamina trinkets. They’re a little better than bonus armor and strength trinkets, but only barely – and they come with a pretty hefty DPS loss. As a result, I wouldn’t be surprised if we didn’t bother using stamina trinkets at all this tier.

Of course, the usual disclaimers apply. This sim is only one potential scenario, a TMI boss that does ~75% physical damage, etc. Stamina may shine in an encounter with a lot of magic damage and so on. But bonus armor has really taken a serious run at stamina here, because it provides all the effective-health goodness that stamina does (at least, against physical attacks), but also gives us a lot of DPS.

In fact, the bonus armor trinkets are the ones that really shine here. The combination of Blast Furnace Door and Evergaze Arcane Eidolon give you nearly the best DPS possible and almost match the TMI you get with stamina trinkets. If you look at the sim with trinket pairs, you’ll see that the only way to improve DPS over the BFD+EAE combination is to pair a bonus armor trinket with a Horn of Screaming Spirits, and the gain is only about 100 dps. The only way to beat BFD+EAE in TMI is to replace one or both with stamina trinkets, for at best a reduction of about 2k TMI.

Obviously you’ll take what drops as it comes and adjust accordingly, but it seems clear that the two trinkets we’ll value most highly are BFD and EAE. And again, as bonus armor trinkets, you won’t be competing for them with your plate DPS guild-mates. It won’t hurt to keep a spare stamina trinket or Horn of Screaming Spirits in your bags to customize your load-out to the fight, but in all likelihood the BFD+EAE combination will be your go-to trinket setup for the entire tier, provided you can get your hands on them.

There’s one last gearing point to discuss, and that’s tier bonuses. Unfortunately, there isn’t much to say yet. Preliminary work suggests that both tier bonuses are worth getting, despite the fact that our tier isn’t heavily mastery-itemized. But I haven’t had time to do an exhaustive comparison here, and frankly, that sort of comparison won’t be relevant for at least a month or more thanks to the fact that the Highmaul raid doesn’t drop tier tokens. By the time we actually have access to them, I’ll have results to share. So expect a follow-up blog post on that topic.

Glyphs

I did a little preliminary work with glyphs here, and updated them for L100 here. The short version is that for DPS,

Harsh Words > Alabaster Shield > Double Jeopardy (2T+) > Focused Shield (1T) > Final Wrath

This is with Holy Shield selected, which gives Alabaster Shield a boost (thanks to Holy Shield). It’s also using Divine Purpose, so Final Wrath may get a little stronger if you take Sanctified Wrath, but probably not enough to catch up to the next two choices (it’s behind by 300-some DPS). Note that you only get a benefit from Double Jeopardy if you’re properly cycling targets the whole time, and Focused Shield is a flat-out DPS loss whenever you can cleave to 2+ targets.

The only other thing to mention is that while Immediate Truth is a DPS loss against bosses, it could be useful while leveling. The difference in DPS is small enough that it’s almost certainly a DPS gain if the target doesn’t live long enough to build up a 5-stack of Censure, which is pretty common while leveling. So you may want to consider using that if you’re leveling with Seal of Truth active.

WeakAuras Strings

Not much has changed here, though I did add a Seraphim cooldown icon. I hope. I forgot to do it on beta, so I had to do it on live, which means I obviously can’t test it. But I will as soon as I get to 100, and it’s a simple icon so it should just work assuming I got the right spell id.

Here’s what they look like:

 

As I said last time, I removed a lot of the useless stuff. While I’m not using a Resolve bar, somebody asked for one, so you can find it on the WeakAuras page.

Any Questions?

That’s pretty much all I have for you today. But I’ve been pretty busy lately, so it’s possible that I’ve forgotten something. Or that you might want to know more about something I mentioned, or maybe something I didn’t mention. So I’ll try to be around most of today to answer any questions you post in the comments.

 

Posted in Tanking, Theck's Pounding Headaches, Theorycrafting | Tagged , , , , , , , , , , , , , , , | 34 Comments

Simulationcraft 6.0.2 – New Features

Now that we’re made the transition into raiding in a post-6.0.2, pre-level-100 world, I wanted to bring you up to speed on what’s been happening in Simulationcraft in the past few months.

Simulationcraft 602-1 was released on Tuesday, and you can get it at the usual downloads page. As you’d expect, it’s updated with the new mechanics that patch 6.0.2 brings to the table, and works seamlessly for characters of level 90 to 100. Default profiles have been updated, though we’ve removed the old normal T16 profiles and renamed the old heroic profiles “T16M” (since it’s now Mythic difficulty).

I’ve ironed out all of the bugs I’m aware of in the paladin module, so Ret and Prot should be working well. I think most of the other modules are too, though I can’t personally vouch for them since I haven’t worked on or tested them. But if you want to sim your Ret or Prot paladin, you can be pretty certain the results are accurate. And as always, if you do find a bug, let me know ASAP so I can look into it.

What I really want to go into today are the other changes and new features, though.

Automation Tab

Simulationcraft's Automation Tab - First Look

Simulationcraft’s Automation Tab

The automation tab is new to SimC if you haven’t been using the alpha builds. It’s an interface that lets you quickly generate profiles containing many different actors (SimC’s term for an individual player or boss) with different configurations of talents, glyphs, gear, or even action priority lists. If you’ve been following the blog, then you know I wrote a tutorial (part one, part two) explaining how to use the tool to compare different options.

I’ve been using this tool heavily during the last three or four weeks, because I’ve been doing a lot of theorycrafting  about talents, rotations, and so on. For example, I used it heavily while determining the best default action priority list for SimC. I hope to find time to write a blog post describing that process in the next week or so. Likewise, it’s immensely useful for comparing different talent configurations, like so:

DPS and HPS rankings for different talent configurations.

DPS and HPS rankings for different talent configurations.

The automation tool makes it easy to perform simple comparisons, like which talents or glyphs work best, without needing to know much more than the basic SimC syntax you’d use to tweak a profile. And the whole tool has mouseover tooltips that give instructions on how to format the text for each box, just in case you forget.

Options Tab

The new Global Options tab.

The new Global Options tab.

The options tab has also gotten a bit of an overhaul. It’s now separated into three columns according to category. Basic options that are applicable to most players, like number of iterations, fight length, and options related to importing characters are in the left column.

The center column has a bunch of options related to tanking and boss selection. This is where you can specify things like the number of enemies, target (boss) level and race, and the TMI window length you want to use. But I’ve also added a new option called “Target Type” that lets you select what type of boss you want to fight. Included are options for Custom (if you want to define your own within the profile on the Simulate tab), Fluffy Pillow (not very well calibrated), Tank Dummy, and TMI Standard Boss.

Target Type drop-down box.

Target Type drop-down box.

TMI Standard Bosses are pretty much how you remember them. Now that there’s no more 10- vs. 25-man formats to deal with, we just have one boss for each difficulty. They all use the new nomenclature, so they’re T16L/T16N/T16H/T16M for this tier and T17N/T17H/T17M for tier 17. Each boss will be roughly tuned to match the damage output of a very tough 20-man raid boss (ex: Garrosh).

You might have wondered what “Tank Dummy” bosses are. These are the tank dummies you can find in Shattrath (outland) on the beta servers, which come in Weak, Dungeon, Raid, and Mythic versions. These are all programmed to match the damage output of the dummies in-game, so if you’re in beta you should be able to directly compare sims against these dummies to in-game logs against those exact same dummies.

Tank Dummies!

Tank Dummies!

One word of warning, though: the Target Type drop-down determines what boss you get.  In other words, if you want a TMI Standard Boss, you have to set the Target Type to “TMI Standard Boss.” It doesn’t matter what you choose in the TMI Standard Boss drop-down box if you haven’t told the sim you want a TMI Standard Boss in the first place! The same is true for the Tank Dummy drop-down – you won’t get a Tank Dummy if you have Target Type set to something else.

If the sim can’t figure out what you want (e.g. if you chose a Target Type of “Tank Dummy” but leave the Tank Dummy drop-down set to “None”), it will give you a Fluffy Pillow as a consolation prize.

Spell Query Tab

One tool that theorycrafters have had in their back pocket for quite a while is SimC’s “spell_query” command-line syntax. This lets you query the spell data directly to find out what it says. For example, with a quick call to spell_query, we can answer lots of questions about Crusader Strike:

SimC's spell_query command-line interface.

SimC’s spell_query command-line interface.

This tells us most of the pertinent information: resource cost, spell level, range, gcd, cooldown, and a list of all spells that affect Crusader Strike. The “Effects” section tells us about the stuff that’s unique to CS: It uses normalized weapon damage, does 100% of that weapon damage, and gives us a charge of Holy Power.

The functionality of spell_query is now built into the GUI so that you don’t have to worry about loading up a command prompt and remembering syntax. Now, you can just switch to the Spell Query tab and use the convenient drop-down boxes:

Spell Query Tab

Spell Query Tab

This interface lets you choose the data source (e.g. “spell” or “talent” or so on), filter (“name”, “id”, etc.), and then an operator and an argument. So for example, choosing spell.id>=1 will give you the data for every spell in the game. This also has a “save to file” option in case you want to save all of that data to a file to search through later. More commonly, you’ll just use the interface to search for e.g. spell.name==crusader_strike to get the data for the specific spell you want.

Reporting Features

We’ve also made some major changes to the html reports that Simulationcraft generates. In some cases, they reflect not just a change in display, but a change in how we do things “under the hood” within the program itself.

For example, if you’ve ever generated stat weights in SimC, you know that you have to choose what metric you want to use to calculate those stat weights. You have your choice of DPS, DTPS, HPS, TMI, and a bunch of other metrics, but no matter what you choose, the sim only gives you a table and graph showing stat weights for that one metric. If you ran a sim generating scale factors for TMI, and then wanted to know how those same stats stacked up for DPS, you’d have to re-run the entire sim. And if you’ve done this recently, you know that generating stat weights can take a reasonably long time.

That’s all changed in SimC 602-1. Now, when you generate stat weights, you’ll see something like this:

New Stat Weights display.

New Stat Weights display.

Looks the same, right? Look closer. In addition to the table giving you the stat weights for the metric you’ve chosen (in this case, TMI), there’s a collapsible heading called “Scale Factors for other metrics.” If we click on that, we get….

More stat weights!

More stat weights!

Yes, the sim calculates stat weights for every metric simultaneously now, and the report contains tables for all of them. So at the same time that we found

Haste>Mastery>BonusArmor>Versatility>Crit>Str>Multistrike

for TMI, we also found out that

Str>BonusArmor>Haste>Multistrike>Crit>Versatility>Mastery

for DPS.

Right now, the only plot that we generate is the one you request (again, in this case TMI). It would have cluttered things up too much to create stat plots for each metric, and at any rate, we’re moving to a new plotting interface in the near future that will let us store all of that data in one plot and let you choose what you want to see in real time. So eventually, you’ll be able to switch seamlessly between scale factors for TMI or DPS or anything else within that same plot. Pretty nifty.

Another new feature on the reports is tooltip integration. If you look at the Abilities or Buffs table or the Gear section, you’ll notice that these components now have wowhead tooltips:

Wowhead tooltips on spell names.

Wowhead tooltips on spell names.

This makes it easier to identify that buff or proc you don’t recognize without having to tab out to a browser. Note that these are disabled on simulations with many actors because they slow down the report pretty appreciably, so we only use them for sims with a handful of players.

Moving further down the report, I want to draw your attention to a section that doesn’t often see much use – the Action Priority List section. This gives us the action priority list that the actor uses in the sim, and at the end, there’s always been a “Sample Sequence” that looks something like this:

Sample Sequence in the Action Priority List section.

Sample Sequence in the Action Priority List section.

This sample sequence is coded to the APL, and in theory lets you see exactly in what order you’re casting things. If you mouse over one of those letters, it will also tell you the time, target, your resources at the time (mana and holy power), and what buffs were active.

Which is all well and good but…. this format is really tough to understand, at least for a human. Most people will have trouble remembering what each of the 40+ letters means, and mousing over each entry isn’t very efficient. So I added another visualization that’s a little easier to work with.

If you’ll note, there’s another collapsible section called “Sample Sequence Table” underneath the alphanumeric block. If we click on that, we find…

Sample Sequence Table Display.

Sample Sequence Table Display.

This is the same data, but put into a table format that’s easier to read and work with. You can see exactly what’s cast, the timestamp of the cast, the resources, the buffs – everything you can get out of the alphanumeric block. But this version you can visually scan very easily to identify particular spells, or do a simple text search (e.g. finding “judgment”) to find a particular spell.

This is mostly useful for debugging action priority lists. For example, you can go through this step by step to see if the actor is really doing what you think they should be doing. And if not, it can give you hints as to what mistakes you may have made in the APL.

Simulationcraft Addon

One final change is outside the program itself. Have you ever wanted to import your current character, but realized that you just changed some gear and the armory hasn’t updated yet? Or maybe you’re in game, swapping pieces of gear around trying to figure out which configuration is best, and don’t feel like logging in and out over and over to keep updating the armory. Or maybe you’re on a beta server, so you can’t even use the armory for import! If you’ve ever found yourself in one of those situations, you were probably wishing there was some better way of getting that character info out of the game and into Simulationcraft.

Well, now there is. The Simulationcraft Add-on.

The Simulationcraft  AddOn

The Simulationcraft AddOn

Over the summer I wrote an addon that will generate a Simulationcraft profile for your character while you’re in the game. It pops up a small text window with that information, which you can then copy and paste directly into SimC’s “Simulate” window. Quick, simple, and painless. This addon should work on live servers as soon as 6.0.2 is up and playable.

Posted in Simcraft, Simulation, Theck's Pounding Headaches, Theorycrafting | Tagged , , , , , , | 12 Comments

Patch 6.0.2 Survival Guide

Patch 6.0.2 is upon us, and with it comes a host of changes to the game and our class. This post is your quick and easy guide to making the transition from raiding in 5.4.8 to raiding in the brave new world of 6.0.2.

Unlike usual, I’ll try and keep things short and to the point.

Major Game Mechanics Changes

These are all changes to core systems in the game that affect us as tanks, so you should know about them.

  • Hit and Expertise are gone – You’ll now automatically hit appropriate-level targets all the time. Technically speaking, there’s still a 3% chance to be parried when attacking from the front, but as a tank, you have a passive that gives you a free 3% expertise (Sanctuary for paladins) that eliminate that chance.
  • Everything was squished – You’ll note that stats are much lower than before, and the amount of rating on gear has been reduced substantially, but so have the conversion coefficients. So for example, it used to take 425 haste rating for 1% haste, but now it only takes 20 haste rating!
  • Tank mitigation was squished – To try and rein in tank survivability and self-sustainability, tank mitigation was nerfed pretty much across the board. You’ll find that many spells, especially ones that provided flat percentage effects, now provide less mitigation than they used to. We’ll talk more about details further down the page. However….
  • Health was squished… less? – You won’t have 1 million hit points anymore, but you will still have substantially more health compared to what you’d expect post-squish. That’s because rather than getting 14 hit points per point of stamina, you now get 60. This is all part of the revamped tanking/healing model they’re trying in WoD.
  • Snapshotting is gone – For the most part, damage-over-time and heal-over-time spells do not snapshot stats (like attack power, crit, etc.) anymore. There are a few exceptions, but none (at least that I know of) that we care about. The damage and healing of abilities like Eternal Flame, Sacred Shield, etc. will now dynamically update with your current stats on every tick.
  • Pandemic for everyone! – If you’ve played a warlock, you may recall a passive effect called “Pandemic” that allowed you to refresh DoTs to up to 150% of their base duration. That same mechanic (though reduced to 130%) has been applied to all HoTs and DoTs in WoD. This means that, for example, if you refresh Sacred Shield with 15 seconds remaining, the new duration will be 39 seconds, not 30 seconds. Likewise it means that refreshing it with up to 9 seconds remaining won’t “waste” any of the remaining duration.

And there’s one change so big that it deserves its own section….

Vengeance – GONE

Vengeance is finally gone. No more standing in the fire to boost your DPS!

It’s been replaced by a mechanic called Resolve. The tooltip for Resolve is misleading – much earlier in beta, there was a static component based on your Stamina, but that’s long since been removed. Now it just increases your self-healing and self-absorb effects based on the damage you take. Mathematically it’s fairly complex – I covered the original version in this blog post, but that’s now out of date – but for now all you need to know is that:

  • It doesn’t turn on until you’ve taken a certain amount of damage in the last 10 seconds,
  • It continuously re-calculates its value based on the damaging events that happened in the last 10 seconds,
  • It has built-in diminishing returns that limit its effectiveness to a 240% boost to your baseline (zero-Resolve) healing.

The plot below shows the diminishing returns curve as a function of “DamageMod,” which is related to your damage intake. Again, I don’t want to get into the mathy details today, so for now all you need to worry about is that it increases your self-healing more as you take more damage, with fairly smooth diminishing returns.

Resolve diminishing returns curve. "Old" refers to the version that gave -60% to all healing.

Resolve diminishing returns curve. “Old” refers to the version that gave -60% to all healing.

There are a few reasons that Resolve is pretty awesome when compared to Vengeance. First, since it’s decoupled from damage entirely, there’s no longer an incentive to stand in fire, or worse, jump through inane hoops to solo-tank bosses for huge DPS gains (Heroic 25M Garrosh, I’m looking at you…). The diminishing returns also ensures that it’s never worth taking increased damage – for example, if you take 2x as much damage, you won’t generate twice as much healing, so it’s a net survivability loss.And thanks to the changes to snapshotting, our self-healing abilities will dynamically update with Resolve. That means we can get rid of a ton of weakauras we’ve historically used, both for tracking our current amount of Resolve and for tracking what level of Resolve, haste, and so on we were at when we last cast Eternal Flame or Sacred Shield. I am really looking forward to hitting “delete” on a bunch of those auras!

Class Changes

There are a bunch of changes that affect Prot Paladins specifically that I want to talk about in more detail.

In the great ability pruning of ’14, many a skill was lost by many a class. As Protection Paladins, we lost access to Avenging Wrath, Devotion Aura, and…. that’s about it. So much for freeing up key bindings. Technically we freed up another key bind in Blinding Light, which was moved to the second talent tier.

Sanctified Wrath has been totally redesigned since we no longer have Avenging Wrath. Now it causes Holy Wrath to generate a charge of Holy Power and makes it hit like a truck by doubling its damage. No, seriously, like a truck:

Holy Wrath really does hit like a truck with Sanctified Wrath talented.

Holy Wrath really does hit like a truck with Sanctified Wrath talented. It does nearly twice as much damage as Avengers Shield (with Focused Shield glyphed).

If you decide to take the Final Wrath glyph, you can add another 50% to that. In other words, if it does 10k damage with no talents, it does 20k with Sanctified Wrath talented and 30k if Final Wrath is glyphed. Fun stuff.

One downside of all of this massive damage is that Holy Wrath has a longer cooldown in Warlords, up from 9 seconds to 15 seconds. This is somewhat unfortunate from the perspective of picking up groups of adds, in that it will be less available than before. But it will hit significantly harder, so it’ll do a better job of picking them up when it is available. It’s just a shame that it still splits damage amongst all targets hit.

Level 45 talents have all seen some significant changes. Eternal Flame got hit pretty hard with the nerfbat. The base heal is unchanged (still identical to Word of Glory), but the heal-over-time portion was nerfed several ways, the biggest one being that it no longer benefits from Bastion of Glory. This is bad from a “massively overpowered self-healing throughput” point of view, but good from a balance perspective because… well… it was massively overpowered. This should put allow it to stay on more even footing with the other options in this tier.

I should also add that it got a quality-of-life improvement, though. Rather than having the heal-over-time portion heal for less when you cast with less than three holy power, it now just has a shorter duration. So if you need to emergency-WoG yourself with only one or two Holy Power, you’re not gimping yourself with the HoT – you’re just not getting the full 30 seconds out of it.

Sacred Shield, on the other hand, got hit with the… buffbat? Unlike in MoP, Sacred Shield ticks can now individually crit, and now that multistrike is a thing they can do that as well. So if your Sacred Shield normally ticks for 100, a lucky tick that crits and makes both multistrike rolls will tick for 320.

Selfless Healer got nerfed, in that it no longer benefits from Bastion of Glory. On the other hand, in all the re-tuning it ended up in a not-so-awful place. So it might actually be a viable contender in 6.x. More on that later.

As I mentioned earlier, many of our mitigation abilities got nerfed. It isn’t worth going into detail on all of them, but there are a few you should be aware of:

  • Shield of the Righteous‘ base mitigation was nerfed to 20% (from 25%), and each point of mastery now only provides an additional 0.75% mitigation (down from 1%).
  • Bastion of Glory only provides 6% per stack (down from 10%), and each point of mastery only adds 0.75% (down from 1%).
  • Divine Protection and Guardian of Ancient Kings now only last 8 seconds (down from 10).

Finally, there are some new passive skills you should know about. The first is Bladed Armor, which is a hidden passive that causes bonus armor on gear to also grant attack power. This makes bonus armor a potent offensive stat in addition to its already-respectable defensive benefits.

The second is Riposte, which causes critical strike rating from gear to also grant an equal amount of parry rating. This gives crit rating a defensive benefit, so that it isn’t useless to us.

The third is Shining Protector, which gives multistrike a more significant defensive benefit. Any time we receive a heal, Shining Protector has a chance to proc an extra heal for 30% of that amount. It works on our own self-healing as well as external healing.

And finally, the new passive Sacred Duty increases the amount of haste rating you get from gear by 5%.

Gear Changes

After the patch, all of your gear will be “squished” in the sense that it will have much less rating on it. In addition, hit, expertise, dodge, and parry will be converted to crit, mastery, or haste. For example, here’s the dodge/parry chest from T15 before and after the squish:

Comparison of an item before and after squish and stat changes.

Comparison of an item before and after squish and stat changes.

The one exception is that dodge and parry on “non-armor” pieces like rings, amulets, and trinkets, which can turn into bonus armor. Since bonus armor will be a fairly prized stat, this will make some items that were ignored pre-6.0, like Juggernaut’s Focusing Crystal, suddenly very desirable.

Dodge and Parry on rings, amulets, and trinkets can turn into Bonus Armor.

Dodge and Parry on rings, amulets, and trinkets can turn into Bonus Armor.

Gems were also squished – you’ll find that your 320 haste gems from 5.4.8 are now only 20 haste.  On the other hand, that’s actually a buff due to rating conversion changes. Pre-patch, each of those gems gave you 0.75% haste, while post-patch they each give you 1.00%.

In addition, all of your hit and expertise gems will have turned into crit and haste gems, respectively. Wowhead has a great summary of both the new gem combinations and the other gear changes coming with this patch.

Between the more favorable rating conversions and a large chunk of hit and expertise on your gear turning into haste, you may find yourself significantly over the 50% haste cap when you log in on Tuesday.

Stat Priority

Unsurprisingly, the shuffling of stats, massive re-tuning of abilities, and tank mitigation nerfs all had noticeable effects on our stat priority. Whereas before, haste was our most-desired stat, it’s now only about average.  On the other hand, mastery has really become strong, which in part led to the SotR and Bastion of Glory nerfs mentioned earlier.

Here’s an example of what your stat weights might look like if you’re wearing Mythic T16 gear:

Example stat weights for a T16 Mythic-geared raider.

Example stat weights for a T16 Mythic-geared raider.

I’ve tweaked the gear in this case so that we’re far enough below the haste cap of 50% that we aren’t artificially lowering its value. As you can see, mastery and bonus armor dominate, with stats like versatility, haste, and crit all trailing. Our new secondary stat priorities for survivability are,

Mastery > Bonus Armor > Haste (to 50%) > Crit > Multistrike

There are some caveats to mention here, of course. First of all, multistrike is probably a little stronger than the sim represents, because we’re simming without an external healer here. That said, I don’t know that it’s that much more valuable. It’s certainly a strong throughput stat when you’re being healed, but generally when you’re being healed you aren’t dying either. In the situations where you do die, which are usually situations where you have a shortage of incoming healing, multistrike’s value isn’t likely to be much higher than this sim predicts.

It will remain to see exactly how deaths happen in 6.0 before we can really estimate it more accurately – if trickle-down deaths over 10+ seconds are the norm, then multistrike will probably be a fairly strong stat that we may want to stack over haste and crit. If spike deaths in 5- to 6-second windows are still the target (as opposed to the 2-second windows we see now), then it’s not likely to be our go-to stat.

Second, we’re simming this against a T17 Mythic boss scaled down to level 90. So stamina’s value here is a little larger than it normally would be. Again, for Siege content you can probably skimp on stamina in favor of mastery for more mitigation, but until we really get a chance to play with 6.0 Siege it’ll be hard to say exactly how much stamina feels comfortable.

In case you’re wondering, the DPS stat priorities are a little different:

DPS stat weights.

DPS stat weights.

In this case, strength reigns supreme, followed closely by bonus armor. Put in order, our DPS priorities would be:

Strength > Bonus Armor > Multistrike / Crit > Versatility > Mastery > Haste

For buffs or effects that give attack power, you can just recall that 1 bonus armor gives 1 attack power, so AP is exactly the same as bonus armor for offense.

I ran some quick sims of the same T16M gear set with different gemming patterns to see how they differed. You can see all of the specifics here, but in summary, I took the gear set and re-gemmed it for haste, crit, and mastery just to see what would happen. Here are the DPS and TMI results:

Different gearing strategies.

Different gearing strategies.

As you can see, the mastery build does hold a significant TMI advantage, while the crit build gives the most DPS. Haste doesn’t really excel in either department anymore, sadly. The entire report can be found here if you want to dig through it in more detail.

Talents

Obviously at level 90, we don’t need to worry about the new level 100 talents. So our talent questions center around the usual three tiers: level 45, level 75, and level 90.

Level 90 is the easiest. Execution Sentence is still top DPS, but neither Light’s Hammer nor Holy Prism are that far behind. Holy Prism is still a great choice for add pick-up and such, while Light’s Hammer is still a very versatile AoE pick-up tool. Both of their raid-healing capabilities are somewhat diminished by the removal of Vengeance – Resolve won’t boost their healing on other raid members.

For the other two tiers, here are some sim results:

Talent simulations.

Talent simulations.

At level 45, we actually have a fair choice. Even though it’s not on the plots, Selfless Healer has been surprising me in some of my L100 sims, mostly in that it’s not that far behind. But it’s still far enough that we probably won’t take it. That said, if you really like that play style, you aren’t gimping yourself as much by taking it after 6.0.

Between Sacred Shield and Eternal Flame, the race is tighter. You really aren’t in too bad shape with either choice, but even with the strength of the T16 4-piece bonus, Sacred Shield comes out ahead. It does, however, come with a small DPS cost thanks to the GCDs required to refresh it.

The HoT component of Eternal Flame only does about 1/3 as much healing as Sacred Shield provides in absorption, which is why Eternal Flame can’t really keep up here. Once we lose the T16 bonus that’s propping up Eternal Flame, it’ll fall even further behind. Without a significant buff, I don’t see EF competing with Sacred Shield at level 100.

Finally, for our L75 talents, we again have a pretty fair choice. Divine Purpose is dominating the TMI charts, but also gives the lowest DPS. Sanctified Wrath gives the highest DPS, but at a TMI cost. Holy Avenger performs respectably in both categories, though it trails the other two in TMI. Really though, they’re all fine, and it will generally come down to personal preference or which one suits the fight better.

To be honest, I’m pretty impressed – never before have we seen both the L45 and L75 talents so well balanced with one another. My initial sims suggest that this will remain the case at 100, which is pretty neat. It’s gotten pretty boring having only one “correct” answer in a tier, and I’m glad to see that we’re moving away from that.

Rotation

I’ve been doing a lot of work fine-tuning the rotation that I’ve used in these sims, especially for level 100. At level 90 it’s significantly easier, and doesn’t take much modification from what you’re already used to.

At level 90, the base rotation priority is as follows:

  1. Crusader Strike
  2. Judgment
  3. Holy Wrath – if Sanctified Wrath is chosen
  4. Avenger’s Shield
  5. Level 90 Talent (any of them)
  6. Hammer of Wrath
  7. Holy Wrath
  8. Consecration

As you can see, not too much has changed. Holy Wrath is much higher in priority with Sanctified Wrath chosen thanks to the Holy Power generation. As we level to 90, the second Holy Wrath entry will actually drop behind Consecration once the Improved Consecration perk is obtained.

As far as Sacred Shield goes, refresh it in any empty GCD. If it’s about to expire, slot it in above anything that doesn’t generate Holy Power (so use it instead of Avenger’s Shield only if you don’t have a Grand Crusader proc).

For AoE, make some simple modifications:

  • Replace Crusader Strike with Hammer of the Righteous,
  • Bump Consecration up to be equal with L90 talents (technically ahead of Execution Sentence, but behind Light’s Hammer or Holy Prism), and
  • Move Avenger’s Shield to the very top of the list if you have a Grand Crusader proc and you will hit more than one target (i.e. Focused Shield is not glyphed).

None of those should be all that surprising, and they’re basically exactly what you do now in AoE circumstances.

WeakAuras?

I’ve updated my WeakAuras on the beta, though I haven’t added level 100 talents yet. I’ll have a more complete post discussing what changed up in the next week or so. The links below will give you the import strings you need to get up and running though:

Theck-Prot-PriorityTheck-Prot-Cooldowns
Theck-Prot-Priority-SW
Resolve/Haste Text Indicators

The Priority and Cooldowns groups are similar to before, but I’ve re-arranged them for the new spell priorities and removed spells we don’t have anymore (Avenging Wrath, Devotion Aura, etc.). The “Priority-SW” group is an overlay that switches the priority when you talent into Sanctified Wrath. Finally, the Resolve/Haste indicators are just simple text indicators that show your current haste percent and Resolve amounts.

Note that all of the Vengeance Bars, SS and EF indicators, and so on are all gone – they’re all irrelevant now, so it was nice to clean house and get rid of loads of excess auras. Those were also some of the more computationally-intensive auras, so the rest of the suite should run a little faster as a result.

One warning: on beta, the cooldown spirals weren’t working, and I couldn’t figure out why. I assume it’s a simple bug in WeakAuras that will be fixed eventually.

Ask A Theck!

That covers all of the important topics that I could remember, but it’s entirely possible I forgot to mention something. I’ve been working in “beta-mode” for so long now that the line between “current” and “beta” has started to blur. So if there’s anything you want me to clarify further, or any questions you have for me, feel free to ask them in the comments. I’ll try to answer everything that gets asked throughout the day.

Also don’t forget that you can run your own character through SimC to see how your personal stat weights work out. I’ll have a post up Friday giving you an overview of all of the new features we’ve added to SimC in the last few months.

The Icy Veins guide, which I help edit, has also been updated for 6.0.

Posted in Simcraft, Tanking, Theck's Pounding Headaches, Theorycrafting, Uncategorized | Tagged , , , , , , , , , , , , , , , , , , | 86 Comments

Protection L100 Talents

I want to talk a bit about our level 100 talents, but not in the way you might expect. This post isn’t going to be full of numbers, nor is it going to be a comparison of how the talents perform in a raid setting. In fact, there’s very little quantitative analysis of the talents in it at all. What I want to talk about is how the talents feel on a purely qualitative level.

Obviously that makes much of this post opinion, rather than fact. So keep that in mind – none of this is based on numbers, it’s all based on how I feel about the talents, and most of these opinions were formed well before I started running simulations to figure out how well they perform. You’ll get the performance posts soon enough, once I have time to write those up.

Holy Shield

Image courtesy of wowhead.

Holy Shield is my favorite of the talents, but I’ll admit that I may be unreasonably biased just because of the name. During MoP beta, I campaigned for Shield of the Righteous to be renamed Holy Shield, because Holy Shield is just more iconic. In fact, I’d still love to see the names swapped. I’d love Holy Shield to be our active mitigation and Shield of the Righteous be the talent.

Regardless though, there’s a lot to like about this talent. It plays into the “block tank” theme that our kit was ostensibly based around before we lost that niche to warriors and Shield Block. It seems like Warlords is trying to bring a little bit of that back. We have the Improved Block Draenor perk that brings our block value up to 40%, and both of our tier set bonuses center around blocking as well. The two-piece gives us Faith Barricade, increasing our block chance by 50% after casting Avenger’s Shield, and the four-piece gives us a chance to proc Defender of the Light every time we block, boosting our block value by 50%.

Not only do we block more often with the talent, but we get the unique ability to block spell damage, which is pretty cool. If that doesn’t sound cool to you, consider that with a little mastery-stacking we can reach block cap while Faith Barricade is active, because the buff’s effect isn’t subject to diminishing returns. So if we save Avenger’s Shield for that large incoming magical attack, we can guarantee 40% mitigation of that attack through blocking. And if we’re lucky and Defender of the Light is active, we’ll mitigate 90% of it.

The damage return is just fun for nostalgic reasons. It brings back a bit of the BC- and Wrath-era “round up all the things” strategy that some of us miss. The damage isn’t shabby either, at 50% of your attack power. In an AoE situation, this talent should really shine. The downside is that it obviously doesn’t provide any damage output when you’re not tanking, but if the coefficient is tuned properly that can still be tweaked to balance it with the other two talents.

So if you couldn’t tell, I’m pretty positive on Holy Shield. Unfortunately, I’m not as positive on our other options.

Seraphim

Image courtesy of wowhead.

Seraphim is an interesting idea. 50% of the time (15 second duration, 30 second cooldown) you become a giant ball of bad-ass with inflated stats. Seems fun, especially since it comes with a pretty animation. Seems like a great choice for fights with tank swaps, since you can pool up holy power to prepare for the taunt and get higher effective uptime out of the talent.

What really bothers me about this talent, though, is the holy power cost. Five holy power is steep. One of the things that Blizzard finally learned after Cataclysm was that a resource system is sort of meaningless if all you do is build up to the cap and then dump. That’s why we got Boundless Conviction in Mists – to turn holy power into a real resource that we could pool and spend, and make meaningful decisions about how and when we do either.

And yet… despite learning that 3-HP ability costs in a 3-HP world were limiting and frustrating, here we have a 5-HP ability in a 5-HP world. Apparently the lesson wasn’t taken to heart. I’d much, much rather have a 3-HP version of Seraphim that gave us 800 of each stat for 15 seconds or 1000 of each stat for 12 seconds than the current version. That 5-HP cost is just going to feel awkward when we’re used to spending only 3 at a time.

With a 5-HP cost, we’re almost guaranteeing that we won’t be using Shield of the Righteous in the ~5-6 seconds before Seraphim comes off of cooldown. Otherwise we’ll be delaying Seraphim and getting less bang for the buck out of our talent choice. Divine Purpose procs might help with that, and we could perhaps assume that our last SotR will cover the first part of that period. And of course, maybe that period is while we’re off-tanking if we’re talking about a tank swap scenario. But for regular old steady-state “take it in the face all day erry day” tanking, this is opening us up to a potentially-dangerous spike window. And turning into an invincible angel isn’t very effective if you’re dead before you get to cast it.

That said, when we get to cast it, it will be nice. We get about 4% reduced damage intake from the versatility rating, about 6% dodge from the critical strike rating, 10% haste, 9% crit, 9% mastery, 15% multistrike, and a fair bit of mitigation and attack power from the bonus armor. And we’ll still get one or two SotRs off during that 15 seconds. It really does live up to its billing as a miniature (or not-so-miniature) cooldown. I wouldn’t be surprised if it’s significantly stronger than Divine Protection, though probably not as good as Guardian of Ancient Kings.

However, it’s going to be very, very strange in the first tier of content while holy power income is still limited. You won’t, for example, want to take Eternal Flame and Seraphim together because they’ll be competing for resources, so Seraphim and Eternal Flame are almost mutually exclusive – they may as well be on the same tier of talents.

There’s also the question of “how many cooldowns is too many?” As part of the tank squish, Blizzard toned down cooldowns across the board. Yet we still have three baseline cooldowns (Divine Protection, Guardian of Ancient Kings, and Ardent Defender) and now two talented options (Holy Avenger and Seraphim). I wouldn’t be surprised if we end up chaining all of those to be nigh-invincible for minutes on end.

Last but not least, it also adds a button to an already busy spec. Many classes lots a lot of buttons this expansion, but not us. We’ve lost relatively few. I guess Seraphim can go where Avenging Wrath used to be on my key binds. But I’m a little disappointed that we’ve gained very little ground in the massive key bind disarmament process, and gaining a new tier of activated abilities isn’t helping with that.

So, overall Seraphim is interesting, and could be fun, but I’m a little worried about it feeling awkward and giving us a little too much cooldown coverage. I guess you could say I’m sort of neutral on this talent. Don’t hate it, don’t really love it either.

Empowered Seals

Image courtesy of wowhead.

Empowered Seals is my least favorite talent from a design standpoint. In principle, I’m behind the idea of making seals more interesting. Right now, seals are set-it-and-forget-it buffs for protection. It’s not even worth swapping to Righteousness in AoE situations, because in most cases you need the self-healing from Insight to stay alive. And it’s not even worth the GCD to swap to Seal of Truth for single-target damage. But while I’d like to see seals be interesting, I’m not a fan of this implementation.

First of all, I really don’t like seal twisting. And this talent is advertised as the talent for people who like seal twisting. I’m sure there must be a few people out there who do like seal twisting, but I’m not one of them. Let me explain why.

Empowered Seals may as well be called “Holy Maintenance Buffs.” Having one maintenance buff in a spec is fine, in my opinion. As an example, I had no problem with Inquisition, even though many Retribution paladins complained. Maybe it was a bit annoying when the duration was only 30 seconds, but especially in 5.4 with a 1-minute duration, it was really hard to complain about Inquisition. Not that it stopped people from doing so, of course, which eventually led to it being pruned in Warlords.

When I discussed this with Meloree, he was quick to chide me for jumping on the “maintenance buffs suck” bandwagon. And he has a point. Buff maintenance has its strong points. In particular, it tends to be very good at differentiating players by skill. Even if you invoke a macro to take most of the thought out of it, you’re still choosing which GCDs to use to refresh those buffs, and that decision making process takes skill. And there are players who really like that play style – likely the same people who love seal twisting.

So I want to make it clear that my distaste for the talent isn’t because I hate all maintenance buffs. Having one or two maintenance buffs is perfectly reasonable, and in fact is even desirable. In Mists of Pandaria, we have two buffs that qualify as “maintenance,” or at least “actively managed” buffs: Shield of the Righteous and either Sacred Shield or Eternal Flame. And I feel like that game play has worked out rather well for us. It certainly hasn’t felt cumbersome to manage those two buffs.

However, juggling multiple maintenance buffs can quickly sap the fun out of a spec. Cataclysm-era subtlety rogue felt a lot like that, when I was fooling around on an alt in sub-par gear. While it was interesting to learn how to effectively keep Slice and Dice, Rupture, Hemorrhage, and Recuperate all up at the same time, it ended up feeling like I never really got to spend those combo points showing the boss the pointy end of my Eviscerate.

The entire seal twisting concept is all about swapping seals every 8-10 seconds. By definition, it’s adding up to 3 more maintenance buffs we have to watch and maintain. And those are added to the two maintenance buffs we already have. If you consider that we might be spending up to 3 GCDs every ~20 seconds to cycle seals, and another one on Sacred Shield (I’m cheating here a bit, because I know it’s simming ahead of EF) every 30 seconds, you’re looking at spending 18%-30% of your GCDs on maintaining buffs.

That just seems excessive to me. Compare that to MoP Retribution, which lost Inquisition in part because it felt like too much of an annoyance to maintain. It only spent 1 GCD every 60 seconds, which is a paltry 2.5% of your GCDs at most, and that was considered too much. How do you think Rets will respond to using even 10% of their GCDs to keep two of those buffs up? How much worse will it feel for a starter prot in low haste gear using almost one third of their GCDs to maintain buffs?

Even if seals were off-GCD (and thus didn’t interfere with the rotation), I think I would dislike it, because you’d still be juggling five different maintenance buffs, which is a little more than I think is fun. Ultimately, I think that sort of gameplay ends up in one of two places. It either turns into a game of watching buffs rather than playing your character, or you get an addon or macro to remove the thought from the process. Neither of which are ideal for making a spec feel fun to play.

To add to that, we now have one of the more complex rotations in the game. Many specs lost spells and saw their rotation simplified. We lost only periphery spells; none of our core rotation spells were removed. And our rotation (including off-GCD AM) already involved more buttons than many DPS specs do:

Crusader Strike
Hammer of the Righteous
Judgment
Avenger’s Shield
Holy Wrath
Consecration
Hammer of Wrath
Execution Sentence or Lights Hammer or Holy Prism
Sacred Shield (possibly)
Shield of the Righteous
Word of Glory or Eternal Flame

Empowered Seals adds three more spells to that list. Even if you already had keybinds for them, we’re approaching “John F@#!ing Madden” territory. And that’s all assuming you’re not doing anything to contribute to raid utility. The developers have said they like leaving a few empty GCDs so players can make use of those utility spells. With Empowered Seals, you can kiss those empty GCDs good-bye.

To me, the whole idea just sort of feels awkward and not very fun, which is the same opinion I had of seal twisting in Wrath. Several people have pointed out that you can use a castsequence macro to do the seal cycling with one button, though that’s a gripe unto itself. When the best thing you can say about a talent is, “well, it’s not so bad when you create a macro to do most of the thinking for you,” I think you need to critically re-evaluate whether that talent is a good design.

There’s another problem with Empowered Seals: maintaining balance between the talents. Even without numbers, we can make a philosophical argument for why this will inevitably be a problem. Empowered Seals is situated in a tier with a passive option (Holy Shield). Let’s ignore Seraphim for now. By default, Empowered Seals has to be tuned to be noticeably better than Holy Shield. Why?

If the difference in steady-state performance between Empowered Seals and Holy Shield s tiny, why would you bother taking the active option? It would be both more reliable and easier to just take the equivalent passive option in that case. At least with Seraphim, you’re comparing an always-on Holy Shield to something that has an on/off cycle, and there can be pros and cons for each. But the buffs from Empowered Seals are essentially “always-on” buffs that cost 3 GCDs every 20 seconds, so you’re comparing two static effects, one of which takes more effort.

Likewise, if it takes an enormous amount of concentration to pull off Empowered Seals for a small gain, then why would you bother? At that point, it’s just shelved as a bad talent because it’s ineffective and few will bother to take it. We have historical precedence for this sort of thing – if you have a few hours (days?), go read Cynwise’s excellent set of articles on The Decline and Fall of Warlocks, particularly the third post in the series, which examines the same topic through a different lens. A class, spec, or talent that requires a a large amount more effort or involves a lot more complexity to achieve similar results tends to get marginalized and ignored.

So by design, for it to not be a “bad” talent, it has to provide some noticeable advantage over Holy Shield. And that’s really the issue, because that effort/performance breakpoint is different for each player. For a player going into Mythic progression as soon as it opens, that sort of complexity is something we generally just deal with, because we have the skill to perform the rotation even if we don’t like it. It really only becomes a choice for players that aren’t concerned about min/maxing their performance or don’t have the skill to pull it off.

From one perspective, that makes it perfect for a talent. Since the skill threshold varies from  player to player, making it a talent allows players to choose it based on whether they actually can pull it off or not. In practice though, it doesn’t work that way. We’ve seen it happen over and over again in WoW, and every time the “passive but weaker under ideal conditions” option was the one that everyone avoided. Even by players who really should have been taking it, because they couldn’t handle the complexity of the stronger option. The weaker option was perceived as only for “bad” players, and nobody wants to be bad! Furthermore, I really don’t want to see Holy Shield become the “bad players” option. It’s too iconic for that sort of fate.

They might be able to tune it so that the margin is “close enough” to make it a valid choice, but it’s unlikely for quite a few reasons. One, it’s a razor-thin margin they need to hit; two, the target will vary wildly with player skill; three, the target will drift with gear and content. It’s somewhat naive to believe that any set of three talents can be balanced perfectly just based on numbers. It’s far better if the tier gives three solid but slightly different options that shine in different situations.

For example, the choice between Divine Purpose, Holy Avenger, and Sanctified Wrath is pretty solid. Divine Purpose gave the highest average uptime on SotR and scaled best with gear, but wasn’t controllable. Holy Avenger gave lower uptime, but gave it to you in the form of an extra cooldown that you could control. Sanctified Wrath’s MoP incarnation was somewhat lacking – it would have been good if it was the high-DPS but middle-of-the-road option, but it ended up being an afterthought instead. It’s Warlords implementation looks pretty solid so far though – higher average Holy Power income and lots of extra damage through Holy Wrath. Each has a niche it can fill, and you may pick different ones for different encounters because each favors different encounter mechanics.

I think they *can* make the level-100 tier interesting in a similar fashion. But it will be interesting only if the three talents provide different strengths. For example, if they turned out something like this:

  • Holy Shield – Passive, always-on, best average survivability, average damage
  • Seraphim – Highest short-term survivability and burst damage (during buff), but slightly lower average survivability and damage (due to the fallow periods).
  • Empowered Seals – Most flexible. Lets you swap from high single-target damage mode (SoT) to high AoE damage mode (SoR) to high-survival mode (SoI), but you can’t have all at once. Average performance (i.e. cycling SoI while tanking and SoT while off-tanking) should be close to the baseline set by Holy Shield.

You can see the idea here.  Rather than picking the “winner” in that tier, you pick the talent that suits your purpose. Empowered Seals might be a 5% DPS increase with SoT up, but a ~5-10% sacrifice in survivability compared to Holy Shield. And vice versa if you’re running with SoI. Empowered Seals would give you the flexibility to adapt to the encounter rather than be stuck with the 30-second Seraphim cycle or the passive Holy Shield benefit.

But none of that works if Empowered Seals is effectively a passive effect that costs you 3 GCDs. If you have two passive choices, you pick the one that works best. If sims tell us that it’s worth spending those GCDs and losing Seal of Insight procs to keep up the buffs we get from Empowered Seals, then we take that over Holy Shield.

The way to make the talent interesting is to make our seals interesting, but I don’t think that seal twisting is the way to do it. Making seal twisting extremely powerful by making each seal grant a very powerful buff is putting lipstick on a pig – it’s covering what I feel is bad gameplay by just making the numbers big. I’d rather see Empowered Seals make seals in a substantial way that gives us interesting choices.

So rather than making Empowered Seals a rotational gimmick tied to Judgment, I’d rather see it actually empower our seals. Make SoT do more significant single-target damage. Make SoR do more significant AoE damage. Make Seal of Insight do more significant self-healing.

Better yet, make each of them into a mini cooldown. Maybe the talent gives you an “Empower Seals” spell that actually empowers whatever seal you have active to make it stronger. Using it doubles the effect of your seals for 20 seconds, with a 1 minute cooldown. Now, every minute you get to make an interesting decision.

Do I want single-target damage? Switch to Truth and pop Empower Seals for a burn phase. Do I want AoE damage for picking up and burning down some adds? Switch to Righteousness and pop Empower Seals for 20-seconds of AoE burst. Do I want more survivability? Use ES with SoI active and you have another mini cooldown. This fills a different niche than Seraphim in that you get to choose your benefit every minute, and to be balanced it would give you a bigger boost to that area than Seraphim does.

That’s interesting seal game play that actually involves making choices, rather than just mindlessly cycling through maintenance buffs.

Posted in Design, Tanking, Theck's Pounding Headaches, Theorycrafting | Tagged , , , , , , , , , , , , , , | 58 Comments

Simulationcraft Automation Tutorial – Part II

In the last post, we went over the interface of the Automation Tool and demonstrated how to use it to perform simple talent, glyph, and gear comparisons. Today we’re going to dive into the last comparison type: Rotations.

This comparison type is really the highlight of the tool. While the other comparison types are neat, this one is amazing. It’s an incredibly powerful way to test different rotations against one another, though of course, with that power comes some added complexity.

Interface

First, let’s take a look at how the interface changes when we choose “Rotation” from the Comparison Type drop-down box.

The Rotation Comparison Interface.

The first thing you’ll notice is that everything is enabled. This mode uses all of the text boxes. Though you’ll notice that the “Default Rotation” text box has been renamed “Actions Header,” and the previously-unused box in the lower left is now the “Actions Footer” box. We’ll talk about what those do shortly. The center box is now renamed the “Rotation Configurations” box, and the right-hand-side Rotation Abbreviations box is now editable.

I want to draw your attention to the text in the Rotation Configurations box though. It may look peculiar to you unless you’ve read some of my earlier MATLAB work, like the 5.4.2 Rotation Analysis. If you have read that post (or others like it), you might recognize these as rotation shorthands:

Shorthand configurations.

Shorthand rotation configurations.

The first one is equivalent to a rotation where your priority order is Crusader Strike, then Judgment, then Avenger’s Shield. When we hit Import!, it translates this to an actor with that action priority list:

The generated actor for CS>J>AS

The generated actor for CS>J>AS

How does it know that CS means crusader_strike and so on? That’s what the Rotation Abbreviations sidebar is for. So let’s look at that in more depth.

Abilities

The Rotation Abbreviations sidebar defines all of the shorthands and their longhand equivalents. It’s essentially the dictionary the tool uses to try and make sense of the input you give it. It’s divided into sections by headings marked with six colons, the first of which is “:::Abilities, Buffs, Glyphs, and Talents:::” as shown below.

The shorthand definitions are in the Rotation Abbreviations sidebar.

The Abilities section of the Rotation Abbreviations sidebar.

As you can see, we’ve defined shorthands for a bunch of different abilities using the syntax:

shorthand=longhand

When you hit Import! the tool’s shorthand decoder takes the shorthand you give it and checks each ability against the shorthand side of each line of this section. If it finds one, it replaces that text with the longhand version. So for example, it searches for”CS” in this section, finds the “CS=crusader_strike” entry, and then creates an action priority list line for crusader_strike. As you can see in the example above, we use the greater than sign (>) in the shorthand to indicate a new line on the action priority list. So “CS>J>AS” becomes a three-line action priority list with crusader_strike, judgment, and avengers_shield.

This section also contains the definitions for particular buffs, glyphs, or talents. We’ll see how they get used a little later on, for now don’t worry about them.

Note that this text box is editable, meaning you can define your own shorthands if you want to. If you really want to use “Co” instead of “Cons” to represent consecration, you can change it! Likewise, if you want to add abilities (or buffs, glyphs, or talents) that aren’t already on the list, you can add new definitions by typing them into this section. Some specs already have a bunch of built-in shorthands written by SimC devs for that class. If your spec doesn’t, see the end of this post for information on how you can submit a list.

The shorthand syntax is much more powerful than just allowing you to define strings of abilities though. Most action priority lists use conditionals, so the tool has a way to let you do that in shorthand as well.

Options

The second actor uses the shorthand “CS>J>AS+GC” to demonstrate the use of options. If you look further down the Rotation Abbreviations sidebar, you’ll see a section labeled “Options”:

The Options section of the sidebar.

On this list you can see that we’ve defined an option “GC=buff.grand_crusader.react.” The tool uses the plus sign (+) as the indicator that you’re trying to specify an option, which is just a conditional for the use of that ability. The syntax “Ability+Option” translates into “ability,if=option” during the decoding process. Thus, “AS+GC” translates to “avengers_shield,if=buff.grand_crusader.react.”

The final example just shows that you can combine different options with logical operators, just like you can with conditionals in action priority lists. The entry

AS+GC&(DP|!FW)

translates to

actions+=/avengers_shield,if=buff.grand_crusader.react&(buff.divine_purpose.react|!glyph.final_wrath.enabled&target.health.pct<=20)

Obviously this is a nonsense conditional, it’s just there to demonstrate the flexibility you have with the system. With appropriate ability and option definitions, you can create almost any action priority list you can dream of here. One word of warning, however: note that while you can use logical operators like &|+-*/<=(), you cannot use >, because the decoder thinks that’s you telling it you’re starting a new action priority list line.

One way around that limitation is to use the pound sign (#), which is a special character definition in options. For example, the option

HP#=holy_power>=#

lets you specify an option like “HP3″ that will translate to “holy_power>=3″. The # sign will match any number including decimals, so it would properly translate HP3.2 into “holy_power>=3.2″. This should let you get around the limitation of not being able to use the greater than symbol in a logical expression.

There’s another special sequence for options that can be useful when an option depends on the ability it’s modifying. In an option, the text “$ability” will be replaced with the name of the current ability. So for example, since we have the definition “AC#=action.$ability.charges>=#”, a line like “AS+AC1″ would translate to

avengers_shield,if=action.avengers_shield.charges>=1.

Obviously this is nonsense since Avenger’s Shield doesn’t have charges, but this could be useful for abilities that do, like Shield Block.

Operators

The third section of the Rotation Abbreviations sidebar is called “Operators,” and it defines abbreviations that allow for more flexible creation of operators. An operator requires an additional abbreviation which it acts upon, called the “operand.” The syntax for this is “Operand.Operator”, like so:

GC.BA

When the decoder encounters the syntax “X.Y”, it checks for X in the list of Ability shorthands and checks for Y in the list of Operator shorthands. If it finds both, it will replace “X.Y” with the operator longhand, and then look for the text “$operand” in the result, replacing any instances of that text with the longhand form of the ability.

The list of operators.

The list of operators.

In our example, the ability list contains “GC=grand_crusader” and the operator list has “BA=buff.$operand.react.” So the decoder will first replace “GC.BA” with “buff.$operand.react”, and then replace the “$operand” in that with “grand_crusader.” The final result is

buff.grand_crusader.react.

You might wonder why we would want to use an operator when we can just define an option to handle the entire conditional expression. The answer is primarily one of flexibility. The “.BA” operator lets us test for a buff with any abbreviation we’ve already defined in the Abilities section. Likewise, the “.CD” operator, we can check the cooldown of any of those abilities. By using  operators, we don’t need to define a new option for each cooldown, buff, or debuff that we want to check for.

Operator/operand pairs like “GC.BA” or “CS.CD” are just special types of options, so just like other options they can be combined using logical operations. The decoder will properly parse “AS+GC.BA&CS.CD0.5&E” as

avengers_shield,if=buff.grand_crusader.react&cooldown.crusader_strike.remains>=0.5&target.health.pct<=20

Just as with abilities and options, you can define your own operators by adding them to the appropriate section of the sidebar. There are a few things to keep in mind when defining your own shorthands in any of the three sections.

  • Shorthands are all case-insensitive, so if you define “AS=avengers_shield” both “AS” and “as” will be matched and converted by the decoder. This means you can’t use “AS,” “As,” and “as” to stand for different abilities.
  • Each section of the sidebar is independent. So you can define
    • “AS=avengers_shield” in the “:::Abilities:::” section,
    • “AS=cooldown.avengers_shield.remains” in the “:::Options:::” section, and
    • “AS=action.$operand.charges” in the “:::Operators:::” section

    and the decoder will be smart enough to use the appropriate one based on syntax. So “AS+AS&AS.AS” would parse just fine.

  • The Rotation Abbreviations sidebar is saved when you exit the program, so if you add shorthands they will be there when you start the program up again. However, the sidebar is completely reset every time you choose a new class or spec from the drop down boxes, and your changes will be discarded. This is done partly because it’s far easier than saving the text of the sidebar separately for each class, and partly to make it easy for me to add abbreviations in the future. If there’s a shorthand abbreviation you feel should be added to a spec’s defaults, please contact me (here or via an issue ticket) and I’ll add it to the list.
  • The one thing you should absolutely not do is change the section labels in the sidebar. The code uses the “:::stuff:::” pattern to separate the sidebar into three separate tables of shorthand/longhand pairs, which it then uses to perform the replacement. If you delete one of the colons, the program will probably crash when you hit the Import! button.

Now that we have all the shorthand pieces, let’s see how we use the tool to perform a simple rotation comparison.

Using The Rotation Comparison Tool

For our first foray into rotation comparisons, we’re going to stick to something simple. Let’s test the ideal priority of our holy power generators: CS, J, and AS+GC. With only three abilities, there are six different permutations we could consider:

 

Our first rotation comparison.

Our first rotation comparison.

When we hit Import!, we get a list of six actors, each of which has the appropriate action priority list entries.

The generated profile.

The generated profile.

You’ll note that the rotation comparison automatically gives each of these actors a name based on the shorthand you provide. You can override this automatic naming by providing your own as an option, just as we did in the earlier comparisons. For example, changing the first line to “CS>J>AS+GC name=Alice” will add a “name=Alice” line to the end of the profile which will overwrite the automatically-generated name.

If we run the simulation, we again get a report like before, showing how each actor performed:

Report for Rotation Comparison #1

The resulting report.

The resulting rotation comparison report.

Since we’re only running this with 1000 iterations, the error is about 10 DPS, so the rankings aren’t all that conclusive. In fact, there’s a much more glaring error in these results that would call their validity in question, which we’ll discuss in more detail shortly. However, it’s clear from this example how you might go about comparing different rotations. And note that just as we did with the earlier comparisons, we can tweak the talents, glyphs, or gear of any actor by adding commands after the shorthand, like so:

CS>J>AS+GC name=Alice talents=1111111 glyphs=alabaster_shield
CS>AS+GC>J name=Bob talents=2222222 glyphs=word_of_glory

But wait, there’s more!

Actions Header and Footer

Let’s say we want to apply some actions to all actors. For example, if you look at that simulation you might have noticed the glaring error I mentioned earlier: none of the actors ever cast Judgment! In fact, they can’t, because none of them have a seal active, because we never told them to cast a seal. Normally that’s done in the precombat action list, which we never provided. Likewise, none of them actually use active mitigation abilities, so the TMI results are essentially random and don’t reflect the holy power generation of each action list.

We could define a shorthand for SotR and put it in every one of the action lists, like “SotR>CS>J>AS+GC,” but that would be a bit tedious and make each configuration harder to read. Doubly so if we added shorthands and entries for Word of Glory and Eternal Flame. And it still doesn’t solve our seal problem.

This is where the Action Header and Footer text boxes come to the rescue. They act as bookends for each rotation configuration, allowing you to specify some actions that apply to every actor. So let’s edit the Action Header and Footer boxes and see how this works.

Editing the Action Header and Footer

Editing the Action Header and Footer

The tool will now sandwich each configuration between the text in these two boxes. When we hit Import!, we now have actors which will cast Seal of Insight before combat and use Shield of the Righteous, Holy Wrath, and Consecration:

The profile generated after adding text to the Actions Header and Footer boxes.

The profile generated after adding text to the Actions Header and Footer boxes.

Running this simulation gives us a little better differentiation between the different holy power generator priorities:

Results for Rotation Comparison #2

The results of our revised simulation.

The results of our revised simulation.

Another good example is adding an “actions+=/sacred_shield” line to the end of the Actions Footer to refresh Sacred Shield any time you have an empty GCD. I’m sure you can imagine other uses as well. Note that since the tool is just splicing together text, you’re not limited to putting just actions in the Actions Header or Footer. Any valid SimC syntax that you want to add to the end of each actor would work, such as “position=back” or “tmi_window=5.” In fact, you could add those to the Default Gear text box to achieve the same effect.

Rotation Syntax: Part Deux

What if I want to add something in-between two shorthands? As a (somewhat contrived) example, what if I want to try all of the permutations of CS>J>(other stuff)>AS? As it turns out, you can do that several different ways.

If you prefer sticking with shorthand, you could obviously define a shorthand for (other stuff). To make this example more concrete, let’s say that “other stuff” is our level 90 talents, e.g. ES>LH>HPr, or /execution_sentence/lights_hammer/holy_prism in longhand. We could define

X=execution_sentence/lights_hammer/holy_prism

and then define rotations CS>J>X>AS, CS>AS>X>J, and so on to create our permutations.

If the list of “other stuff” is so long that this would be unwieldy, we could make use of another input mode of the Rotation Configurations text box. You see, the text box can also handle full, text-based action lists that span multiple lines. However, in this input mode, we have to separate each actor with a blank line, much like we did in the gear comparison. That might look something like this:

A longhand action list declaration.

A longhand action list declaration.

When we hit the Import! button, this text is faithfully reproduced between our Actions Header and Footer. The tool is smart enough to (a) recognize that we’re using a blank space to separate actors, and (b) only try to decode shorthand lines, which are lines containing one or more “>” symbols that do not start with the text “actions.” In fact, we can even mix full action declarations and shorthands, like so:

A mixture of longhand and shorthand definitions.

A mixture of longhand and shorthand definitions.

You can hit Import! to see that the decoder translates the shorthand lines into longhand for you, and places them in the appropriate order with all of the rest of the text for that actor. The only limitation is that it will not try to decode single-action shorthands, so “CS” won’t be translated, because the decoder treats any line that doesn’t contain a “>” to be plain text. This is why I didn’t use “AS+GC” in Alice’s configuration above. If you need to, you can get around this by “cheating” a bit and chaining the ability together twice. For example, “CS>CS” would be decoded into two crusader_strike lines. The second one would just be redundant, it wouldn’t change any of the actor’s behavior.

If your “other stuff” was very long, you could put it in a simple text file (e.g. middle_of_rotation.simc) and use that file name in place of the explicit action description. In other words, you’d replace actions+=/execution_sentence/lights_hammer/holy_prism with middle_of_rotation.simc. And you could even define an abbreviation “X=middle_of_rotation.simc” on the sidebar if you wanted, so that you could use it in shorthands. You really have an incredible amount of flexibility in how you define rotations with this tool.

There’s one major limitation that I want to mention though. If you use a new blank line to separate actors, you need to be consistent and do it for every actor. In other words, the input shown below will not work – or rather, it will translate to two different actors rather than three!

Mixing single-line and multiple-line configurations. This only produces two actors, the second one having CS>J>AS>CS>AS>J as its rotation. In other words, don’t do this!

Final Comments

By the end of this tutorial, you should be able to use the Automation Tool to compare all sorts of different things. The goal was to make the tool as useful as possible while still keeping it simple to use. Any theorycrafter that’s familiar with basic SimC syntax should be able to fire up the GUI and use the tool without having to mess around with the command line or batch processing. I’ll be making heavy use of the tool myself in the coming months as I run (and post) simulations investigating our optimal play style in Warlords of Draenor.

If you have a question about the tool or a suggestion for improvement, please don’t hesitate to contact me. Leaving a comment here on the blog is fine, or you can catch me in the #simulationcraft irc channel on irc.stratics.com. If you have a long list of shorthand abbreviations to add to the sidebar, you should contact me rather than posting the entire list here, as I have a google doc set up for that which will make it easier to copy/paste your shorthands into the code.

There are several things that aren’t well-supported, and may not ever be. The most important is probably the use of multiple action lists and the /run_action_list command. A lot of profiles use this to separate out single-target and multiple-target rotations, or make more complicated rotation paths a little clearer to read. There’s no inherent syntax for defining separate action lists in the shorthand code, though of course you could write them out in full or use .simc files and cleverly stitch them together.

That said, this tool was never intended for that type of fine-detail tuning. It uses the same philosophy as our TC101 experimental tests – simplify down to as few variables as possible. So for example, you might use this tool to test different single-target rotations (with one boss), and then use those results to determine the ideal single-target action priority list. You could then add a second boss in the Footer and create a bunch of configurations to test 2-target action lists, and so on. Once you’ve determined each of those independently, you would create a master profile that called the appropriate action list based on the number of targets. By breaking it down into several smaller problems, this tool can still save you plenty of time and effort compared to running sims by hand.

Posted in Simcraft, Simulation, Tanking, Theck's Pounding Headaches, Theorycrafting | Tagged , , , , , , , , , , , | 5 Comments

Simulationcraft Automation Tutorial – Part I

If you follow me on twitter, you know that I’ve been intermittently commenting on the new Automation Tool that I’ve been building for Simulationcraft. I’m happy to say that the tool is more or less finished at this point, complete with documentation!

For those that haven’t heard about this project before, the Automation Tool allows you to quickly generate profiles to compare different talent, glyph, gear, or rotation configurations. For example, if you want to compare 10 different talent configurations, the tool will generate a profile containing 10 different players (“actors”), each of which is identical except for their talents. You can then run that simulation and look at the report to see which one of the actors performed the best, and by how much.

The point of this post is to provide a tutorial that supplements the documentation. I’m going to give you a step-by-step guide that shows how to use the tool to perform different types of comparisons. And hopefully, show some of the tool’s impressive feature set in the process.

Interface

To start using the tool, fire up Simulationcraft (version 602-1 or later, a beta of which you can download here), click on the “Import” tab, and then choose the “Automation” sub-tab. You should be looking at a screen that looks like this:

Simulationcraft’s Automation Tab – First Look

Let’s walk through the interface quickly. At the top left, we have a drop-down box that lets us choose a “Comparison Type” (currently set to “None”), and to the right there is a help text area telling us that we need to choose a comparison type to get started.

In the left column, we have a bunch of defaults. We have drop-down boxes to choose Class, Spec, Race, and Level, and some text boxes to define default talents, glyphs, gear, and rotation. The “Default Talents” box is filled in with a default “0000000” (meaning no talents), and the “Default Glyphs” box has some dummy glyphs for protection paladins. “Default Gear” has some placeholder gear, and “Default Rotations” is empty. There’s also a greyed-out “Unused” box at the bottom.

In the center column, we have another greyed-out “Unused” box, and a “Footer” text box. Finally, the right column has a greyed-out “Rotation Abbreviations” box  with some placeholder text.

We can ignore all of the greyed-out boxes for now. Once we choose a comparison type, some of these boxes will become active and their titles will change to describe what they do.

Since this is a paladin blog, let’s set our default class and spec. We’ll click on the Class drop-down box and choose “Paladin,” and then choose “Protection” from the Spec drop-down. We’ll leave the Race and Level as “Blood Elf” and “100” respectively. You may have noticed that the Rotation Abbreviations text box changed when you chose a class and spec – we can ignore that until we get to the section on rotation comparisons.

We also need to specify some default talents, glyphs, and gear. For now, we’ll leave the talents and glyphs texts boxes alone (they already have defaults), but the gear box needs some attention. We’ll take the gear a premade level 100 character starts with and put it in this box (you can automatically generate this using the Simulationcraft addon).

The left column should now look something like this:

Defining some defaults.

Defining some defaults.

 

For now we’ll leave the Default Rotation empty. As it turns out, if we don’t specify a rotation, the sim is smart enough to use the class module’s default rotation, just like it does when you import your character from the armory.

Now that we’ve gotten some defaults put in, let’s set up our first comparison.

Talent Comparisons

The first choice in the Comparison Type drop-down box is “Talents.” When we make that selection, the large text box in the center column becomes enabled and the name changes to “Talent Configurations.” In addition, the text in the box changes to some example talent configurations: “0000000,” “1111111,” and “2222222.” The other change is that the Default Talents text box becomes greyed out, indicating it’s no longer being used. Finally, the help text area gives us some instructions on how to set up a talent comparison.

Selecting the "Talents" comparison type modifies the interface.

Selecting the “Talents” comparison type modifies the interface.

Now let’s talk about exactly what this all means. Because we’ve chosen the “Talents” comparison type, we’ve told the tool that we want to compare several different talent configurations. It’s responded by greying out the Default Talents box and giving us a new place to list the talent configurations we want to try.

Each talent configuration is specified as a 7-digit number, with each digit corresponding to a talent tier. The first number is our level 15 talent, the second number is our level 30 talent, and so on. A zero means we haven’t chosen a talent, and a one, two, or three indicates we’ve chosen the talent in the first, second, or third column. So “0000000” is a character that has no talents, “1111111” is a character that’s taken all of the talents in the first column, and so on. Each new talent configuration is specified on a new line, with no blank lines between them (this is important).

When we hit the Import! button in the bottom right-hand corner, the tool will generate a profile containing three level 100 Blood Elf protection paladins. Each paladin will have the same glyphs and gear, but the first one will have “talents=0000000,” the second will have “talents=1111111,” and the third will have “talents=2222222.” Try this yourself, it should automatically swap you to the Simulate tab and look like this:

The profile generated by our talent automation.

The profile generated by our talent automation.

As you see, the tool conveniently gives us simple names for our paladins corresponding to their talent selections, and each one is the same except for the “talents=XXXXXXX” line.

So that’s the basic function of this tool. It takes the text you supply in each of the boxes and Frankensteins it together to create multiple actors that you can simulate together. Before we do that, though, let’s go back to the Automation tab and make these paladins a little more unique.

Since the tool is simply combining bits of text, it’s very flexible. It will let us specify additional text that is specific to each actor. For example, let’s change the text in the Talent Configurations box to this:

We can modify the configurations by specifying additional options for each actor.

We can modify the configurations by specifying additional options for each actor.

Again, each line is specifying a different actor. But now we have some extra options, like a name, for each actor. Each new option is separated by a single space, so we can string options together like we have for Bob and Eve.

The tool is smart enough to put these extra options at the end of the actor’s profile, so the “glyphs=alabaster_shield” command we’ve added to Bob’s profile will overwrite the default glyphs. Likewise, Eve will be sporting a new phony_helm with 100 stamina and will be standing behind the boss rather than in front of him. Also note that for Eve I’ve included “talents=” in the talent definition; the sim is smart enough to look for that and adjust its output appropriately.

If you hit “Import!” and scroll down to the end, it should look like this:

Our profile after changing the text in the Talent Configurations box.

As you can see, the “name=Bob” and “glyphs=alabaster_shield” are at the end of the third profile, and all of Eve’s options are at the end of her profile.

Since the Automation Tool puts the profile directly on the Simulation tab, it works just like a profile you import from the armory or another source. The simulation will use whatever settings you’ve chosen on the Options tab, including number of iterations, boss type, fight style, stat scaling calculation settings, and so on.

Here’s the report that Simulationcraft generates when we hit the Simulate! button:
Report for Talent Simulation

This is a raid simulation, so at the very top it shows a summary of all actors, showing DPS, HPS+APS, DTPS, and TMI charts:

After simulating, we get a raid report detailing how well each actor performed.

After simulating, we get a raid report detailing how well each actor performed.

We can quickly see here that Eve’s configuration does the most DPS and takes the least damage, while Alice has the highest HPS and gets the best TMI score. The report also has detailed results for each actor that we can scrutinize if we want to figure out why a particular actor is performing better than another.

This example was a bit contrived due to the talent choices, but you should be able to see how you  would use this tool to compare individual talents. Comparing one actor with “talents=0000001″ to another with “talents=0000002″ and a third with “talents=0000003″ would let you compare the spec’s level 100 talents with one another in the absence of other talents.

However, there are some warnings to keep in mind here. This sim uses the default action priority list, so if the APL isn’t properly optimized for a given talent the results will reflect that. In this example, the APL hasn’t been optimized properly for L100 talents, so even if we had looked solely at those talents we wouldn’t want to draw any conclusions about their relative strength from these results. It’s also worth remembering that talents can interact; the value of Empowered Seals could be different if you’ve chosen Sacred Shield than if you’ve chosen Eternal Flame, since Sacred Shield requires GCDs and Eternal Flame doesn’t. And we’ve also added some variables by tweaking certain players’ glyphs and gear rather than using the defaults.

In general, it’s good to keep that issue in mind when analyzing the results of this sort of simulation. There are plenty of variables involved, and you should consider all of them before drawing conclusions. As we’ve discussed in earlier TC101 articles, trying to control as many variables as possible leads to better results and an easier analysis. The tool is designed to do that as much as possible for you by setting default glyphs, gear, and rotations, but in the interest of flexibility it gives you ways to circumvent those controls.

Glyph Comparisons

If we go back to the Automation tab and switch the Comparison Type to “Glyphs,” the Default Talents text box becomes active again and the Default Glyphs box becomes greyed out. The “Talent Configurations” box is renamed “Glyph Configurations” and gets a new set of placeholder text specifying two different glyph configurations. The help text area has also changed to provide instructions for a glyph comparison.

The interface changes slightly when choosing a Glyphs comparison type.

The interface changes slightly when choosing a Glyphs comparison type.

As you might guess from the screenshot, the syntax for a glyph comparison is very similar to a talent comparison. Each set of glyphs is defined exactly as they are in any other profile, as a tokenized (i.e. lowercase, spaces replaced with underscores, all other symbols excluded) list separated by forward slashes. Each new line is a new configuration, as before. In our example above, one actor has Alabaster Shield and Focused Shield, while the second has Final Wrath and Word of Glory. We could add more actors if we wanted by adding more lines to the central text box.

For example, let’s add a third configuration that uses only Alabaster Shield – then we’ll be able to compare the first and third configuration to see how much DPS the Focused Shield glyph provides. We can also specify options like we did in the talent comparison, and to demonstrate that we’ll name this new configuration Al.

Hello Al.

You have invited Al to the party.

At this point, I also want to talk about the Footer text box at the bottom. This box gets added to the very end of the profile, and only once. It’s there so you can specify global options that you wouldn’t want or need to repeat once for each actor. So for example, we could type “optimal_raid=0″ in this box to turn off raid buffs (if we were too lazy to do that on the Options tab), or use this area to specify a custom boss or bosses. To illustrate that, let’s turn off raid buffs and specify a pair of bosses, like this:

Using the Footer text area to turn off raid buffs and spawn a pair of bosses.

Using the Footer text area to turn off raid buffs and spawn a pair of bosses.

If we hit Import!, we see that we now have three paladins with different glyph configurations, and our Footer text has been faithfully reproduced at the end of the profile. Like before, the tool is stitching together the text in each of the boxes to create the profile.

The generated profile for a glyph comparison.

The generated profile for a glyph comparison.

Unlike the talent sim, this gives each paladin a generic “G_#” name rather than trying to come up with a descriptive name based on the talent configuration. So the ability to rename each actor using additional options, like we did with Al, is pretty helpful here.

Again, we can hit Simulate and generate a report, linked below.
Report for Glyph Comparison

Raid report for a glyph comparison.

Raid report for a glyph comparison.

Looks like Al did the most damage here. Remember that he’s using Alabaster Shield, while paladin G_0 is using both Alabaster Shield and Focused Shield. And while Focused Shield would be a DPS increase against a single target, here we have three targets, so it’s a DPS loss.

Wait, three targets? Didn’t we specify only two Fluffy Pillow bosses? What happened?

If you look at the report, you’ll see both Fluffy Pillows and a TMI_Standard_Boss_T17N:

Oops, a T17N boss snuck into this sim.

Oops, a T17N boss snuck into this sim.

That happened because I had the “TMI Standard Boss” option on the Options->Globals tab set to “T17N.” Remember that since we’re using the Simulate tab of the GUI, the sim will use all of the options you’ve specified, including that boss option. If we want to just use the bosses we have defined in the Footer section, we need to change the TMI Standard Boss drop-down to the “custom” setting. If you do that and run the simulation again, you’ll get a report with just our two Fluffy Pillow bosses, and the DPS results of G_0 and Al will be closer together.

There’s not a lot more to say about glyph comparisons that I haven’t already said about talent comparisons. The two are pretty similar from the tool’s point of view. You can modify the talents of a particular actor by adding ” talents=xxxxxxx” as an option after their glyphs are specified, just like you could modify glyphs in the talent comparison. If you do use that flexibility, just be aware of it when you’re analyzing your results.

Before we move on to gear comparisons, I want you to go to the Comparison Type drop down and switch back to “Talents.” You’ll notice that the central text box reverts to the input we used for the talent comparison. This central text box stores its content separately for each configuration type, so you don’t have to worry about losing your old inputs when you swap between one comparison type and another. It should also save this text (and most of the other text boxes, in fact) in-between sessions, just like most of the other options in SimC do.

Gear Comparisons

Now I want you to change the Comparison Type to “Gear.” As with the other settings, the help text area updates to describe a gear comparison, and the central text box is renamed. This time it’s set to “Gear Configurations,” and some new example text appears in the center. The Default Glyphs text box is re-enabled and the Default Gear box is disabled.

The Gear Comparison interface.

The Gear Comparison interface.

Since defining an entire gear set on a single line would be a bit cumbersome, the gear comparison uses a slightly different syntax. Instead of putting each configuration on a new line, it allows you to use multiple lines for a single configuration to make it easier to see what gear you’re defining. Each configuration is now separated by a blank line. So the text we’re starting with here defines two gear configurations, each only containing a head and a neck.

If we wanted to, we could flesh these configurations out by adding shoulders, chest, etc. until each was a full gear set. We could also add more configurations as long as each new configuration was separated by a blank line. And we could add options (like a name) to each configuration by adding lines to that configuration. For example, here’s what it looks like if we add a third actor named “premade” that uses our premade character’s full gear set:

Adding a third gear set, with a name.

Adding a third gear set, with a name.

That said, you can see how this would get unwieldy fast. If we wanted to define 10 gear sets, all of which used the default premade gear but had a slightly different weapon, we’d be doing a lot of copy/pasting. Luckily, there’s a slightly easier way.

I’m going to take our premade gear and save it as a simple text file, like this one:
base_gear.simc

I’m going to put that file in the “profiles” directory of my simulationcraft folder, like so:

Adding a simc file to the profiles directory.

Adding a simc file to the profiles directory.

Now I’m going to go back to the Automation tab and create three actors, each of which uses a different weapon. I’ll use this file as the base gear set by calling it directly, and then simply add a new weapon for each set on a separate line. The result looks like this:

Our modified gear comparison.

Our modified gear comparison.

And when we hit Import!, this is what we get:

The generated profile.

The generated profile.

Again, you’ll notice that it gives each actor a default name like “G_1,” which is why I’m naming each gear set something descriptive. Since Simulationcraft’s input is all text-based, you can actually tell it to read in entire text files on the Simulate tab like we’re doing here. It will check the profiles folder, find the base_gear.simc file, and read that file in line by line as if we had typed the entire gear set right there in the profile. Very convenient!

Keep in mind that we had to put the “main_hand=” line after the line containing “base_gear.simc” for this to work. base_gear.simc has its own definition of a main hand weapon, so if we want our new weapon to override it, it has to come second. This works just like a variable in a programming language – if I define “x=1″ and then in a later line of code define “x=2″, the second definition will overwrite the first.

If we hit Simulate!, we get a report for the three actors as usual. Note that I’ve deleted the text in the Footer section and set the TMI Standard Boss drop-down back to “T17N” here.

Report for Gear Comparison

The results of our gear comparison.

The results of our gear comparison.

Each of the weapons has slightly different secondary stats, so they’ll all produce slightly different DPS, HPS, and DTPS numbers. TMI is largely unaffected by such a small change in the gear set.

It shouldn’t be hard to imagine uses for this simulation mode. As in this example, we could use it to test out all of the weapons within a tier to see which gives the highest total DPS. We could also define several different complete gear sets to compare combinations of tier pieces and off-set pieces, different enchanting and gemming strategies, and so on.

Also note that while I didn’t show it, you can add comments to the text in the Gear Configurations box as well. You can add a line like “#config one” anywhere in the configuration and it will show up in the generated profile.

Next Time – Rotations

As it turns out the final Comparison Type, which lets you compare rotations, is far more complex than the three we’ve demonstrated today. So much more complicated that it really deserved its own blog post. So stay tuned for next time, when we go over the most powerful part of the tool: the Rotation Comparison.

 

Posted in Simcraft, Simulation, Tanking, Theck's Pounding Headaches, Theorycrafting | Tagged , , , , , , , , , , , | 10 Comments

TC401: Avoidance Diminishing Returns in WoD

Avoidance and diminishing returns are topics we’ve spent a fair amount of time discussing in the past. In 2012, I wrote a series of three blog posts discussing avoidance diminishing returns in Mists of Pandaria, chronicling the background of the formulas the community uses, numerically fitting data sets to determine the diminishing returns coefficients, and eventually discussing what those equations mean for gearing. We used similar fitting techniques to find values for druids and monks.

Later that year, we used a more precise data set collected with the Statslog addon to fine-tune the values for paladins and uncover some wonky rounding in the block calculation. And in 2013, we performed an exhaustive analysis including lots of pretty surface plots to get accurate values for all of the tank specs.

It seemed at first like Warlords of Draenor was going to be an easy expansion in that regard. Celestalon has outright given us the strength-to-parry and agility-to-dodge coefficients and the diminishing returns coefficients for each class. While the provided coefficients are in the format of their internal diminishing returns formula, which is a little different from the version the community usually uses, translating between the two is not difficult.

And yet….

First, some quick tests uncovered a bug in the calculation of base parry, which Blizzard subsequently fixed. And in the past two weeks, I’ve discovered another oddity, which I’ve detailed below.

As usual with TC101 articles, I’ll give the results up front for reference (and those that don’t want to scroll to the bottom to get them), and then start talking about how we performed the tests.

What’s Changed

The diminishing returns (DR) formulas for WoD have changed very little from the Mists versions. In fact, the most significant changes are to the contributions that are not affected by DR.

In Mists, base strength and agility add an amount of parry or dodge, respectively, that is unaffected by DR. In Warlords, that contribution has changed in the following ways:

  • Strength no longer grants parry for druids and monks, and agility no longer grants dodge for paladins, warriors, and death knights.
  • They have subtracted out the “non-DR” parry and dodge contributions from base strength and agility, such that base parry and dodge should be exactly 3.00% (the default for all players and NPCs) plus any race- or spec-based passives. For example, a night elf would have 5.00% base dodge thanks to Quickness, as would a paladin thanks to Sanctuary. However… there are a few quirks.
  • They have subtracted out the contribution due to the class portion of base strength, but not the portion due to the racial strength modifier. That racial strength modifier’s contribution is also not affected by DR. So a gnome warrior (-5 racial strength modifier) would have 2.97% base parry (-0.0283% due to the -5 strength racial modifier). The same is true for the racial agility modifier’s contribution to dodge.
  • Finally, there’s probably a small error in the strength subtraction, because all strength tanks (regardless of race) are getting a “phantom” 0.0004178% parry, or about 0.0739 strength worth of parry, that isn’t affected by diminishing returns.

The last quirk is the interesting one, because it’s a bug. Not a game-breaking bug, mind you; we’re talking about about 0.0004% parry. For most people, they’ll never even be perceptible.

Nonetheless, it’s worth noting because it’s just barely large enough that it could cause a slight discrepancy between calculated and character sheet parry values if not accounted for. For example, if your theorycrafted parry is 21.0199%, but the actual value is 21.0203%, your character sheet will read 21.02% instead of 21.01% (as we mentioned last post, character sheet values are almost always floored, not rounded).

I’ve informed Blizzard of the bug, but I’ve been told that given their programmer’s workload and the tiny magnitude of the effect, we should not expect to see it fixed.

Warlords of Draenor Diminishing Returns Formulas

Since Blizzard has kindly provided us with the diminishing returns coefficients, I’ve chosen to use their formula rather than the community’s traditional one. In the next section I’ll show how to convert the coefficients provided by Blizzard into the conventional ones you might be familiar with.

In the following equations, $\text{ParryFactor}$, $\text{DodgeFactor}$, $\text{BlockFactor}$, $\text{VerticalStretch}$, and $\text{HorizontalShift}$ are the class-specific Blizzard DR coefficients given in the table at the end of this section. $Q_S$ and $Q_A$ are the level-dependent and class-specific strength-to-parry and agility-to-dodge conversion factors. $\text{classBaseStr}$ and $\text{classBaseAgi}$ are class-dependent base stat values, and $\text{raceStrMod}$ and $\text{raceAgiMod}$ are the racial stat modifiers. $\text{Strength}$, $\text{Agility}$, $\text{Mastery}$, $\text{parryRating}$, and $\text{dodgeRating}$ are your character sheet values for each of these stats.

Note that I’m giving these equations in percent form. In other words, a $\text{bonusParry}$ of 15.3% is 15.3 in the equation. If using decimal form (e.g. $\text{bonusParry}=0.153$) there is an extra factor of 100 in the term with $\text{VerticalStretch}$. The easiest way to accommodate this is to just multiply $\text{VerticalStretch}$ by 100.

 

The diminishing returns equations for parry are:

$\text{baseParry} = 3.00 + \left ( \text{raceStrMod}+ 0.0739 \right )\times Q_S$

$\text{bonusParry} = \left ( \text{Strength} – \text{classBaseStr} – \text{raceStrMod} \right ) \times Q_S + \text{parryRating} / 162$

$\begin{align} \text{totalParry} & = \text{baseParry}  \\ &+ \text{bonusParry}/\left ( \text{bonusParry} \times \text{ParryFactor}\times \text{VerticalStretch} + \text{HorizontalShift} \right ) \end{align}$

The diminishing returns equations for dodge are:

$\text{baseDodge} = 3.00 + \text{raceAgiMod}\times Q_A + \text{racial/spec passives}.$

$\text{bonusDodge} = \left ( \text{Agility} – \text{classBaseAgi} – \text{raceAgiMod} \right ) \times Q_A + \text{dodgeRating} / 162$

$\begin{align} \text{totalDodge} &= \text{baseDodge} \\ &+ \text{bonusDodge}/\left ( \text{bonusDodge}\times \text{DodgeFactor}\times \text{VerticalStretch}+\text{HorizontalShift} \right ) \end{align}$

The diminishing returns equations for block are:

$\text{baseBlock} = 3.00 + \text{spec passives}.$

$\text{bonusBlock} = \text{round}[~\text{Mastery}\times Q_M \times 128 ~]/128$

$\begin{align} \text{totalBlock} &= \text{baseBlock} \\ &+ \text{bonusBlock}/\left ( \text{bonusBlock}\times \text{BlockFactor}\times \text{VerticalStretch}+\text{HorizontalShift} \right ) \end{align}$

 

The tables below summarize the constants in these formulas for different tank specs.

Constants By Class
Constant Death Knight Druid Monk Paladin Warrior
ParryFactor 0.634 1 1.659 0.634 0.634
DodgeFactor 1.659 1 0.3 2.259 1.659
BlockFactor 1 1 1 1 1
VerticalStretch 0.00665 0.00665 0.00665 0.00665 0.00665
HorizontalShift 0.956 1.222 1.422 0.886 0.956
classBaseStr 1455 626 626 1455 1455
classBaseAgi 1071 1284 1284 455 889

$Q_S = \begin{cases} 1/176.3760684 & \text{ Death Knight, Paladin, Warrior} \\ 0 & \text{ otherwise}\end{cases}$

$Q_A = \begin{cases} 1/176.3760684 & \text{Druid, Monk} \\ 0 & \text{otherwise}\end{cases}$

$Q_M = \begin{cases} 1 & \text{Paladin} \\ 0.5/2.2 & \text{Warrior} \\ 0 & \text{otherwise}\end{cases}$

Race Stat Modifiers
Race raceStrMod raceAgiMod
Human 0 0
Dwarf 5 -4
Night Elf -4 4
Orc 3 -3
Tauren 5 -4
Undead -1 -2
Gnome -5 2
Troll 1 2
Blood Elf -3 2
Draenei 1 -3
Goblin -3 2
Worgen 3 2
Pandaren 0 -2

 

Background

Blizzard’s formula for diminishing returns looks a little different than the one the community generally uses. If you read community guides (including my old posts on the subject), we tend to use a two-parameter formula:

$\text{totalParry} = \text{baseParry} +1 / \left ( \frac{1}{C_p} + \frac{k}{\text{bonusParry}} \right )$

where $C_p$ is the parry cap (or dodge cap $C_d$ or block cap $C_b$ for the other formulas) and $k$ is a class-dependent constant. It’s not hard to show that this formula is identical in form to the Blizzard ones: multiply both numerator and denominator of the second term on the right-hand side by $\text{bonusParry}$ to get:

$\text{totalParry} =\text{baseParry} + \text{bonusParry} / \left ( \text{bonusParry} /C_p+k \right ) $

In this form it’s clear that $k = \text{HorizontalShift}$, and that there’s a very simple relationship between $C_p$ and the remaining two constants:

$C_p = 1/ \left (\text{ParryFactor} \times \text{VerticalShift} \right )$

and similarly for $C_d$ and $C_b$, substituting the appropriate “Factor” constant. There’s also a fourth $C_m$ and $\text{MissFactor}$ that I’ve omitted since we don’t have ways to change our miss chance.

Despite the fact that Blizzard’s formula has three parameters, each individual formula only really uses two. $\text{ParryFactor}$ and $\text{VerticalShift}$ are redundant parameters, since they only ever show up multiplied together. In theory, they could eliminate one of them entirely in favor of the other; e.g. eliminate $\text{VerticalShift}$ and merge that into the $\text{Factor}$ variable. Then every equation would have a different $\text{Factor}$ variable (just as ours had a different cap constant $C_p$, $C_d$, etc.), but the same class-based $\text{HorizontalShift}$.

We can also plug in the values Celestalon gave us to see how accurate our previous fitting session was:

Calcualted Cap Values
Class $k$ $C_d$ $C_p$ $C_b$
Death Knight 0.956 90.6425 237.1860 150.3759
Druid 1.222 150.3759 150.3759 150.3759
Monk 1.422 501.2531 90.6425 150.3759
Paladin 0.886 66.5675 237.1860 150.3759
Warrior 0.956 90.6425 237.1860 150.3759
Empirically Determined Cap Values (from Aug 2013)
Class $k$ $C_d$ $C_p$ $C_b$
Death Knight $0.956$ $90.6425(74) \pm 0.000010$ $237.186(14) \pm 0.00015$ -
Druid $1.222$ $150.3759(38) \pm 0.000041$ - -
Monk $1.422$ $501.253(48) \pm 0.00032$ $90.642(44) \pm 0.00014$ -
Paladin $0.886$ $66.56744(62) \pm 0.0000060$ $237.1860(40)\pm 0.000055$ $150.3759(469)\pm 0.0000094$
Warrior $0.956$ $90.64254(65) \pm 0.0000052$ $237.1860(91) \pm 0.000057$ $150.375(68) \pm 0.00015$

Comparing the tables, it’s clear that our fitting system nailed all of these. Most were accurate out to 4 decimal places, and the remaining ones out to three decimal places. Almost all of them were accurate to the reported precision in the table. That gives us a lot of confidence in our fitting algorithms and techniques, which is why we’re able to believe that we can detect a systematic error of 0.0004% parry. Now, let’s see how we figured that out.

Testing The Parry Equation

Based on several discussions with Celestalon, we know that the original intent was something like this:

$\text{baseParry} = 3.00\%$ (exact)
$\text{bonusParry} = (\text{Strength} – \text{classBaseStr} – \text{raceStrMod})\times Q_S + \text{parryRating}/162$
$\text{totalParry} = \text{baseParry}+\text{bonusParry} / \left ( \text{bonusParry}\times\text{ParryFactor}\times\text{VerticalStretch}+\text{HorizontalShift}\right ) $

In other words, the parry from the class contribution to base strength (which is not affected by DR) is completely negated, such that base parry is exactly 3% for each class. However, we also discovered that this wasn’t the case, and were subsequently told that the racial strength modifier is not negated, and that this racial modifier is affected by DR. The “edit” and follow-up post he’s provided since are actually in error, as we’ll see shortly.

So, taking his word from before the edits, what we should be seeing is:

$\text{bonusParry} = (\text{Strength} – \text{classBaseStr} )\times Q_S + \text{parryRating}/162$

Unfortunately, that’s not what the game is doing. For example, let’s take a naked Gnome Warrior. Here are the relevant values:

$\text{classBaseStr} = 1455$
$\text{ raceStrMod} = -5$
$\text{ Strength} = 1450$
$\text{ parryRating} = 0$
$\text{ ParryFactor} = 0.634$
$\text{ VerticalStretch} = 0.00665$
$\text{ HorizontalShift} = 0.956$

If you plug those values into the formulas above, you get (keeping only 10 decimal places):

2.9703430316%

If you use GetParryRating() in-game though, you get (again, to 10 decimal places):

2.9720702171%

A difference of ~0.002%. Not that far off… but this should be nearly exact, we’re using the same formula the game does. At first, I thought that perhaps this was because Celestalon rounded the $\text{ParryFactor}$, $\text{VerticalStretch}$, and $\text{HorizontalStretch}$ values he gave us in the Theorycrafting thread. However, last week I took a few quick data sets to test this hypothesis, and convinced myself that isn’t the issue. In fact, given the accuracy and agreement we see with the empirically-obtained values from August 2013, the values he provided in the Theorycrafting thread may well be exact, and not rounded at all!

To illustrate why, here’s the data for the naked gnome warrior, all retrieved through the the Statslog addon with minor tweaks to get it working again on beta. Statslog uses the World of Warcraft API functions UnitStat("player",1), GetCombatRatingBonus(CR_PARRY), and GetParryChance() to retrieve this information, giving us very high precision results. Again, I’ve only kept 10 decimal places for the table since we’d be ecstatic to fit to even that precision. To collect this data, I just added or removed gear to change my total stats.

Gnome Warrior Data
$\text{Strength}-\text{classBaseStr}$ $\text{parryRating}/162$ $\text{totalParry}$
-5 0.0000000000 2.9720702171
-5 1.2962962389 4.3203210831
205  1.2962962389 5.5452437401
426 2.2037036419 7.7356786728
550 2.7530863285 8.9868812561
674 2.7530863285 9.6833515167
798 3.3024692535 10.9137287140
964 3.9814815521 12.4860315323
1130 3.9814815521 13.3895244598
1351 4.8888888359 15.4365730286
1517 5.6172838211 16.9933910370
1738 6.5246915817 18.9761753082
1904 6.5246915817 19.8289909363
2028 7.0000000000 20.8874912262
2249 7.0000000000 22.0019493103
2121 6.4753084183 20.8898067474
2245 6.9876542091 21.9709510803

I put that data in MATLAB and used it to fit values for $\text{VerticalStretch}$ and $\text{HorizontalShift}$ with very strict tolerances on accuracy but very loose tolerances on $\text{VerticalStretch}$ ($\pm 0.0001$) and $\text{HorizontalShift}$ ($\pm 0.001$). This means that MATLAB’s fitting algorithms will attempt to determine the values very accurately, but will also allow them to vary anywhere within the tolerance on each constant. Note that I’ve chosen those tolerances to provide complete flexibility in rounding those values and then some – in other words, any value of those constants which rounds to the ones given by Celestalon is fair game in this fit, and even some values outside of that range (e.g. 0.00666 for $\text{VerticalStretch}$).

The formula, fit details, and plot are given below. In this fit, $x$ is our definition of $\text{bonusParry}$ above, which includes the strength contribution (in this case negative) of the racial strength modifier.

General model:
 fitresult(x) = 3+0*0.0056697+x/(x*0.634*vs+hs)
 Coefficients (with 95% confidence bounds):
 vs =    0.006668  (0.006661, 0.006675)
 hs =      0.9559  (0.9559, 0.956)
Gnome Warrior Parry Fit.

Gnome warrior parry fit.

That looks pretty good – hs ($\text{HorizontalShift}$) is about right, though the parameter vs ($\text{VerticalStretch}$) has to be higher than is reasonable to be rounded to a value of 0.00665. However, the proof that something’s wrong is in the plot of the residuals – the difference between the fitted curve and the actual data. Here are those differences in tabular form:

Gnome Warrior parry fit residuals
Fit Data Residual
2.9703 2.9721 -0.0017
4.3190 4.3203 -0.0013
5.5442 5.5452 -0.0010
7.7352 7.7357 -0.0005
8.9866 8.9869 -0.0003
9.6832 9.6834 -0.0002
10.9137 10.9137 -0.0000
12.4862 12.4860 0.0001
13.3897 13.3895 0.0002
15.4369 15.4366 0.0003
16.9937 16.9934 0.0003
18.9763 18.9762 0.0002
19.8291 19.8290 0.0001
20.8875 20.8875 -0.0000
22.0018 22.0019 -0.0002
20.8898 20.8898 -0.0000
21.9708 21.9710 -0.0002

Again, it’s not off by much… but ~0.002% is enough to cause rounding errors that lead the character sheet value to differ by 0.01% compared to calculations (i.e. SimC’s output). So it’s worrisome. Furthermore, these residuals tell us something else about the fit. A graphical representation is a little more revealing, in this case:

Gnome Warrior parry fit residuals.

Gnome warrior parry fit residuals.

It may not be clear to a layperson, but someone who’s been fitting data for years will instantly recognize the meaning of that plot. The fact that there’s curvature indicates some sort of systematic error. If we have the correct formula, the residual plot shouldn’t have curvature – it should look almost like a random scatter plot. For example, like this plot from 2012:

Dodge residuals from August 2012 post.

If you read through that post, you’ll notice that I used the same technique of looking for details and patterns in a residuals plot to identify a systematic error in our assumed value of the agility-to-dodge conversion factor, as well as to figure out that the game performs a binary rounding operation on $\text{bonusBlock}$.

The point this time around is that with such loose tolerances on the two DR coefficients, the fit should have no trouble producing a very clean residual plot. That tells us that either

  1. Our DR coefficients lie outside the region we’ve provided, which means Celestalon doesn’t know how to round (unlikely), or
  2. something is wrong with the formula.

My first thought was to try the obvious thing: assume Celestalon lied! Ok, not really, but I thought maybe he was mistaken about the racial stat modifier being affected by DR. So I moved it outside the DR calculation in my code. In other words, I now let

$\text{baseParry} = 3 + \text{raceStrMod}\times Q_S$
$x = \text{bonusParry} = ( \text{Strength} – \text{classBaseStr} – \text{raceStrMod} )\times Q_S + \text{parryRating}/162$

Doing that gives us:

Gnome Warrior parry residuals, mark II.

Gnome warrior parry residuals, mark II.

General model:
 fitresult(x) = 3+-5*0.0056697+x/(x*0.634*vs+hs)
 Coefficients (with 95% confidence bounds):
 vs =    0.006654  (0.006652, 0.006656)
 hs =      0.9559  (0.9559, 0.9559)

You might note that the residuals have gone down considerably here – the largest is now $-4\times 10^{-4}$ rather than $-1.7\times 10^{-3}$, which suggests that the hypothesis is likely correct. The parry from racial strength modifiers is probably not being affected by diminishing returns. But what bothered me is that there’s still curvature on the residuals plot – that means we still don’t have the formula right.

Just to make sure I wasn’t loony, I tried this with dwarf and draenei warriors too. Both races exhibited similar curvature in the residuals plot, so it’s not just gnomes acting oddly. Next, as a sanity check, I tried a human warrior. Since a human warrior has a racial modifier of zero, the curvature should disappear if that’s the cause of the problem.  I also added $Q_S$ as another fit parameter just in case that value was incorrect, unlikely as that was since it was also given to us by Celestalon. Adding that parameter turns our curve fit into a surface fit, so the residual plot will be 3-dimensional. Here’s what it looked like:

Human warrior parry fit residuals.

Human warrior parry fit residuals.

General model:
 fitresult(x,y) = 3+0/q+(x/q+y)/((x/q+y)*vs*0.634+hs)
 Coefficients (with 95% confidence bounds):
 vs =    0.006655  (0.006652, 0.006657)
 hs =      0.9558  (0.9556, 0.9561)
 q =       176.4  (176.3, 176.5)

The curvature there should be clear despite the viewpoint of the plot. So this curious result tells us that this isn’t a problem limited to racial strength modifiers. There’s still something else missing. And it didn’t take much guessing to stumble across the solution.

Let’s assume there’s some extra amount of strength that’s giving parry, and that it’s not subject to diminishing returns. In other words, we let

$\text{baseParry} = 3.00 + (\text{raceStrMod} + R)\times Q_S$

Let’s also assume that $Q_s$ is accurate as given, so we can go back to curve fits rather than surface fits. Then, the fit and residuals for a human warrior look like this:

Human warrior parry residuals, mark II.

Human warrior parry residuals, mark II.

General model:
 fitresult(x) = 3+(0+r)*0.0056697+x/(x*0.634*vs+hs)
 Coefficients (with 95% confidence bounds):
 vs =     0.00665  (0.00665, 0.00665)
 hs =       0.956  (0.956, 0.956)
 r =     0.07385  (0.07367, 0.07404)

This is what a residual plot should look like. It’s mostly numerical noise at the ~$1\times 10^{-6}$ level, and it’s more or less randomly distributed. It’s not entirely clear why we even have that much noise, because $\text{HorizontalShift}$ and $\text{VerticalStretch}$ are allowed to vary by $\pm 0.001$ and $\pm 0.00001$ respectively, so it’s not due to rounding of those values. It may just be some subtlety of the calculation that differs between Blizzard’s implementation and my MATLAB formula. Regardless, it isn’t that important – nobody will ever notice a 0.000001% change in parry chance.

In any event, the key point here is that Humans are magically getting around 0.07385 Strength worth of parry chance (about 0.0004187%) that isn’t affected by DR. The likely explanation is that the subtraction that negates the parry from $\text{classBaseStr}$ isn’t quite correct, since we know they’ve been fiddling with that recently. It may be something as simple as rounding – if whatever formula determines a warrior’s base strength produces a value of 1455.07385, the game could be adding 1455.07385 strength worth of parry rating, but only subtracting off the rounded 1455 strength worth of rating.

Repeating this with our gnome (-5 racial strength modifier) or dwarf (+5 racial strength modifier) revealed a few more details. If the racial strength modifier was included in $\text{bonusParry}$ (and thus affected by DR), I was only able to get a fit with “good” residuals if I was flexible with $\text{HorizontalShift}$ and $\text{VerticalStretch}$ – for example, if I let $\text{VerticalStretch}=0.00661$ and $\text{HorizontalShift}=0.9562$. And that was further complicated by the fact that those values would have to be allowed to be different for each race, which is obviously wrong since we know they’re class-dependent constants that are independent of race. If I tightened the restrictions on $\text{HorizontalShift}$ and $\text{VerticalStretch}$ such that they are nearly exact as given, the curvature started to appear again. For example:

Gnome warrior parry residuals, mark III.

Gnome warrior parry residuals, mark III.

General model:
 fitresult(x) = 3+(0+r)*0.0056697+x/(x*0.634*vs+hs)
 Coefficients (with 95% confidence bounds):
 vs =     0.00665  (fixed at bound)
 hs =       0.956  (fixed at bound)
 r =     -0.1561  (-0.3099, -0.002212)

However, if I move the racial strength bonus into $\text{baseParry}$ (outside of the DR calculation), we get good residuals:

Gnome warrior parry residuals, mark IV.

Gnome warrior parry residuals, mark IV.

General model:
 fitresult(x) = 3+(-5+r)*0.0056697+x/(x*0.634*vs+hs)
 Coefficients (with 95% confidence bounds):
 vs =     0.00665  (0.00665, 0.00665)
 hs =       0.956  (0.956, 0.956)
 r =     0.07391  (0.07368, 0.07413)

Again, recall that the $\text{bonusParry}$ value $x$ I feed to this equation is adjusted for the location of the racial modifier in the code in each case.

Note the amount of “phantom” strength $r$ being added here: 0.07391, awfully close to the value we found for humans. As it turns out, we get the same amount of “phantom” strength if we fit a gnome death knight (0.07387) or a dwarf warrior (0.07382), and a very similar value from a draenei warrior (0.07369). Loading up a human paladin (and adjusting $\text{HorizontalShift}$ appropriately) gives a phantom strength value of (0.07392), confirming that this isn’t a class-based thing and doesn’t depend on the DR calculation at all.

In short, any tank class that gets a strength-to-parry conversion is getting this phantom amount of parry, regardless of race, DR coefficients, or gear. Testing with a monk shows that they have a fixed 3.0000000% parry, suggesting that the agility tanks are not getting this bonus. This is why I’ve framed it as a phantom amount of strength rather than a phantom amount of parry. We can’t say for sure if the agility tanks still have that phantom strength contribution or not, because either way they don’t get any parry from it.

Testing The Dodge Equation

The obvious next question was whether agility tanks were getting a similar effect.

To test, I just assumed that the racial agility modifier worked the same way as the strength modifier did for the strength tanks. I created a Night Elf monk, which has a +2% dodge racial bonus and +4 racial agility modifier, and tried the formulas:

$\text{baseDodge} = 5.00 + (\text{raceAgiMod}+R)\times Q_A$
$x=\text{bonusDodge} = (\text{Agility}-\text{classBaseAgi}-\text{raceAgiMod})\times Q_A + \text{dodgeRating}/162$

along with the usual DR formula to determine $\text{totalDodge}$. The result was pretty good:

Night elf monk dodge fit residuals.

Night elf monk dodge fit residuals.

     General model:
     dfit(x) = 5+(4+R)*0.0056697+x/(x*0.3*vs+hs)
     Coefficients (with 95% confidence bounds):
       R =  2.345e-005  (-2.033e-005, 6.723e-005)
       hs =       1.422  (1.422, 1.422)
       vs =     0.00665  (0.00665, 0.00665)

Looks like our hunch was correct, and that racial base agility is granting dodge that isn’t affected by diminishing returns. Just to be sure, we should test a few more times though. Let’s double check this with a dwarf monk, which has a racial agility modifier of -4, and a base parry of 3%:

Dwarf Monk dodge fit residuals.

Dwarf Monk dodge fit residuals.

     General model:
     dfit(x) = 3+(-4+R)*0.0056697+x/(x*0.3*vs+hs)
     Coefficients (with 95% confidence bounds):
       R =   2.95e-005  (-4.765e-006, 6.376e-005)
       hs =       1.422  (1.422, 1.422)
       vs =     0.00665  (0.00665, 0.00665)

Looks good. Running a night elf druid through the fitting algorithm produces similar results:

Night elf druid dodge fit residuals.

Night elf druid dodge fit residuals.

     General model:
     dfit(x) = 5+(4+R)*0.0056697+x/(x*1*vs+hs)
     Coefficients (with 95% confidence bounds):
       R =  1.693e-005  (-1.27e-005, 4.655e-005)
       hs =       1.222  (1.222, 1.222)
       vs =     0.00665  (0.00665, 0.00665)

This pretty much confirms that we’ve got it right, and it’s reasonable to expect that it works the same way for the rest of the druid and monk races.

Testing The Block Equation

There isn’t really much to say here. The block equation is unchanged from Mists, and it appears they haven’t tinkered with it. The exact same fitting code that worked in Mists works now, and produces a great fit. Nonetheless, I updated it to match the other functions and to use the Blizzard formulation:

Human paladin block fit residuals.

Human paladin block fit residuals.

     General model:
     bfit(x) = 13+R+x/(x*1*vs+hs)
     Coefficients (with 95% confidence bounds):
       R =  7.405e-006  (-2.273e-005, 3.754e-005)
       hs =       0.886  (0.886, 0.886)
       vs =     0.00665  (0.00665, 0.00665)

Similarly good fits were obtained with all of my warrior test subjects, suggesting that the block DR equations are working the same way they have been.

Conclusions

So we’ve confirmed that

  • Racial strength modifiers grant parry that is not affected by parry DR.
  • Racial agility modifiers grant dodge that is not affected by dodge DR.
  • There’s some phantom parry being added to all strength-based tanking classes, but not to agility tanking classes.
  • Block diminishing returns seem to be working exactly like they should be.

The obvious question is, “what will Blizzard do about it?”

The parry bug is a difference of 0.0004%, which is insignificant in the grand scheme of things. It only matters to crazy people like me that want to be able to replicate the character sheet values 100% of the time and stamp down those rare 0.01% rounding errors. So it didn’t surprise me in the least that the response was that I should just build it into my models, because it was too small to matter and their programmers had better things to do. I can’t argue with that at all, really.

Similarly, I don’t think there’s any reason they need to move the racial strength modifier back out of $\text{baseParry}$ and into $\text{bonusParry}$, or to remove it altogether. It’s entirely arbitrary how that works, and it only matters insofar as theorycrafters want to know how to model it properly. It seems like a waste of time for them to change that around at this point just for the sake of cleaning up the equations.

So I think it’s safe to say that these are the diminishing returns formulas that we’ll be using throughout Warlords. I’ve already programmed the changes into Simulationcraft and run some tests with a few characters to make sure they’re working.

A Word On Theorycrafting

This installment was a little more complicated than the earlier TC101 articles. In particular, I talked a lot about “fitting” the data, but didn’t go into any detail on how that’s done. However, explaining how to fit data using MATLAB’s curve fitting toolbox or associated methods would be somewhat useless, because the likelihood is that you don’t have MATLAB at home. It’s more likely that you’d be putting the data in Excel or a Google documents spreadsheet and attempting to fit the data that way.

Unfortunately, that way is a lot less flexible (which is why I use MATLAB instead!). The built-in fitting functions are more limited, for one thing. If your data is linear, then you’re all set, but if not you often have to be creative. You can’t quickly and easily define and change a custom fitting function, at least to my knowledge.

But there are plenty of tutorials on how to do this sort of thing online. Fitting linear (i.e. $y=mx+b$) or polynomial data (i.e. $y=a + bx + cx^2 + dx^3 + …$) is incredibly easy, and you’ll find plenty of hits from a simple Google search. Fitting nonlinear data, like our diminishing returns equations, is more complicated, but there’s a great guide from California State Polytechnic University, Pomona that details how you’d go about fitting a complicated equation in Excel.

Ultimately, though, your first step should be to ask yourself whether you need that level of precision. For something like this, most players don’t, and would be satisfied with being within 0.01% of the character sheet avoidance value. If you decide you do need more accuracy, that’s when you take stock of the tools you have at hand to deal with the problem, and decide if they’re suitable. If they are (maybe you have Excel and the time to learn how to use the Solver), then great! If not, though, you might need to seek out someone who does have the knowledge and/or tools you need.

Remember, theorycrafting is a collaborative process, so there’s nothing wrong with asking for assistance. Sometimes just having another set of eyes looking at the data, or looking at it with a different tool, will crack a tricky problem wide open.

Posted in Tanking, Theck's Pounding Headaches, Theorycrafting | Tagged , , , , , , , , , , , , , , | 9 Comments

TC101: How Stats Are Calculated

Primary attribute calculations seem like they should be a pretty simple topic. So simple, in fact, that most players don’t even think about how they’re done. Most theorycrafters don’t either until they try to write a spreadsheet that models a character and notice that their math doesn’t work out.

I wonder how many times the following scenario has been re-enacted over the past few years:

Okay, my Paladin has 1455 base strength and 2378 strength from gear, for a total of 3833. With the 5% bonus for wearing plate armor, that should give me 3833\times 1.05=4024.7. The 5% stats raid buff should raise that to 3833\times 1.05\times 1.05=4225.9. My character sheet only gives an integer, so it should round that to 4226. Right?

4224 is not equal to 4226

4224 is not equal to 4226

Wait, what??

As it turns out, stat calculations are one of the more convoluted things in the game, and I suspect that (until now) few theorycrafters have modeled all the nuances with complete accuracy. Blizzard tosses a few floor() and round() functions into the mix at seemingly arbitrary places, which makes it tougher to reverse engineer. Over the past month or so, I’ve been collecting data from beta and working on determining exactly where and how the stat calculations are rounded.

This is a Theorycrafting 101 article because this process is a great example of the sort of thing I spoke about in part 1: starting with a basic model and adding complexity until all the details work. After we go over the formulas for calculating stats, we’ll go step-by-step through the process I used to test and determine the formulas.

Primary Attribute Formulas

Here’s how your character sheet attributes are calculated. First, we define some conditional values.

$\text{match} = \begin{cases}1.05 & \text{if armor matches class} \\ 1.00 & \text{otherwise} \end{cases}$

$\text{epicurean} = \begin{cases} 2 & \text{if pandaren} \\ 1 & \text{otherwise} \end{cases}$

$\text{alchemy} = \begin{cases} 2 & \text{if alchemist} \\ 1 & \text{otherwise} \end{cases}$

$\text{multiplier}$ is the total multiplier from buffs and other effects. So for example, if the only buff you have active is Blessing of Kings,

$\text{multiplier} = \begin{cases} 1.05 & \text{for STR/INT/AGI} \\ 1.00 & \text{otherwise} \end{cases}$

Similarly, Fortitude would be a $\text{multiplier}$ of 1.10, Guarded By The Light would give 1.25, and so on. Multiple effects are multiplicative, so a protection paladin with Fortitude active would have a stamina multiplier of $1.10\times 1.25=1.375$.

We then calculate the total base $B$ and gear $G$ contributions before multipliers:

$B = \text{race_base}+\text{class_base} + \text{heroic_presence} + \text{endurance}$

$\begin{align} G = \text{gear_stat} &+ \text{round}[~\text{food_stat}~] \times \text{epicurean} \\ &+ \text{round}[~\text{flask_stat}~] \\ &+ \text{round}[~\text{potion_stat}~] \\ &+ \text{round}[~\text{trinket_proc_stat}~] \end{align}$

And generate a “composite” value $C$ that incorporates the matching multiplier:

$C = \text{floor}[~G\times \text{match}~]+B\times \text{match}$

Finally, your character sheet mouseover tooltip reads:

Strength CS_Total ( CS_Base + CS_Bonus ),

with:

$\text{CS_Total} = \text{floor}[~C \times \text{multiplier}~ ]$
$\text{CS_Base} = \text{floor}[ ~B \times \text{match}~ ]$
$\text{CS_Bonus} = \text{CS_Total} – \text{CS_Base}$

Building The Model

Now that we’ve got the math out of the way, let’s see how we determined it. First of all, let’s go back to our original example. If we log on to the beta PvP server and create a new level 100 Paladin, this is what we get:

When I grow up, I want to run a camel farm.

When I grow up, I want to run a camel farm.

As you can see, the character has 1455 base strength and 2378 “bonus” strength.  Since we haven’t chosen a spec yet, and we’re completely unbuffed, these values should properly reflect our total base strength and strength from gear, respectively. We can double-check this, because Celestalon gave us the full list of base stats for each class ($\text{class_base}$)as well as the racial base stat modifiers ($\text{race_base}$). A human’s $\text{race_base}=0$ and a paladin’s $\text{class_base}=1455$, so it’s quite clear that our character sheet’s giving us the correct base value. Likewise, you could go through and add up all the strength on each piece of gear to confirm that the sum is 2378. Together, that makes the 3833 total given on the character sheet.

In other words, so far we’ve got the following skeletal formulas:

$B = \text{class_base}+\text{race_base}$
$G = \text{gear_stat}$
$\text{CS_Base} = B$
$\text{CS_Bonus}=G$
$\text{CS_Total}=B+G$

Those aren’t final, of course – we’re going to be adding to them and correcting them as we go.

This is also useful because it means when we go to test other classes, we can look at the unbuffed values before we chose a spec to grab our $B$ and $\text{gear_stat}$ values.

Adding Armor Skills

Now let’s choose a spec. When we spec Retribution, we get the 5% increase to strength from the Armor Skills passive. Which gives us slightly different numbers:

We can respec her. We have the technology. We can make her ...stronger...faster.

We can respec her. We have the technology. We can make her …stronger…faster.

The only thing we’ve changed is to add a multiplier of 1.05 thanks to the armor specialization passive. Yet, as you might have guessed from our earlier example, our new value is not just 1.05 times our un-specced value of 3833. $3833\times 1.05 = 4024.7$, yet our character sheet reads 4023! Let’s see what’s going on here.

First, let’s consider the base value. We started with 1455, and $1455\times 1.05=1527.8$. The character sheet reads 1527, though, which tells us that the character sheet is taking the result of the calculation and applying a floor() function. In fact, this isn’t much of a surprise – it’s been known for a while that all of the values on the character sheet are floored rather than rounded. The game still uses the full-precision values when it does calculations though, so you don’t have to worry about stat points being “wasted” due to rounding/flooring.

Similarly, the 2378 strength from gear has become 2496 bonus strength. If we check the math, $2378\times 1.05 = 2496.9$. So the bonus strength is also being floored, not rounded. Our total strength is just the sum of the two floored values, which tells us that some of this flooring is happening before it’s displayed on the character sheet, otherwise we should have 4024 strength, as mentioned earlier. This is also useful information: since we know that the three character sheet values are linked through basic addition, we really only need to find correct formulas for two of them, and the third will fall into place automatically.

Now, none of this is really news. These details have been known for some time, since it’s very easy to stumble across. But this is how someone, at some point, had to go about determining it.

So now we can update our skeleton formulas slightly to incorporate the new details:

$B = \text{class_base}+\text{race_base}$
$G = \text{gear_stat}$
$\text{CS_Base} = \text{floor}[ ~B \times \text{match}~]$
$\text{CS_Bonus}=\text{floor}[~ G\times \text{match}~]$
$\text{CS_Total}=\text{CS_Base}+\text{CS_Bonus}$

The trick here is that there’s some ambiguity about those floor functions. For example, according to this, our $\text{CS_Total}$ could be expressed as:

$\text{CS_Total} = \text{floor}[~B\times \text{match}~] + \text{floor}[~G\times \text{match}~],$

but in reality, we’d get the same result from either of the following formulas as well:

$\text{CS_Total} = \text{floor}[~\text{floor}[~B\times \text{match}~] + G\times \text{match}~]$
$\text{CS_Total} = \text{floor}[~B\times \text{match} + \text{floor}[~G\times \text{match}~]~]$

So we don’t really know which is correct yet. The one thing we can rule out is having no floors.

Incorporating Multipliers

Now let’s apply Blessing of Kings to see how that interacts with these formulas:

It's good to be the King.

It’s good to be the King.

Our first guess might have been that Kings would work the same way as the matching multiplier. In other words, our character sheet base should be $1455\times 1.05\times 1.05=1604.1$, or 1604. But it’s clear that’s not how it works, because our base value hasn’t changed – it’s still 1527. Likewise, if we treat the bonus strength contribution the same way, we’d get $2378\times 1.05\times 1.05 = 2621.7$, which is far too low. Something else is happening here.

If we naively take our total strength before Kings (4023) and multiply by the Kings modifier, we get $4023\times 1.05=4224.2$, which is exactly right after applying a floor function. Interesting! This actually gives us a hint as to how to proceed, but I’m going to blithely ignore it for instructional purposes.

That detail does make it pretty clear that base strength is affected by Kings, though. But the game’s accounting adds that extra strength to the green bonus strength value rather than the white base strength value in the tooltips.

For the moment, let’s go with our earlier (and unstated) assumption that the game calculates things the way we have, such that “base” and “bonus” strength are calculated independently and then summed to get the total. We’ll find out shortly if this is a good assumption or not. The bonus strength value is then, roughly speaking,

$G\times \text{match}\times \text{multiplier} + B\times \text{match}\times (\text{multiplier}-1)$

with the caveat that there may be some floors going on in there. We can turn that “may” into a “must” by checking the math:

$2378\times 1.05 \times 1.05 + 1455\times 1.05\times 0.05 = 2698.1$

which should give us a bonus strength value of 2698, not 2697. So we know that in order for this formulation to be correct, there has to be a floor happening somewhere before we get to the value that the game floors to show on the character sheet. We can also rule out any uses of round() here, because that would always give 2698.

This is the same ambiguity I spoke of earlier – we knew that the character sheet values were being floored, but we weren’t 100% sure where. Including the Kings multiplier here has clarified that there needs to be at least one extra floor() floating around in our hypothetical formula, but doesn’t tell us exactly where. So we have to try them all, and see if we can rule any of them out.

There are four logical scenarios that use only one floor (in addition to the final floor used to display the value on the character sheet). They are:

$F1=\text{floor}[~G\times \text{match}~]\times \text{multiplier} + B\times \text{match}\times (\text{multiplier}-1)$
$F2=\text{floor}[~G\times \text{match}\times \text{multiplier}~] + B\times \text{match}\times (\text{multiplier}-1)$
$F3=G\times \text{match}\times \text{multiplier} + \text{floor}[~B\times \text{match}~]\times (\text{multiplier}-1)$
$F4=G\times \text{match}\times \text{multiplier} + \text{floor}[~B\times \text{match}\times (\text{multiplier}-1)~]$

If we put our data into this, with $G=2378$, $B=1455$, $\text{match}=1.05$, and $\text{multiplier}=1.05$, they give us the following results:

$F1=2697.19$
$F2=2697.39$
$F3=2698.10$
$F4=2697.75$

This rules out $F3$, because the final floor() on the character sheet would leave that as 2698, which is wrong. But this test can’t distinguish between $F1$, $F2$, and $F4$. Any of those could still be correct. Unfortunately, that’s all the information we can extract from our premade Ret paladin.

We learn a little more if we swap specs to protection. In protection spec, we get a 5% increase to stamina from the Armor Skills passive along with the 25% increase to stamina from Guarded By The Light. Starting with $B=890$ base stamina and $G=3250$ from gear, and using $\text{multiplier}=1.25$, the formulas give us:

$F1=4498.63$
$F2=4498.63$
$F3=4499.13$
$F4=4498.63$

And looking at the character sheet….

One of these things is not like the others.

One of these things is not like the others.

Uh oh. The only one that worked was $F3$, which we’ve already ruled out with our ret paladin. So this tells us that none of those formulas are correct. And increasing the number of floors doesn’t help, because it just makes the values even smaller, which won’t satisfy the protection data. For example,

$F5=\text{floor}[~G\times \text{match}\times \text{mult}~]+\text{floor}[~B\times \text{match}~]\times (\text{mult}-1) = 4498.50$

Still no dice. We can’t add round functions either, because then the ret data isn’t satisfied. As it turns out, we’re going about this the wrong way. Our original hypothesis – that the game calculate the base and bonus values individually and sums them to get the total – has to be false.

This isn’t really news, because theorycrafters have been using an alternative formulation for years. But it’s a good example of coming up with a hypothesis, testing it, and ultimately ruling it out, which is something that happens all the time in theorycrafting. Now that we’ve done so, let’s see if we have more luck with another hypothesis.

A Change Of Approach

The traditional approach goes something like this: rather than trying to calculate base and bonus strength individually, let’s try deriving correct formulas for the base and total values. Then the bonus value will be determined using basic subtraction. As we’ll see, this approach is much more successful.

Just as we did for bonus strength, we’ll construct formulas for total strength using $B$, $G$, $\text{match}$, and $\text{multiplier}$. We also know there has to be at least one floor in there somewhere based on our armor matching modifier test.

There are six obvious ways to do this using one or two floor functions:

$T1 = \text{floor}[~G\times \text{match}~]\times \text{multiplier}+B\times \text{match}\times \text{multiplier}$
$T2 = \text{floor}[~G\times \text{match}\times \text{multiplier}~]+B\times \text{match}\times \text{multiplier}$
$T3 = G\times \text{match}\times \text{multiplier}+\text{floor}[~B\times \text{match}~]\times \text{multiplier}$
$T4 = G\times \text{match}\times \text{multiplier}+\text{floor}[~B\times \text{match}\times \text{multiplier}~]$
$T5 = \text{floor}[~G\times \text{match}~]\times \text{multiplier}+\text{floor}[~B\times \text{match}~]\times \text{multiplier}$
$T6 = \text{floor}[~G\times \text{match}\times \text{multiplier}~]+\text{floor}[~B\times \text{match}\times \text{multiplier}~]$

We could also come up with two more methods using two floors, but they would require that we be flooring before the $\text{multiplier}$ in one term but not in the other, which seems unlikely. If none of these hold up, we’ll revisit that idea.

Plugging in our ret paladin stats of $G=2378$, $B=1455$, $\text{match}=1.05$, and $\text{multiplier}=1.05$, we get the following results:

$T1=4224.94$
$T2=4225.14$
$T3=4225.10$
$T4=4225.75$
$T5=4224.15$
$T6=4225.00$

So right out of the gate, we can cross off four of the formulas (2, 3, 4, and 6). Only $T1$ and $T5$ give a value consistent with the character sheet. And there’s something notable about those two formulas: we can factor out $\text{multiplier}$ in each of them:

$ T1  = \left (~ \text{floor}[~G\times \text{match}~]+B\times \text{match}~ \right )\times \text{multiplier}$

$T5 = \left (~ \text{floor}[~G\times \text{match}~]+\text{floor}[~B\times \text{match}~] ~ \right ) \times \text{multiplier}$

that observation will come in handy later. For now, we need to figure out which one of these two formulas correct.

It’s worth noting that $T5$ is what’s frequently been used for calculating base stats in most theorycrafting works. This is what Simulationcraft has been using throughout MoP, for example. It’s pretty close, and generally gives you answers that are correct.

But as we noticed while working on the WoD code, on some rare occasions, it’s off by one. You can see why, as well: Let’s say that $B=919$. Then $B\times \text{multiplier}=964.95$. If we just multiply by $\text{multiplier}$ like we do in formula $T1$, we’d get a subtotal of 1013.20. But if we floor that 964.95 before multiplying, we get 1012.20. The two formulas would give answers that differ by one, with $T1$ giving a slightly higher value than $T5$.

So to test this discrepancy, we need to find a character with just the right amount of stat bonus. This gets easier the higher $\text{multiplier}$ is, so let’s try with our prot paladin, whose $\text{multiplier}=1.3750$ for stamina once we apply the 10% stamina buff.  Again using $B=890$, $G=3250$, and our $\text{match}=1.05$, we get:

$T1 = 5976.44$
$T2 = 5975.75$

Demonstrating the “off-by-one” error. And what does the character sheet say?

Conclusive Evidence!

We’ve already shown earlier that this value has to be floored rather than rounded, so this removes any ambiguity. $T1$ is the only formula that’s still standing. We now know conclusively how our total stats are calculated, at least so far.

Since we can factor the $\text{multiplier}$ out, it makes some sense to define a “composite” subtotal $C$ to make the math a little easier. In other words, we define it such that

$C = \text{floor}[~G\times \text{match}~]+B\times \text{match}$,

and then our character sheet base and total values are just

$\text{CS_Base} = \text{floor}[~ B\times \text{match}~]$
$\text{CS_Total} = \text{floor}[~C\times \text{multiplier}~]$

And of course, $\text{CS_Bonus} = \text{CS_Total}-\text{CS_Base}$. This gives you the bulk of the formulation provided in the beginning of this post.

The Nitty-Gritty Details

We’re not finished yet, though. Because even after this, we were able to observe some odd off-by-one errors due to certain special effects. For example, how are flat stat-bonus buffs like potions, trinket procs, flasks, and food incorporated into this? What about racial effects like Endurance, Heroic Presence, and Epicurean? So I set out to do some more testing.

Endurance was the easiest to test. Consulting our handy tables, all of the classes have 890 base stamina, and taurens get a racial modifier of +1. So before we choose a spec, our tauren paladin test subject (lovingly named Testbeef) should have 891 stamina. Instead…

There's some extra beef here...

There’s some extra beef here…

Endurance gives 197.055 stamina at level 100. The tooltip is, as usual, floored, but we can get an exact value directly from the spell data using Simulationcraft’s spell_query tool:

SimC to the rescue.

SimC to the rescue.

It’s clear from this that Endurance is being counted as base stamina by the game (890+1+197 = 1088). In other words, we can update our formula for $B$:

$B = \text{race_base}+\text{class_base}+\text{endurance}$

And it’s fairly simple to confirm that all of the other formulas work out to accurate values as given.

Next up is Heroic Presence, so we create a draenei paladin. It isn’t hard to determine how this works:

Heroic base strength.

The tooltip for Heroic Presence reads 65, but spell_query reveals that the actual value is 65.25. Draenei get a 1-point racial strength modifier, so it’s pretty clear that our base strength is just 1455+1+65=1521, meaning that Heroic Presence is also added into $B$:

$B = \text{race_base}+\text{class_base}+\text{endurance}+\text{heroic_presence}$

There’s one caveat here, which is that we can’t know for sure from this data whether Endurance or Heroic Presence are being floored before they’re added to $B$. Both of them have low enough decimal values that it would be unlikely to matter and difficult to test. Heroic Presence’s value was 130.5 several beta builds ago, and I was able to confirm that it isn’t being rounded (though that was unlikely anyway). But I couldn’t rule out a floor(). To do so now, we’d need modifiers such that $0.25\times \text{match}\times \text{multiplier} > 1$ to test Heroic Presence (or $0.055\times \text{match}\times \text{multiplier}>1$ for Endurance), which we don’t have. So it probably doesn’t matter very much, but it’s worth noting in case we find a situation where we can explicitly test that.

Epicurean was the most interesting test, because first we had to figure out how stat buffs worked. For example, is the amount of stat given by food floored or rounded? It turns out that by being clever, we can test both at once.

First, we searched through to find some foods that would be useful to us. The two we ended up using were Serpent Brew of Serenity and Hearty Elekk Steak. Serpent Brew has an intellect bonus of 24 according to the buff it grants. However, if we check the spell data…

Sneaky Sneaky

Sneaky Sneaky

… it apparently gives a buff of 23.816 intellect. Which is a strong case for flat stat bonus buffs being rounded, not floored, and making them the exception to just about everything else. We can double-check this by rolling a level 100 monk, using Zen Pilgrimage to visit Master Chang at the Peak of Serenity, and testing this:

I took off all of poor Foodtest's gear and didn't give her a spec to make this easier to see. I'm sort of a jerk like that.

I took off all of poor Foodtest’s gear and didn’t give her a spec to make this easier to see. I’m sort of a jerk like that.

This tells us that the buff is definitely rounded, not floored. Because there are only two ways to get 48 intellect from a 23.816-intellect buff on a pandaren, and neither of them involve a floor:

$F1 = \text{round}[~\text{food_stat}\times 2~]$
$F2 = \text{round}[~\text{food_stat}~]\times 2$

To figure out which one we have, we employ the new Hearty Elekk Steak, which is conveniently available from Savage Flaskataur, Esq. in Stormwind or Orgrimmar. This food is almost magical, in that the spell data says it grants a 187.49999 stamina buff. Even spell_query rounds this to 187.5, which led to a little confusion until we sussed out the issue. But what it means for us is that if $F1$ is correct, we’ll see a buff that’s 375 stamina on our pandaren, but if formula $F2$ is correct it will only be 374. And what is it?

The steaks are low.

So apparently, food buffs are rounded, and Epicurean is applied after the rounding occurs. It’s also fairly easy to test that these are affected by $\text{match}$ and $\text{multiplier}$ just like gear contributions are, so we can fold this directly into our definition of $G$:

$G = \text{gear_stat} + \text{round}[~\text{food_stat}~] \times \text{epicurean}$

Testing the others follows a similar process. Spell data tells us that a Flask of the Earth adds 170.926 stamina, but in-game both the tooltip and character sheet show that it grants 171 stamina. So flasks are clearly rounded as well. The Alchemy profession buff has already been turned off, so we can safely ignore that. A Potion of Mogu Power grants 455.793 strength according to spell data, but shows up as 456 in-game, suggesting that potions are also rounded. Testing with a few different trinket procs also showed that they were all rounded, not floored.

The one thing we haven’t shown yet is whether these effects are rounded individually or after-the-fact. The Epicurean data strongly suggests each is rounded independently, but a more rigorous test would be nice. To do so, we need a pair of buffs that give a different value when rounded separately than together – e.g. both ending in 0.5 or greater, or both ending between 0.25 and 0.49.

Digging through the spell data, we come up with Beer Basted Crocolisk, which grants 35.724 strength and stamina, and Flask of Steelskin, which grants 178.62 stamina. If we use both items, we should get 215 stamina if each is rounded individually, but only 214 stamina if they’re rounded after being added together. A few unlucky crocolisks later, we have our confirmation:

Only about four crocolisks were harmed during the filming of this test.

This is the last piece of the puzzle, and finishes confirming the equations given in the beginning of this post.

Closing Thoughts

You can see that we’ve done a pretty exhaustive job of testing edge cases to make sure our formula for base stats works correctly in all circumstances. If we were content to be accurate to within one point of stat, we could have stopped very early on. But it was important to me that the stats Simulationcraft spits out match your character sheet all the time. Ultimately that lack of accuracy reflects poorly on the sim, even if “off-by-one” errors have no significant effect on the overall simulation results.

And as you’ve now seen, trying to cover all of those edge cases often takes some careful thought about what those cases are and how you can test them. Often it means ruling out all but one hypothesis, and sometimes you need very specific items or gear combinations to distinguish between different hypotheses. Most combinations of food+flask wouldn’t reveal the difference between the two rounding schemes proposed, we had to seek out a very specific pair based on the numerical constraints of the problem.

But that’s the sort of work theorycrafters do – wading through the minutiae to build models that are as accurate as possible. And sometimes, even an “easy” task like calculating player attributes ends up having a ton of details that you never thought about before.

Posted in Theck's Pounding Headaches, Theorycrafting | Tagged , , , , , , | 10 Comments