In December, I talked about the code I’ve written to automate the testing of Simcraft profiles. In that post, I tackled the two easiest simulations to write: glyphs and talents. In both of those cases, we’re just editing a single line of the .simc file, so it was a fairly simple job of tweaking that line and repeating. Of course, there was the entire superstructure of code surrounding that idea, which is what took far longer than the (relatively) simple logic required to swap out talents and glyphs.
Today I present the results of the other end of the spectrum – one of the most difficult sims to write. Because today we’re going to look at rotations.
If you haven’t read the previous post, I recommend you go back and do so now. Or at least re-read the “Automating Simcraft” portion of it. I’ll refresh your memory about certain points, but I’m going to assume that you’re familiar with the basics of how this code operates. In short, if you don’t remember that we piece together a .simc file from discrete components (i.e. a player, a gear set, a rotation, a set of glyphs, a set of talents, etc.), then you should probably go re-read that section.
Note that I’ve taken to calling each of these components “blocks” in the rest of this post. That’s what I tend to call them in my head, and it’s faster than typing “component” over and over. Plus, I think it gives a nice visual – sort of like building the .simc file out of a bunch of different distinct Lego pieces.
You might ask what makes the rotation sim significantly harder than, say, a glyph sim. The short (and woefully incomplete) answer is that it involves changing more than one line of the .simc file we feed to the executable.
I say “woefully incomplete” because that statement encompasses a lot more than just swapping out a single component. For example, in the glyph simulation, we kept the same player block, gear block, rotation block, and so on, and just swapped out the glyph block. We did that by pre-generating a glyph block for all of the different glyph combinations we were interested in and cycling through them.
On its face, it seems like that same logic couldn’t apply to the rotation simulation. We could just generate 100 different rotation blocks that describe the different rotations we’re interested in, and then swap them in and out one by one to get the results. Right?
Wrong. Oh, so wrong…
That might work fine for a really simple rotation simulation where we only consider combinations of basic abilities. For example, we limit ourselves to Crusader Strike, Judgment, Avenger’s Shield, Holy Wrath, Hammer of Wrath, and Consecration. That would be enough to figure out the basic gist of the rotation, for sure.
But it should be obvious that this list is missing a few important abilities. What if we want to include Sacred Shield, or one of our level 90 talents? All of those have to go into the rotation somewhere. And the sim won’t use them unless we’ve talented them. So, first of all, that means we need to swap the talent block out at the same time as the rotation block. And not just that, but we need some way to know which talent block to use when – it’s no good if we use a talent block with Light’s Hammer when we’re testing Execution Sentence rotations. That seems like an obvious and trivial problem to solve, but it’s still an extra moving part we need to consider in a sim that’s already going to be pretty complicated.
Because it’s not just talents we need to worry about, either. Let’s say we want to look at execute-range rotations in particular. We might want to know if Holy Wrath changes priority when Final Wrath is glyphed. But to do that, we need to enable that glyph, or else use it by default. But there may be cases where we don’t want it on, either. So we need to be able to swap glyphs too.
Further, we need to be able to specify conditionals in the action priority list (APL). So that, for example, we can compare
Now, of course, that’s not really a problem in theory, because we could just write each block by hand and take care of all of that. But we might have hundreds of rotations, and the risk of making a small, unnoticed but relevant error in one of them is pretty high when you’re talking about writing that many by hand. Also, if you really expected me to write hundreds of rotation files by hand, you’re kidding yourself.
We’ll still need a good shorthand for it for identifying rotations on tables anyway, and if you’re going to write a robust shorthand, then you may as well automatically generate the rotation blocks from that shorthand. That gives us the consistency we want (because there will never be an error in “HW” in one file that doesn’t exist everywhere else) and makes tables easy to read. But it adds another complication: now we need to write a translator that goes between shorthand and full SimC file, complete with all of the options and conditionals we might want to use.
You can already see why this snowballed into one of the more complicated sims to write. And it’s not even necessarily the hardest – the AoE one may be more annoying still depending on what exactly we want to calculate!
The Nitty Gritty Details
So, in short, this is how the simulation works. I’ve divided the rotations we care about up into groups (which, in a sad turn of events, I’ve called “blocks” in the code…. oops? I’ll be consistent about calling them “groups” here though). Each group has a defined set of talents and glyphs, because for the most part those vary on a group level. So there’s a “Basic” group, an “Execute” group that focuses on Hammer of Wrath and Final Wrath, a “Defensive” group that’s primarily for testing Sacred Shield, and a “Level 90″ group that tests all the level 90 talents.
In addition, I have the ability to enable custom talents per rotation. So for example, within the Level 90 group, it will automatically check each rotation to see which level 90 talent it uses and tweak the talent block to enable that talent. It also does this for the Sacred Shield rotations in the Defensive group. I signify this by adding “+custom” to the end of the talent block, which is the flag the code looks for to decide whether it needs to perform this check.
In theory I could do the same thing with glyphs, I suppose, but I found that I didn’t really need to. It wouldn’t be difficult to modify the code to do that in the future if we decide it’s necessary.
The rest of the difficulty was coming up with the abbreviation scheme for abilities and their conditionals. Thinking ahead, I wanted this to be extendable to other classes, so I set it up such that each class can have its own definitions. For a paladin, CS will always mean Crusader Strike, but if we’re simming another class it could translate to something different.
The abilities were fairly easy, since I’ve been using a standard notation for them in the old MATLAB code for years. They are:
|CSw||Crusader Strike followed by a /wait (see below)|
|HotR||Hammer of the Righteous|
|HoW||Hammer of Wrath|
|SotR||Shield of the Righteous|
|WoG||Word of Glory|
In the earlier code, we used a bracketing technique for options, which was very powerful, but led to really long rotation names.This time around, I’m trying to keep the names fairly compact for display purposes, so I went with a slightly different method. Each option has a shorthand and gets appended to the ability shorthand with a plus sign (‘+’). The options I have enabled at this point are:
|W#||add a /wait after the ability if the cooldown is less than or equal to # seconds|
|GC#||buff.grand_crusader.up or buff.grand_crusader.remains<#|
So for example, AS+GC would translate into
Not all of these are in use in the data I’ll present today, but they’re all coded and potentially usable. I expect that we’ll add a bunch of action priority lists to the simulation after we’ve analyzed the results in this post. For example, it might be interesting to see if “Cons+nt” has any effect, but it wasn’t high on my list of priorities when I was putting this together so I didn’t include it.
There’s one special case I want to mention. The “wait” conditional works something like this: CS+W0.35 translates to:
As you might expect from the default APL for protection, this almost always nets an increase in holy power generation because it prevents us from doing silly things like CS-X-X-X-CS. That can otherwise happen in situations where one or more of the X’s were spells, so the GCD ends a little before CS becomes available. As a result, we’ll almost always want to follow CS with a wait. Since that comes up a lot, and I didn’t want to type CS+W0.35 all the time in the interest of keeping the rotation abbreviations short and readable, I’ve defined the shorthand “CSw” to implicitly mean “CS+W0.35″
As a final note, I want to mention that this simulation is limited to GCD-based abilities. In other words, I’m using the same precombat actions and the same finishers in each rotation. I’m basically bolting the rotations below together with the precombat actions and the following default finisher definitions:
This ensures that the changes we see are purely due to any change in holy power generation or dead time in the rotations themselves. And in any event, since our active mitigation is decoupled from the GCD, it’s not really part of our “rotation” in a strict sense. It’s stuff we use when necessary and available based on the resources, not based on whether they’re more or less important than e.g. CS. We’ll analyze the finisher options specifically in a later sim in much the same way we do here for the rotation. Luckily, that sim will be a lot easier to write!
All of the results can be found in the /io/ directory, along with the results of the glyph and talent simulations. The sims are labeled appropriately with “>” replaced by “_”.
We’ll go through each of the rotation groups one at a time, briefly discussing what makes them unique and why we’ve made the choices we have.They all use the default T16N profile gear set (which includes 4T16) and are pitted against the T16N25 TMI calibration boss. The default talents include Unbreakable Spirit, Eternal Flame, and Divine Purpose unless otherwise specified. Everything else should be provided in the details below.
I’ll note that for all of these simulations, I’ve set the number of iterations to 250k. Yes, that’s a lot, but it’s necessary to get the degree of accuracy we want.
The “DPS Error” that Simulationcraft reports is really the half-width of the 95% confidence interval (CI). In other words, it is 1.96 times the standard error of the mean. To put that another way, we feel that there’s a 95% chance that the actual mean DPS of a particular simulation is within +/- DPS_Error of the mean reported by that simulation. There are some caveats to this statement, insofar as it makes some reasonably good but not air-tight assumptions about the data, but it’s pretty good.
I’m actually doing a little statistical analysis on SimC results right now to investigate some deviations from this prediction, but that’s enough material for another blog post, so I won’t go into more detail yet. What it means for us, though, is that in practice I’ve found that when you run the sim for a large number of iterations (i.e. 50k or more) the reported confidence interval tends to be a little narrower than the observed confidence interval you get by calculating it from the data.
So for example, at 250k iterations we regularly get a DPS Error of approximately 40. In theory that means we feel pretty confident that the DPS we found is within +/-40 of the true value. In practice, it might be closer to +/- 100 or so.
Why does that matter for us? Well, we want to know if one rotation is better than another in a statistically significant sense. Based on the theoretical estimate, this means that as long as they’re farther apart than 80 DPS, we can trust that the higher-DPS rotation is better. In practice, I think we should expand that bound a bit, at least to 100 DPS, and probably to 200 DPS if we’re going to be generous and assume that there could be other sources of systematic error that we don’t know about. I’ve seen the same rotation sim up to 300 DPS differently from two separate runs, so I’m inclined to be a little more generous in my error estimate than SimC is.
And keep in mind that we’re looking at a mean value of almost 400k DPS in these sims. 400 DPS is a change of 0.1%, which is miniscule, and not likely to swing an encounter one way or another. Even if our sims are accurate to that level, that’s right around the point where you prioritize mental bandwidth over DPS gain and choose the rotation that’s simpler to execute. So I’d probably be hesitant to ascribe any real significance to differences that are smaller than 1000 DPS, which is still less than a 1% change.
Basic Rotation Group
This group of rotations is focused on determining the order of operations for our basic abilities, excluding talents and execute range. From this, we determine our “ideal” base rotation, which we then go about tweaking in the other groups.
In this set, we use just two glyphs: Focused Shield and Word of Glory. We could have included Divine Protection, but we want to be able to compare the survivability results to those obtained in later groups which use all three glyph slots on DPS glyphs. Plus, there’s really not a lot to learn from glyphing Divine Protection here. It’s our only feasible survivability glyph and it’s so highly situational that there’s no guarantee we’re using it for a given boss.
In addition to the table, the sim spits out the maximum DPS Error measurement of the group (each rotation is fairly similar in that regard, so it didn’t make sense to include it on the table) and the talents and glyphs used:
Max DPS Error: 41
Note that you can sort the table by a particular column by simply clicking on that column’s header. The “Var” column simply reports the measurement of “TMI Error,” which is really more of an uncertainty or variance measure due to the nature of the TMI distribution. Basically, treat that column as the +/- on the measured TMI value. The “Wait” column tells us how much time the sim spends waiting while the GCD is available, either because there’s nothing to cast or because we’re hitting the /wait action.
Before sorting, it’s clear that waiting for CS’s cooldown to come up is a significant survivability gain. The more subtle thing to notice is that it’s actually a slight DPS loss, mostly because CS hits like a limp noodle. There are a number of reasons for that, but the primary one is that CS’s damage increases far more slowly with attack power than the rest of our abilities do. So the higher Vengeance gets, the worse CS is compared to just about everything else we could cast.
A lot of the features here are expected. Dropping CSw below anything else in priority gives you a large survivability loss. It’s worth noting that the “CSw>AS+GC>J>*” rotations near the bottom produce some very low TMI results, but I’m still a bit skeptical of these. The SotR uptime isn’t any higher than the default (CSw>J>AS>HW>Cons), nor are the TMI values lower in a statistically significant sense.
If we sort by DPS, we see that the top rotation is actually the one where we don’t wait for CS’s cooldown, again because CS is such a weak ability at this point. But after that one, we have a bunch of rotations that emphasize AS in various ways. This can be summarized with a pretty simple rule of thumb: “if you don’t care about survivability and need max DPS right now, prioritize AS.”
There are a bunch of rotations where I push Holy Wrath up ahead of CS/J/AS. These aren’t interesting from a survivability point of view, because they uniformly increase our TMI. They also seem to uniformly reduce DPS compared to the standard CSw>J>AS>HW>Cons. We’ll have to revisit these in the execute range group where we have Final Wrath glyphed, which is where we might expect a high HW prioritization to bear fruit.
The HotR rotation I threw in has the same wait as CSw, so it’s directly comparable to a CSw rotation. This is really only relevant in cases where you want to know how much single-target damage you’re sacrificing to cleave to adds now that Weakened Blows is applied by both abilities. Nonetheless, we see it’s about a 1700 DPS loss to use HotR instead of CS. Not really a big deal in the grand scheme of things, we’re talking about less than a 1% difference. CS and HotR both hit so weakly it’s almost irrelevant which you use.
I also want to call attention to the TMI and Var columns again quickly. If you sort by either of these, you’ll see that as TMI goes up, so does the variance. This is one significant drawback of the current TMI formula – because it’s an exponential metric, the variance tends to be rather large when TMI is large. Increasing the number of iterations doesn’t end up helping it much, because it’s just not anything resembling a Gaussian distribution.
The two take-home messages I want to get across here are:
- Unless two TMI values differ by more than the sum of their Var columns, it’s not 100% clear that they’re different in a statistically significant sense. So TMIs of 400 and 500 are roughly identical if their Vars are 100 or more, but you could safely say that a TMI of 400 is better than e.g. a TMI of 1000. We’re looking for order-of-magnitude effects in TMI, because that’s how the metric was constructed.
- This will be fixed in TMI v2.0, which I’m working on currently. More on that soon, maybe next week if I have time to write.
Next, let’s look at the execute rotations.
Execute Rotation Group
In this case, we want to find out how we vary the basic CSw>J>AS>HW>Cons rotation in execute range. That means we need to know where to slot in Hammer of Wrath and what (if anything) to do about Holy Wrath when Final Wrath is glyphed.
Since we can already look at the table above to figure out what happens when Final Wrath isn’t glyphed, this group includes it by default along with Focused Shield and Word of Glory.
Max DPS Error: 41
We can clearly see that Hammer of Wrath should slot in ahead of Consecration but behind Holy Wrath. TMI values vary somewhat depending on how far ahead of other abilities you put it, but note that HoW>J and J>HoW don’t differ much because both are 6-second cooldowns, so they don’t generally clash all that often.
However, if we push HoW ahead of CSw we get a significant TMI increase without realizing any sort of DPS gain compared to slotting it behind Holy Wrath. This is a little different than the results we got with the old MATLAB sims in 5.2, which suggested HoW was a DPS increase at the top of the priority queue. My guess is that the change is due to two factors: switching our L45 talent from SS to EF and losing Grand Crusader procs.
In 5.2, we had fewer empty GCDs because we’d be refreshing Sacred Shield every 30 seconds and using up more Grand Crusdaer procs, which ended up leaving less room for Hammer of Wrath and other fillers. Now, we have a larger number of empty GCDs to work with, so using Hammer of Wrath doesn’t necessarily push another filler back multiple cycles. And since we have those extra GCDs more regularly, it’s not worth pushing it ahead of the basic CS-J cycle; it’s just more efficient to slot it back in wherever it fits without delaying heavy-hitters like AS and Final-Wrath-Glyphed Holy Wrath (can we just call it “Final Wrath” in execute range?).
Speaking of Final Wrath, it looks like that does hit hard enough to be a DPS increase at the front of the queue, for relatively little cost in TMI. The CSw>J>AS+GC>HW+FW>AS>HW>HoW>Cons rotation is particularly interesting in that it gives you a small (~300) DPS boost without sacrificing any holy power generation. But at the same time that difference is right at (or below) our error threshold, so it’s not clear that’s a realizable gain. By the time we’re looking at 0.1% DPS increases, we’re splitting more hairs than we probably should.
So the conclusion here seems to be that the filler order ought to be HW>HoW>Cons, and during execute range you can prioritize “Final Wrath” as high as you want for a DPS gain, realizing that you’re sacrificing a little survivability if you use it instead of a holy power generator.
Next up: Defensive rotations.
Defensive Rotation Group
While I called this the “Defensive” category, it should really just be called the “Sacred Shield” category, since that’s the only defensive spell in here. And with EF being so strong in Siege of Orgrimmar, it’s also mostly irrelevant. But I’m including it for completeness, and to highlight how strong EF really works out to be.
One oversight here is that this group doesn’t take advantage of the T16 4-piece. The default finisher block has lines for SotR usage and Eternal Flame maintenance, but there’s nothing in there for Word of Glory. As a result, we expect to see a drop in SotR uptime corresponding to losing the 4-piece bonus, as well as an increase in TMI. In the future, I’ll be adding a line like this:
which should appropriately use WoG whenever we have 3 stacks of the 4T16 buff to fish for extra Divine Purpose procs. For now, just keep in mind that the results in this group aren’t strictly comparable to the ones with EF for survivability purposes. However, they should still be accurate for comparing the SS rotations against one another if you’re hell-bent on running Sacred Shield.
Max DPS Error: 41
First, notice that all of the TMI values on this table are in the 100k range, compared to ~400 when we use Eternal Flame. Some of that is the utter dominance of EF over SS at high AP/Vengeance, some of it is because the Shield of the Righteous uptime is lower by a few percent because we’re no longer leveraging the 4-piece bonus. Note that our SotR uptime is a little higher here than the ~64% range we saw in the 4T16 post; we’re averaging around 69% instead.
You might wonder why that is – after all, in that earlier post we said the 4T16 benefit is about 10% SotR uptime, and we’re not taking advantage of the 4-piece in this group of sims. However, when we talent Sacred Shield we also don’t have to maintain Eternal Flame, which means we can spend that holy power on SotR instead, making up about half of the difference. If we were fishing for extra DP procs with Word of Glory, SotR uptime should actually catch up to what we get with Eternal Flame.
In any event, there’s not a lot to say here. TMI obviously improves as we increase the priority of refreshing SS (“SS+R1″ means “refresh SS if it’s got less than 1 second left”), but there’s no advantage to putting it ahead of CS or J. I added the CSw>J>AS+GC>SS+R1>AS>HW>HoW>Cons option at the last minute on a hunch, as I suspected that would truly be the low-TMI option after looking at the rest of the results, and it paid off. I’m not entirely sure why this performs better than the identical rotation with an exra “>SS” tacked onto the end though. It’s clear that it’s causing some kind of holy power generation loss based on the SotR uptimes, but I don’t really see how. Something to investigate for later, I guess.
I also want to draw attention to the fact that refreshing it at 2 seconds early seems to be the sweet spot. One second puts it off long enough that sometimes you get short gaps due to the GCD. Three seconds or longer tends to be no more effective than two seconds. I don’t know offhand why the SS+R3 version scored so poorly, but again, it could just be RNG given the Var column is nearly 3000.
That’s enough about Sacred Shield, let’s move on to the level 90 talents.
Talent Rotations Group
This is the fun group, where we make use of our “+custom” talent flag. Basically, we’re just swapping the L90 talent appropriately so that we have the ability the rotation calls for.
There are two things we’re checking for in this sim. First, what’s the “default” place to slot each talent into the rotation, ignoring what section of the encounter we’re in. Then, we want to try and fine-tune that by specifying execute rotations to see if there’s an advantage to increasing the priority during execute. We might care about that because once Hammer of Wrath becomes available, we don’t have that many empty GCDs to work with, so we could inadvertently ignore a L90 talent (or at least delay it for a long time) if we slot it behind Hammer of Wrath.
I’ve decided to split this group up into three tables for ease of filtering/sorting.
Max DPS Error: 41
First, it’s clear that Execution Sentence is our damage option, with Holy Prism trailing it slightly and Light’s Hammer coming in at a close third place.
Execution Sentence seems to be a toss-up with Hammer of Wrath initially, with them neck and neck at around 407k DPS. But the ES>HoW version is far enough ahead that I’m willing to believe it’s a little better, but again, we’re talking about differences that are right on the boundary of our error level. Still, level 90 talents are more fun than Hammer of Wrath, and when two rotations come this close in DPS that’s as good a criterion as any. This basically boils down to “ES>HoW” during execute range, since outside of execute the two rotations are identical. In other words, the ES rotation should be:
None of the tweaked versions that prioritize things differently in execute range give us a significant improvement over that rotation, so we can rule them out.
Curiously, with LH we would be lead to believe that prioritizing it above AS, J, or even CS is a DPS increase. That doesn’t make a lot of sense though: ES hits harder, yet those rotations didn’t exhibit this same behavior. At this point, I’m inclined to believe that something fishy is going on here. I’d call it an outlier, even though it’s several hundred DPS ahead of some of the other options, but it’s not just one rotation. All three of the rotations with LH near the top show the same effect. I’m not sure why that’s happening yet.
That said, if we ignore those three, perhaps on the grounds that it’s a HPG loss, then the same rotation that maximizes Execution Sentence is the best choice here as well. The CS>J>AS>HW>LH>HoW>Cons rotation is the strongest performer when we’re not putting LH above holy power generators. Though again, the difference between that rotation and LH>HW>HoW or HW>HoW>LH is so small that any of them would be fine.
Holy Prism is an odd duck. It seems to enjoy – no, relish even – hanging out in the last spot. Moving it anywhere higher in the queue is a loss of 800 DPS or more, a large enough gap that we can feel pretty certain it’s statistically significant. Even playing some execute-range tricks with it doesn’t help.
This is actually pretty easy to explain. Consider the following three charts of damage per execute time (DPET) for the rotations CSw>J>AS>HW>HoW>Cons>L90:
Note that the DPET on Execution Sentence is far higher than any of our other spells, which is why it’s worth prioritizing ahead of HoW and Cons. The only reason it isn’t worth pushing higher in the queue is that we have enough gaps in our rotation that it’s better to use high-damage, low-cooldown spells like Holy Wrath first to minimize empty GCDs.
The DPET on Light’s Hammer is lower than ES, but still above everything else, so most of the same logic applies. Again, with the weird unexplained exceptions that we talked about earlier, which I’m likely chalking up to error (either in the LH results or in the ES results – I’m not really sure which!).
But the DPET on Holy Prism is only on par with Hammer of Wrath and Consecration. This is mostly because it doesn’t scale as well with attack power as the other Level 90 options. Or to state that more precisely, the spell’s attack power coefficient is similar to that of Consecration and Hammer of Wrath (all around 0.7ish, I believe), so in the high-Vengeance regime they all do about the same damage. Light’s Hammer and Execution Sentence have significantly larger attack power coefficients, and thus do a lot more damage in that regime.
Now, it’s worth noting that this doesn’t mean Holy Prism is badly balanced. The cooldown of Holy Prism is only 20 seconds, compared to 60 seconds for ES and LH. In theory, you could get 3 casts of Holy Prism off in the same time that you cast one of either of the other level 90 talents. And those three Holy Prisms would total more damage than a single LH cast, though less than a single ES.
But those three Holy Prisms also cost three GCDs to the single GCD used by LH or ES. And that hurts Holy Prism in the “rotation priority” department, because it means we’re far more likely to be pushing something else back, effectively extending the cooldown of another spell and cutting into the DPS gain.
And if you have three spells that do very similar amounts of damage, one with a sub-6-second cooldown (HoW), one with a sub-9-second cooldown (Cons), and one with a 20-second cooldown (HPr), which one do you use first? Generally speaking, the ones with the shortest cooldown, because you usually lose less DPS by pushing the long-cooldown spell back than you do by pushing the short-cooldown spells back. See Wrath-era Retribution theorycrafting for another example of this, where Crusader Strike was prioritized over harder-hitting spells simply because its cooldown was much shorter.
Another reason for the discrepancy in DPET (and DPS) in our L90 talents is that LH and Holy Prism have some utility that they’re being balanced around. Both spells do a good bit of healing. Light’s Hammer works a lot like a raid cooldown, while Holy Prism does less of it but does it up-front. Holy Prism also has availability going for it, in that you can use it more frequently – something that anyone who’s tried to pick up a group of loose adds will recognize as a life saver.
In any event, that was a slight tangent; the take-home message of this last table is that Holy Prism gets to bring up the rear in our priority list.
This was an incredibly long post, and I didn’t even begin to go over the results in the sort of detail that I could given more time. But I’m pretty sure I hit most of the more important things. Still, it’s worth summarizing what we learned, or at least reinforced.
From this data, we’d ideally want to follow this rotation:
with the caveat that I’m obviously assuming you’re taking Eternal Flame instead of Sacred Shield, that you’re not doing any fancy Holy Wrath prioritization during execute range, that you’re glyphing Focused Shield and Glyph of Word of Glory, and that you’re ignoring whichever two talents you don’t currently have chosen.
We know that not waiting up to about a third of a second for CS to come off of cooldown is a notable DPS gain, as is prioritizing Avenger’s Shield. In both of those cases we suffer a noticeable decrease in survivability, however.
We also know that it’s a small DPS gain to push Holy Wrath higher in the queue during execute range if we’re using the Final Wrath glyph, but that this comes with a small survivability loss as well.
We know that if we’re taking Sacred Shield, we want to slot it in somewhere in the filler section to refresh it when the duration is almost up. It should probably be a gain to tack it on to the end of the queue to fill an empty GCD as well, but the data is inconclusive here, so the jury’s still out on that one.
And of course the Level 90 talent results are already incorporated into the rotation given above.
It’s also worth noting what we didn’t check here and to be clear about the limitations of this data set. We haven’t attempted to try any additional L75 talent options, so all we have is Divine Purpose data. Holy Avenger shouldn’t vary things too much, insofar as most of HA’s effect is simply more off-GCD SotR spammage. But it could cause rotations that try to increase DPS by prioritizing something over a holy power generator to fail miserably because each holy power generator is basically adding 2/3 of a SotR in damage during HA. On the other hand, they’re also less effective outside of HA than they would be with Divine Purpose, so who knows! Note also that we’re tanking the boss full-time here, so the effective uptime of Holy Avenger isn’t being considered.
Likewise, we didn’t test how Sanctified Wrath affects things. We’re already fairly sure that pushes a J+SW up ahead of CSw in priority, but we don’t know if it changes filler priority at all. Those are all on the list of things to add for next time.
We’re also simming the most bland encounter possible: solo-tanking Patchwerk forever. There’s no movement, no sudden or predictable damage bursts from a boss special, no significant variation in damage patterns (i.e. it’s a steady stream of melee+DoT damage, not an oscillating pattern of heavy melee followed by heavy magic followed by heavy melee and so on…). Basically none of the things that make real encounters interesting.
So keep that in mind when interpreting the results. I may say “this data suggests X is better than Y,” but I’m always doing that within the context of this particular set of constraints. It’s reasonable to assume that it generalizes fairly well to other situations, but it won’t always, and it’s almost certainly not going to be iron-clad enough to be correct for every encounter.
As usual, a smart tank should be looking for those inconsistencies and adapting their play to the encounter rather than blindly relying on “but Theck said so!”