5.1 Warrior Simulations – Part 2 – Rotations

Last time, we went over the model we’ll be using to evaluate different rotations and looked at some basic queues.  We decided that we’d use the SB and SBr* queues (“Spam Shield Block” and “Spam Shield Barrier,” more or less) as our gold standard for comparison.  Hopefully, some of the more sophisticated queues that utilize both Shield Barrier and Shield Block will improve over these basic queues in one way or another.

Before we start, I want to mention that I’ve made slight modifications to the files since the last post.  The only difference is that I’ve greatly expanded the versatility of the finisher code – rather than hard-coding each finisher priority, I now use regular expressions to construct them dynamically.  So if you’re fooling with the code, you may want to grab revision 550 (warr_mc.m, warr_mc_finishers.m).

Just to reiterate the meaning of the statistics that you’ll be seeing in the tables below:

S% is our Shield Block uptime in decimal form (ex: 0.6667=66.67%)
mean is our mean damage intake in percentage of maximum DTPS.
std is the standard deviation of damage intake for a 5-attack moving average
SBr(k) is the total number of Shield Barrier casts, in thousandsSBr<60(k) is the number of Shield Barrier casts at less than 60 rage, in thousands
RPS is our rage generation rate (i.e. X rage per second)
xsR(k) is the amount of excess rage, in thousands

Note that all of these are for 10,000 minutes of combat, which is why we’re counting in thousands for many of these metrics.  In addition, we have two spike damage metrics:

80% is the percentage of spikes that are above 80% maximum throughput
90% is the percentage of spikes that are above 90% maximum throughput

I’ve calculated both spike metrics for strings of 2 attacks in a row to 7 attacks in a row and everything in-between.  If you see me use shorthand like “90% events for 4-attack strings,” it means we’re looking at what percentage of all 4-attack strings fell above 90% of maximum throughput – in other words, how many times did we take 4 attacks in a row that summed to 90% of 4 full hits.

Also note that the 90% metric is a subset of the 80% metric.  In other words, the 80% category tells us about all of the events above 80% throughput, which necessarily includes all of the 90% events too.  If we want to know how many events fall between 80% and 90%, we have to subtract the number in the “90%” row from the number in the “80%” row.  In other words, if we have a queue that gives us the following data:

80%: 5.0
90%: 2.5

It means that 5% of all events exceeded 80% throughput, 2.5% of all events exceeded 90% throughput, and therefore 5.0-2.5=2.5% of all events were between 80% and 90%.

So, with all of that said, let’s start looking at queues.

Bleed Queues

The “bleed” category of queues was inspired by my earliest attempt at combining Shield Block and Shield Barrier. The idea was to simply use Shield Barrier as a “bleed valve” for excess rage beyond what was necessary to maintain Shield Block. Subsequently, the logic for these queues is pretty simple:

  • B-100 tries to cast Shield Block on cooldown, and will cast Shield Barrier any time rage exceeds 100 (after trying to cast Shield Block first, obviously)
  • B-105 through B-120 are identical except for having a higher rage-bleed threshold.

Let’s see what adding a bleed valve to Shield Block accomplishes:

|      Set: |       SB |     SBr* |   B-100 |   B-105 |   B-110 |   B-115 |    B-120 |
|        S% |   0.6667 |   0.0000 |  0.6667 |  0.6667 |  0.6667 |  0.6667 |   0.6667 |
|      mean |   0.5852 |   0.4144 |  0.5152 |  0.5139 |  0.5144 |  0.5202 |   0.5276 |
|       std |   0.1394 |   0.2029 |  0.1909 |  0.1924 |  0.1932 |  0.1941 |   0.1929 |
|    SBr(k) |   0.0000 | 100.0000 | 14.4770 | 14.4240 | 14.0260 | 12.9640 |  11.4290 |
| SBr<60(k) |   0.0000 |  66.0780 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |   0.0000 |
|       RPS |   8.1018 |   7.3681 |  8.1171 |  8.1267 |  8.1314 |  8.1233 |   8.1168 |
|    xsR(k) | 860.9650 |   0.0000 |  1.5100 | 10.4890 | 37.2100 | 96.0460 | 184.1910 |
|    ------ |    --- 2 |   Attack |  Moving | Average |  ------ |  ------ |   ------ |
|       80% |  23.3400 |  17.1937 | 18.3660 | 18.5260 | 18.8710 | 19.7318 |  20.5240 |
|       90% |   8.0145 |   8.4785 |  6.2952 |  6.1865 |  6.2670 |  6.6265 |   7.0230 |
|    ------ |    --- 3 |   Attack |  Moving | Average |  ------ |  ------ |   ------ |
|       80% |   9.1480 |   5.5260 |  7.1965 |  7.1465 |  7.2642 |  7.7650 |   8.2138 |
|       90% |   0.0003 |   3.9580 |  0.4938 |  0.2680 |  0.1538 |  0.1130 |   0.0800 |
|    ------ |    --- 4 |   Attack |  Moving | Average |  ------ |  ------ |   ------ |
|       80% |   7.8452 |   2.1927 |  6.3350 |  6.2198 |  6.2600 |  6.6950 |   6.9975 |
|       90% |   0.0005 |   0.0000 |  0.6302 |  0.3563 |  0.2053 |  0.1538 |   0.1080 |
|    ------ |    --- 5 |   Attack |  Moving | Average |  ------ |  ------ |   ------ |
|       80% |   5.9655 |   1.9955 |  4.9975 |  4.8215 |  4.7722 |  5.1018 |   5.2975 |
|       90% |   0.0000 |   0.0000 |  0.1505 |  0.0703 |  0.0460 |  0.0350 |   0.0313 |
|    ------ |    --- 6 |   Attack |  Moving | Average |  ------ |  ------ |   ------ |
|       80% |   0.0005 |   1.0360 |  0.5940 |  0.3290 |  0.1935 |  0.1495 |   0.0950 |
|       90% |   0.0000 |   0.0000 |  0.0010 |  0.0005 |  0.0000 |  0.0030 |   0.0047 |
|    ------ |    --- 7 |   Attack |  Moving | Average |  ------ |  ------ |   ------ |
|       80% |   1.1823 |   0.4202 |  1.2530 |  1.0570 |  0.9883 |  1.0565 |   1.0500 |
|       90% |   0.0000 |   0.0030 |  0.0010 |  0.0008 |  0.0000 |  0.0017 |   0.0030 |

The bleed queues eliminate a lot of the excess rage that SB can’t do anything with, and obviously give lower mean damage intake (around 12% or so for B-100 and B-105). They all maintain maximum Shield Block uptime, however, and subsequently don’t have a large effect on rage generation. And of course, all of the Shield Barrier casts are at 60 rage, as expected. As the bleed valve threshold increases, it becomes less effective at both mitigating damage and using up excess rage. But in any event, they’re all definitely an improvement over SB in TDR and rage utilization.

However, the real problem with these queues is in the spike damage category. They perform slightly better for 2-attack strings, but they’re worse at strings of 3 attacks or more. We’ve reduced the number of spikes that exceed 80% spikes compared to SB, but the majority of those spikes are more deadly 90% spikes (~4% out of 5.5%). At the 5-attack level or higher it’s not a huge problem, but 0.2% of the time is still about twice in 2 hours of boss attempts (probably reasonable estimate of time spent on-boss for a 4-hour raid night where you’re solely working on a progression kill).  And it doesn’t get any better for longer queues – they’re strictly worse for 6-attack strings, and not significantly different from SB for 7-attack strings.

The sweet spot for the bleed valve seems to be around 110 rage – you get the largest reduction in 80% spikes across all string lengths and aren’t giving up quite as much in the 90% department as you would at lower rage settings.  Higher rage setting seem to be a little stronger for long 90% spikes, but permit more spikes overall.

But how could spending otherwise-wasted rage on Shield Barrier possibly make you less survivable? The answer is surprisingly straightforward: spending rage on Shield Barrier ends up pushing back Shield Block casts and subsequently creating gaps in your Shield Block coverage that exceed 3 seconds. If rage generation was higher, this problem wouldn’t manifest itself. However, maximum rage generation tops out at around 8.12 RPS, and 6.67 of that is necessary to maintain Shield Block. That only leaves about 1.5 RPS for Shield Barrier casts.

One might naively assume that we could spend that excess rage without affecting Shield Block uptime if we were careful, meaning we only tried to cast a Shield Barrier every 40 seconds on average. It turns out that’s not the case. Consider what happens if we cast a generator and reach exactly 120 rage, triggering our bleed valve. We drop 60 rage on a Shield Barrier, dropping us to 60 rage. We then cast a Shield Block that drops us to zero. In theory, it should only take us about 60/8.12=7.4 seconds to generate the next 60 rage for Shield Block, which should be fast enough.

But we don’t get rage in a steady stream, it comes in discrete chunks at variable intervals due to Sword and Board and Revenge procs. So while that might work out some of the time, some of the time we’ll get an unlucky streak and get only 40 rage from Shield Slams and about 2 rage from Defensive Stance. And when that happens, the next Shield Block is delayed slightly. Thanks to the charge mechanism, we’re still able to maintain maximum Shield Block uptime in these situations, but what it does is create cases where we have almost 12 seconds of continuous Shield Block uptime followed by a 5-6 second gap. And that 5-6 second gap is deadly, because we leave ourselves open to larger spikes.

Another issue with these bleed queues is that they tend to cast Shield Barrier when we need it least. We’re unlikely to get to 100+ rage shortly after dumping 60 into a Shield Block, so that means we’re generally casting Shield Barrier after we’ve had some time to pool rage, which means we cast it right before we cast Shield Block. We’re doubling up our protection, which isn’t a good smoothing strategy. It would make a lot more sense if we could try to prioritize Shield Barrier casts in such a way as to slip them in when Shield Block isn’t active – i.e. to weave them in-between Shield Block buffs. This leads to a new set of strategies, which we’ll call “weave” queues.

Weave Queues

The goal of a “weave” queue is to come up with conditionals that produce a Shield Barrier cast in the gaps in our Shield Block coverage.  Ideally, we want to try and cast a low-rage Shield Barrier when Shield Block falls off to tide us over until the next Shield Block.  Doing so is a little trickier than it sounds.  If we use a simple queue like “Cast Shield Block if rage>60, else cast Shield Barrier if rage>20,” we’ll end up spamming Shield Barrier most of the time rather than successfully weaving the two.  We also know that if we cast a 60-rage Shield Barrier right before a Shield Block charge becomes available, we’ll end up pushing Shield Block back further, which is likely to be counter-productive.

To avoid the “spam Shield Barrier” problem, we want a conditional that prevents us from casting Shield Barrier if a Shield Block charge is available.  Strengthening that condition a little bit allows us to bypass the second problem.  We introduce the idea of a “lockout” period during which we’re not allowed to cast Shield Barrier.  The lockout period is keyed to the availability of Shield Block charges: basically, a lockout period of X seconds means that we can’t cast Shield Barrier if a Shield Block charge will become available in the next X seconds.  That’s simple enough, and gives us a knob we can turn to see exactly how long the ideal lockout period should be.

Remember that the goal was to weave these in-between Shield Block casts.  With just the conditionals above, we could run into situations where we gain a bunch of rage quickly, cast Shield Block, and then cast Shield Barrier with the extra rage during Shield Block’s duration.  Since we don’t want to do that, we’ll add another lockout condition: we aren’t allowed to cast Shield Barrier if the Shield Block buff is active.  That should successfully limit us to truly “weaving” our Shield Barrier casts instead of stacking them with Shield Block.  Finally, we’ll also add a lockout condition for Shield Barrier on itself, so we don’t overwrite the buff.  Since our Barrier casts will be confined to 3-second periods of Shield Block downtime, buff overwriting is just going to waste rage.

Thus, here’s the short form of the conditionals for the “weave” strategies:

  • WX tries to cast Shield Block on cooldown, and will cast Shield Barrier if
      • Rage is >= 20
      • A Shield Block charge will not be available in the next X seconds
      • Shield Block’s defensive buff is not active
      • Shield Barrier’s defensive buff is not active

And we’ll let X take on values of 4, 3, 2, and 1.  A value of 0 would be almost like removing the lockout entirely (but not exactly – more on that in a later section), which we’re pretty sure we don’t want to do.  1 is almost as bad, in that it’s less than a full GCD, but we’ll give it a whirl anyway.  Increasing the lockout further is simply playing more conservatively, in an attempt to minimize Shield Block pushback.  Now that we have the logic figured out, let’s see how these queues pan out:

|      Set: |       SB |     SBr* |       W4 |      W3 |      W2 |      W1 |
|        S% |   0.6667 |   0.0000 |   0.6667 |  0.6665 |  0.6664 |  0.6659 |
|      mean |   0.5855 |   0.4159 |   0.5853 |  0.5154 |  0.5150 |  0.5143 |
|       std |   0.1387 |   0.2025 |   0.1389 |  0.1756 |  0.1758 |  0.1761 |
|    SBr(k) |   0.0000 | 100.0000 |   0.0000 | 17.1190 | 17.4090 | 18.4490 |
| SBr<60(k) |   0.0000 |  66.1670 |   0.0000 |  6.9420 |  7.6780 |  9.9900 |
|       RPS |   8.1070 |   7.3617 |   8.1074 |  8.1144 |  8.1128 |  8.1145 |
|    xsR(k) | 864.0440 |   0.0000 | 864.2560 |  0.1640 |  0.1100 |  0.0470 |
|    ------ |    --- 2 |   Attack |   Moving | Average |  ------ |  ------ |
|       80% |  23.2888 |  17.2935 |  23.2272 | 15.7037 | 15.5595 | 15.1150 |
|       90% |   8.0242 |   8.5203 |   8.0382 |  6.3570 |  6.5395 |  6.9605 |
|    ------ |    --- 3 |   Attack |   Moving | Average |  ------ |  ------ |
|       80% |   9.1170 |   5.6035 |   9.0838 |  6.9930 |  7.1907 |  7.7350 |
|       90% |   0.0000 |   3.9815 |   0.0000 |  2.9437 |  3.2748 |  3.6463 |
|    ------ |    --- 4 |   Attack |   Moving | Average |  ------ |  ------ |
|       80% |   7.7910 |   2.1948 |   7.7340 |  6.2015 |  6.3585 |  6.7892 |
|       90% |   0.0000 |   0.0000 |   0.0000 |  2.7633 |  3.0295 |  3.3723 |
|    ------ |    --- 5 |   Attack |   Moving | Average |  ------ |  ------ |
|       80% |   5.8880 |   2.0383 |   5.8137 |  5.5548 |  5.7040 |  6.0615 |
|       90% |   0.0000 |   0.0000 |   0.0000 |  0.8783 |  1.0170 |  1.2260 |
|    ------ |    --- 6 |   Attack |   Moving | Average |  ------ |  ------ |
|       80% |   0.0000 |   1.0653 |   0.0000 |  2.3687 |  2.5800 |  2.9080 |
|       90% |   0.0000 |   0.0000 |   0.0000 |  0.2658 |  0.3277 |  0.4365 |
|    ------ |    --- 7 |   Attack |   Moving | Average |  ------ |  ------ |
|       80% |   1.1480 |   0.4245 |   1.1415 |  2.0782 |  2.2130 |  2.5255 |
|       90% |   0.0000 |   0.0028 |   0.0000 |  0.1373 |  0.1635 |  0.2280 |

The first thing to notice is that W4 doesn’t end up casting Shield Barrier at all.  I was puzzled by this at first, but after a little bit of debugging it made sense.  It’s the Shield Block lockout conditional at work.  You will never have more than 3 seconds remaining on a Shield Block charge when Shield Block’s buff isn’t active, because by the time the buff falls off the first charge has had at least 6 seconds to recharge.  So a 4-second lockout essentially nullifies the weaving entirely, turning this into a duplicate of the “SB” queue.

Unfortunately, the other weave queues are disappointing for completely different reasons.  W3 is a flat-out gain for strings of two attacks, but fails to be attractive as soon as you consider a third attack.  You shave another 2% off of the number of 80% attacks, but in doing so shifts 3% of them into the even more dangerous 90% category.  And things don’t get better as you look at longer strings, as W3 rapidly falls behind SB in both 80% and 90% spike categories.  The only advantage is a significant (~12%) drop in overall damage intake thanks to Shield Barrier’s numerical advantage over Shield Block in TDR.

And the situation isn’t helped by reducing the lockout – that just makes the pushback effect worse.  We actually start seeing a slight (~0.1%) drop in Shield Block uptime due to the pushback, and no spike mitigation improvement over the W3 queue in any category.  These queues do show better rage utilization (less wasted rage), and slightly improved TDR (though only barely), but wasting less rage isn’t all that attractive if it’s going to get you killed more often either.  Though not shown in the table, I also simmed out W3.5 and W2.5; W3.5 is identical to W4, and W2.5 falls solidly in-between W3 and W2 with no further advantage.

Almost unbelievably, the weaving strategy makes you less survivable than spamming Shield Block and ignoring Shield Barrier does!

The problem again comes down to rage generation.  We simply don’t generate rage fast enough to satisfy the conditionals we’re shackled with without causing Shield Block pushback.  It takes an average of about 7.4 seconds to generate enough rage to cast Shield Block.  Since we’re really gaining rage in discrete chunks, sometimes it’s 5-6 seconds, and sometimes it’s 8-9 seconds or longer, but it’s rarely much less than 5 seconds.  Even back-to-back Sword and Board procs plus Berserker Rage only gives us 60 rage in 3 seconds (SS-Dev-SS, ignoring the trailing GCD), and that’s not a frequent occurrence.

When we use Shield Barrier and drop below 20 rage, we only have at most 3 seconds in which to generate the extra 40-60 rage we need before the next Shield Block charge becomes available.  And we’re just not generating rage fast enough (or consistently enough) to pull that off reliably.  We’d need to be generating 14-20 RPS to be able to successfully weave a Shield Barrier in without a significant risk of Shield Block pushback, and that’s just not possible.

Remember, we’re hit- and expertise-capped in this set.  We’re hitting the “rage soft cap,” so to speak, by capping our most effective rage gain stats.  While we have a good chunk of mastery and avoidance, the rage gain through those mechanics is weak by comparison.  We’re in an almost ideal gear set for rage generation, and it’s still not enough.  And shifting that itemization from avoidance into mastery (or vice versa) isn’t going to be enough of a change to nearly double our rage generation.

There’s little doubt that the weaving strategy is just not as good as we all thought it would be.  You can include me in that group too – in previous comments here and on other forums, I too suggested that this strategy would probably give smoother damage profiles.  But it just goes to show you that you can’t always trust your intuition.  We all made the same flawed assumption – that rage overhead at hit and expertise caps would be high enough to support seamless weaving.  And that assumption turned out to be flat-out wrong.

Just for curiosity’s sake, I cranked up the rage generation of Defensive Stance from 1 rage every 3 seconds (0.333 RPS) to 9 rage every 3 seconds (3 RPS).  Doing so pushes us up to about 10.76 RPS total, and has a drastic effect on the results.  W4 doesn’t change, but W3 suddenly becomes amazing.  33% less damage taken than SB and about 10x better at eliminating 80% spikes across the board.  For example, the 5-attack moving average data drops to 0.4068% in the 80% category and 0.0028% in the 90% category.  If we could maintain that level of rage generation, the weave strategy would be hands-down better for survivability.

So we can perhaps be forgiven for our errant assumption – the weave strategy is great in concept, it’s just stifled by (and very sensitive to) lack of rage generation.  The weave strategy is a leashed dog chasing a squirrel in the backyard, only to find that the leash leaves him one yard short of his quarry.  But one yard may as well be a mile as far as the dog’s concerned, and another 3 rage per second may as well be a million for us, because we’re both at the end of our leashes.

This exercise wasn’t completely fruitless though.  One thing we have discovered is that the W3 queue is a little better than the SBr* queue for 2-attack strings.  This might be relevant in and of itself if we run into a boss that hits for nearly half our health in a single attack.  You wouldn’t survive long against such a boss without cooldowns, but that knowledge might be useful if we run into a boss with mechanics that require you never take two attacks in a row without some sort of mitigation.

In addition, we know that we’re not far from the rage levels that would support a weaving strategy.  It’s not uncommon to get raid buffs that significantly improve resource generation, and while protection warriors no longer have any resource scaling with haste, one would hope that the developers account for this (see, for example old Essence of the Red vs. new Essence of the Red).  So in a fight like Sinestra, we might shift to a weave strategy.

Weave-Bleed Queues

After the “meh” performance of bleed queues and the outright lack of success with weave queues, I wouldn’t blame you for asking why I’d expect a combination weave-bleed queue to fare any better.  In fact, I wouldn’t, but it turns out that I actually ran these weave-bleed simulations first, and only afterwards tried the “pure” weave queues.  It wasn’t until I saw the results of these simulations that I thought to separate out the weave.  But since I’ve already coded the queues and generated the output, we may as well take a look at what happens.  The logic is pretty straightforward:

  • WX-Y will try and cast Shield Block on cooldown, and will try and cast Shield Barrier if
    • either
      • Rage is >= 20
      • A Shield Block charge will not be available in the next X seconds
      • Shield Block’s defensive buff is not active
      • Shield Barrier’s defensive buff is not active
    • or
      • Rage is >= Y

It’s just what you would expect to see for a WX queue with a Y bleed valve added.  Let’s see what happens:

|      Set: |       SB |     SBr* |  W3-105 |  W3-110 |  W3-115 |  W3-120 |
|        S% |   0.6667 |   0.0000 |  0.6665 |  0.6665 |  0.6665 |  0.6665 |
|      mean |   0.5854 |   0.4174 |  0.5153 |  0.5157 |  0.5154 |  0.5145 |
|       std |   0.1390 |   0.2021 |  0.1761 |  0.1755 |  0.1759 |  0.1759 |
|    SBr(k) |   0.0000 | 100.0000 | 17.0950 | 17.1350 | 17.1360 | 17.1490 |
| SBr<60(k) |   0.0000 |  66.4910 |  6.9520 |  7.0110 |  7.0490 |  6.9750 |
|       RPS |   8.1052 |   7.3499 |  8.1123 |  8.1146 |  8.1118 |  8.1164 |
|    xsR(k) | 862.9810 |   0.0000 |  0.0420 |  0.0970 |  0.1300 |  0.2870 |
|    ------ |    --- 2 |   Attack |  Moving | Average |  ------ |  ------ |
|       80% |  23.2643 |  17.4233 | 15.7930 | 15.7805 | 15.7305 | 15.6757 |
|       90% |   8.0210 |   8.5962 |  6.3663 |  6.3312 |  6.3775 |  6.2878 |
|    ------ |    --- 3 |   Attack |  Moving | Average |  ------ |  ------ |
|       80% |   9.0898 |   5.6418 |  7.0233 |  6.9907 |  7.0135 |  6.9320 |
|       90% |   0.0000 |   4.0285 |  2.8112 |  2.7873 |  2.9040 |  2.8022 |
|    ------ |    --- 4 |   Attack |  Moving | Average |  ------ |  ------ |
|       80% |   7.7640 |   2.2183 |  6.1898 |  6.1692 |  6.2270 |  6.1375 |
|       90% |   0.0000 |   0.0000 |  2.6545 |  2.6183 |  2.7140 |  2.6425 |
|    ------ |    --- 5 |   Attack |  Moving | Average |  ------ |  ------ |
|       80% |   5.9170 |   2.0448 |  5.5000 |  5.4852 |  5.5430 |  5.4417 |
|       90% |   0.0000 |   0.0000 |  0.8215 |  0.7983 |  0.8648 |  0.8220 |
|    ------ |    --- 6 |   Attack |  Moving | Average |  ------ |  ------ |
|       80% |   0.0000 |   1.0720 |  2.2700 |  2.2455 |  2.3280 |  2.2725 |
|       90% |   0.0000 |   0.0000 |  0.2238 |  0.2210 |  0.2440 |  0.2315 |
|    ------ |    --- 7 |   Attack |  Moving | Average |  ------ |  ------ |
|       80% |   1.1575 |   0.4313 |  1.9890 |  1.9552 |  2.0055 |  1.9895 |
|       90% |   0.0000 |   0.0040 |  0.1087 |  0.1050 |  0.1208 |  0.1093 |

If you’re wondering where to look in the table to find the interesting part… well, there isn’t one.  They all perform almost identically to W3, suggesting that the bleed valve doesn’t do very much.  That does tell us that the “pure” weave queues rarely build up enough rage to need a bleed valve though.  It happens so rarely, in fact, that we barely even get a single 60-rage Barrier worth of excess rage savings.  That also means there’s no point in simming W2-Y queues, as they’ll just perform like the W2 queue did.

These queues are very sensitive to the lockout.  We’re only getting weaving at all because W3’s lockout is exactly the duration of Shield Barrier’s downtime window.  If you set the lockout to anything higher than 3 (i.e. W3.1-110), all weaving stops and the bleed valve becomes the only avenue for Shield Barrier casts.  And in that case, the results look almost identical to the associated “pure” bleed queues.

Basically, depending on where you set the lock and bleed thresholds X and Y, the WX-Y queues collapse into either a weave or a bleed, but never seem to engage both.  There’s not much more to be said about these queues.  There’s no obvious advantage to any of these over the simple bleed or weave queues, so there doesn’t seem to be any point in using them.

FCFS Queues

Finally, I want to fool around with something I call “first come, first serve” or “FCFS” queues.  The idea behind these queues is that maybe it doesn’t matter if we push back Shield Block as long as we have something active.  As long as we’re throwing something defensive up at a regular interval, we might be able to get a damage smoothing benefit out of it.

How do these queues differ from the Weave-Bleed queues?  Primarily, it’s  that we’re constraining both Shield Block and Shield Barrier rather than just Barrier.  All of the earlier queues were still focused on trying to minimize the disruption of Shield Block uptime.  With these queues we’re going to give them more equal footing.

The basic logic is this:

  • F-Y will attempt to cast
    • Shield Block if
      • Shield Block’s defensive buff is not active
      • Shield Barrier’s defensive buff is not active
    • Shield Barrier if
      • either
        • Shield Block’s defensive buff is not active
        • Shield Barrier’s defensive buff is not active
        • Rage is >= 20
      • or
        • Rage >= Y

As you can see, this is similar to the weave strategy, but with the additional constraint on Shield Block.  It still favors Shield Block, of course, but it’s a little more equitable than the weave strategies.  I haven’t included a lockout here, even though the code will technically accept “FX-Y” queues and handle them appropriately.  But I haven’t included them because after trying a few of those queues, they turned out no different than the Weave-Bleed queues.  Even a lockout of 0 seconds will force you into Shield Barrier casts once the charge is available.  It’s only when you remove the lockout completely that you start to see different behavior, because now we may end up casting a 40-rage Shield Barrier even though a Shield Block charge is available.

Of  course, the fear is that with no lockout, we’ll just degenerate into a SBr* and spam Shield Barrier all day.  Let’s see if that’s really what happens:

|      Set: |       SB |     SBr* |   F-110 |   F-115 |   F-120 |
|        S% |   0.6667 |   0.0000 |  0.4219 |  0.4122 |  0.4146 |
|      mean |   0.5857 |   0.4159 |  0.4786 |  0.4774 |  0.4764 |
|       std |   0.1388 |   0.2027 |  0.1601 |  0.1606 |  0.1605 |
|    SBr(k) |   0.0000 | 100.0000 | 57.8110 | 58.7820 | 58.5360 |
| SBr<60(k) |   0.0000 |  66.2570 | 56.5630 | 57.6290 | 57.3190 |
|       RPS |   8.1061 |   7.3562 |  7.8358 |  7.8148 |  7.8297 |
|    xsR(k) | 863.4910 |   0.0000 |  0.0000 |  0.0250 |  0.0350 |
|    ------ |    --- 2 |   Attack |  Moving | Average |  ------ |
|       80% |  23.2543 |  17.2838 | 14.2528 | 14.5067 | 14.4210 |
|       90% |   7.9967 |   8.5430 |  5.3230 |  5.3033 |  5.2850 |
|    ------ |    --- 3 |   Attack |  Moving | Average |  ------ |
|       80% |   9.1100 |   5.5718 |  5.7012 |  5.7890 |  5.7838 |
|       90% |   0.0000 |   3.9517 |  3.3825 |  3.3708 |  3.3872 |
|    ------ |    --- 4 |   Attack |  Moving | Average |  ------ |
|       80% |   7.7692 |   2.1925 |  2.0100 |  1.9283 |  1.8865 |
|       90% |   0.0000 |   0.0000 |  0.1363 |  0.1295 |  0.1123 |
|    ------ |    --- 5 |   Attack |  Moving | Average |  ------ |
|       80% |   5.8825 |   2.0310 |  1.8770 |  1.6962 |  1.6265 |
|       90% |   0.0000 |   0.0000 |  0.0000 |  0.0000 |  0.0000 |
|    ------ |    --- 6 |   Attack |  Moving | Average |  ------ |
|       80% |   0.0000 |   1.0682 |  0.8375 |  0.7502 |  0.7150 |
|       90% |   0.0000 |   0.0000 |  0.0000 |  0.0000 |  0.0000 |
|    ------ |    --- 7 |   Attack |  Moving | Average |  ------ |
|       80% |   1.1593 |   0.4270 |  0.4678 |  0.4182 |  0.3960 |
|       90% |   0.0000 |   0.0013 |  0.0010 |  0.0008 |  0.0017 |

I’ve only shown three bleed settings here, but that’s enough to see that the bleed valve doesn’t have a strong effect on this queue.  It’s certainly being invoked in F-110, because I checked for that in the debugging, but it only triggers a handful of times (literally) in the entire 10,000 minute run.  And the bleed valve didn’t get invoked at all at the 115 or 120 bleed levels.  When I dropped the bleed value to 100, it performed a little worse than F-110, probably due to a few extra early bleed triggers.  In any event, it seems the bleed setting is mostly irrelevant to the behavior here.  The behavior is dominated by the NOR() we’re performing on the Shield Block and Shield Barrier buffs.

It’s also clear that we haven’t devolved into a Shield Barrier spam routine, because we have a fairly significant amount of Shield Block uptime.  While we’re nowhere near the cap, 41% is still a pretty large amount of coverage for a queue that permits chain spamming of Shield Barrier.  F-110 also casts a little over half as many Shield Barriers as SBr* does, and the majority of them are 40-rage casts (14.47% @ 20-rage, 83.37% @ 40-rage, 2.16% @ 60-rage).

As far as the queue’s performance, TDR and rage generation fall squarely between SB and SBr*, and there’s almost no wasted rage to speak of.  The spike damage data is… well, surprisingly good, actually.  It’s solidly ahead of both SB and SBr* for two-attack strings, much like the Weave queues.  It has the same problems a SBr* at 3 attacks, with improved overall (80%) spike reduction at the cost of an increase in 90% events.  It’s similar to SBr* for 4-attack queues, though it does permit a small amount of 90% events.  But it beats SBr* pretty consistently for 5+ attacks.

While it isn’t as good as SB for eliminating 90% spikes across the board, it does generally give a lower percentage of 80%+ spikes overall.  If you’re less concerned with the exact distribution of spikes above 80% and more concerned with minimizing the total number of events that exceed 80%, it’s considerably better than either of the basic queues, and edges out the Weave and Bleed queues as well.  The only place it loses with that metric is for 6-attack strings, which SB eliminates completely.

Conclusions – Part 2

These simulations have been a bit of an eye-opener, I think.  We all expected to see a significant performance increase from combining Shield Barrier and Shield Block casts, but that increase failed to materialize in practice.  The simple Bleed queues failed to be all that attractive, and the Weave queues fell flat on their face rather than vindicating the “weaving” strategy many have been espousing as ideal.  And we got an unexpected surprise in the performance of the FCFS queues, which I had assumed would suffer due to low Shield Block uptime.

But what is perhaps the most surprising result is just how well the simple “Shield Block spam” queue held up.  Despite all of the criticisms of this queue – it was “simplistic,” “unrealistic,” and a “poor model for rage utilization” – you could make a strong argument based on these results that it was in fact the strongest performer against Patchwerk.  The ability to completely eliminate 90% spikes is a huge selling point, and not to be dismissed lightly.

It does raise a new questions though: where exactly ought we set our sights? Is is events exceeding 90% that matter most, or should we be minimizing everything over 80%?  If you aren’t going to survive an 80% spike anyhow, the significance of that distribution becomes less important.  And if that’s the case, these new FCFS queues may be worth considering further, as they’re incredibly effective in that department.  Just as you could make a good argument for SB based on 90% spikes, I think you could make a strong argument for F-110 based on 80% spikes.

It’s hard to crown a “winner” here as a result.  I think it’s clear that the Weave and Bleed queues were both disappointing, and wouldn’t qualify for the title without some external source of rage.  But I think it’s a pretty close toss-up between SB and F-110.  I can think of situations where I’d want one or the other, but I’m not sure which is the more general choice.  Adding magic damage into the mix ought to favor F-110, one would expect.  That’s something we can look into in another installment.  On the other hand, lower rage generation might favor SB, for example if someone isn’t hit- and expertise-capped.  That’s something we’ll analyze once we start looking at how stat distribution affects the results.  The excess rage could potentially be turned into Heroic Strike DPS (lower rage cost, especially with Deadly Calm active, which should eliminate the risk of Shield Block pushback).  And there’s a nerf to Shield Barrier coming in 5.2, so that may shift the results a bit too.

In any event, I’m going to perform future tests with several queues.  Certainly SB and F-110 are going to be included, and potentially SBr*.  They all have slightly different strengths and weaknesses, so it’s reasonable to expect them to vary differently with initial conditions.  It’s unlikely that I’ll consider the Weave or Bleed queues very heavily, but there’s nothing stopping us from trying them if the situation looks like it warrants it.

I’m actually not entirely sure which aspect we’ll look at next.  I have the simulations written, but haven’t cranked out or analyzed the data.  There’s a plethora of questions we could tackle.  What stat allocations are ideal? How does periodic magic damage affect queue choice?  What happens if we crank up/down boss damage significantly?  What effect does a longer swing timer have?  If you have opinions as to what’s more interesting, please share them in the comments.

This entry was posted in Tanking, Theck's Pounding Headaches, Theorycrafting, Uncategorized and tagged , , , , , , , , , , , , , , . Bookmark the permalink.

50 Responses to 5.1 Warrior Simulations – Part 2 – Rotations

  1. bryjoered says:

    Stat allocations please :)

  2. Thunderspank says:

    Very interesting analysis. Perhaps we can make the case for higher rage gain through defensive stance to make weaving more interesting? Because as it stands, you could almost macro S-Block in and call it a day, right? :)

    • bryjoered says:

      Not really though. There are a lot of fights where you will want to have raged reserved so you can have a shield block or barrier ready for a damaging sequence. Garalon’s cleave is the most obvious one I can think of where ideally you would want to have shield block active every time it hits.

      • Theck says:

        I’m not sure that’s optimal. The interval between Furious Swipes is around 8.4 seconds according to my logs from last week. That means you’ll only ever cover ONE Furious Swipe with Shield Block, and you’ll only mitigate about 30% of that Swipe with it for 60 rage. A single 60-rage Shield Barrier will mitigate about 1.8 Swipes worth of damage, though again the 6-second duration keeps you from chaining. But even a 20-rage SBarr would mitigate about 60% of an attack, double what SBlock will do.

        TLDR: For Garalon, you should probably not be casting SBlock at all, just using SBarr every time he starts to cast Swipe.

        • bryjoered says:

          Hmm, that’s interesting because it seems to be pretty effective at all but eliminating the damage from the swipe. I’ve been trying to use shield barrier when I can for crushes and it really shines there I see everyone’s health drop like a quarter and mine just a fraction. Any predictions as to whether hit/exp is worth capping over mastery?

    • Theck says:

      For Patchwerk? Yeah, you really could. Luckily most of the fights in T14 aren’t quite that simple. See comment above regarding Garalon, for example. In practice, you’ll want to figure out whether it makes sense to weave Barriers in at certain points of predictable or magical damage.

      I think it’s actually a neat setup, to be honest. More interesting than just timing Shield of the Righteous, IMO.

  3. bryjoered says:

    I should clarify and say it doesn’t “eliminate” the swipe, but seems to mitigate it pretty well.

    • luofu says:

      Another thing is the dmg bost from using shieldslam within shieldblock.

      Not ebery guild is blessed with top dds.

      And the tank can do quit amount of dmg on garalon.

      70k+ dps on garalon with nhc gear is not bad at all. That was the highest one of our warrior tank could get.
      And even better if our kulls are almost always a “berserk-kill”. Garalon floating in the air. Ready to crush everyone with massive crush. xD

      For dmg reduce. Barriere is better. But if the dmg is easily healable. The dmg boost is golden!

      • bryjoered says:

        70k is insane for a warrior tank! He must be hit/exp capped :) I do about 25k on Garalon using the Mastery>hit/exp build. I guess I should take into account that in my guild the tanks are assigned as kiters, so for about 1/4 of the fight i’m doing zero damage to him.

  4. ex says:

    Wow this is not what I expected at all! Executing a Bleed or Weave strategy clearly requires more skill from a player then just spamming SB and therefore should perform better imo. After all this is one of the main arguments of the whole active mitigation discussion. Furthermore, I compared the numbers from your paladin damage smoothing post: The difference in healing a paladin compared to a protection warrior is quite significant. I would argue that is significantly easier to heal a paladin due to the fact that they have less 80 and 90% events in every section with a haste control set.

    Therefore the question that interests me most at the moment is how stats influence these results.

    Is it possible to produce similar or better results with a full mastery set?

    If I am not able to cap hit and expertise hard how will the results be affected? Am I better off with a mastery strategy?

    Another thing I would be interested in is how a longer swing timers effects the results. I.E in the encounter Imperial Vizier Zor’lok if the boss casts inhale and as a result is not hitting you and you have a SB buff, that SB is basically “wasted” since the boss is hitting you less. I would assume a longer swing timer would benefit Sbarrier but how bad is it really?

  5. jeff.fischer@sasktel.net says:

    I’d like to see what reforging to mastery would do. This is all based on hit and exp capped, but Mr Robot still says to not do that and to spec all mastery as optimal. To me that seems to be the other really large question that is still outstanding.

  6. Xpariah says:

    Simply a great post. Thank you for all the information you posted. You make me want to start a movement to up our rage generation: either through abilities (my preference) or through Defensive Stance. I would love to see more intricacy through the use of weaving and it sort of disappoints me that that is not the case already. It’s always good to have this information available.

    In addition to a previous poster, I would love to see stat allocation based on these primary methods (SB, F-110, &SBr*) but also a possible fluctuation of those values if our rage generation went up. Some kind of uniformed information that could be used along with a presentation to Blizzard that might show the damage mitigation and stat allotment. In short, I’d love to see Defensive Stance damage reduction lowered but our TDR increase through skill (something similar to Brewmasters, for example.)

    The math you do sometimes boggles my head but I sit and stare at it and the explanations you give provide me with a chance to comb through it all. You do a very good job of explaining something I would consider complex in an enjoyably comprehensible way.

    Also, would damage output be too far out of the bounds of realism TO COMBINE with the damage intake models you are constructing? Some kind of all encompassing model that solidifies what is best when considering DPS, TDR, 80%, & 90% spikes collectively. I imagine it would be quite the task and maybe inappropriate to ask considering this is not your primary class or specialization.

    Well, enough from me– thank you again for all the work done here in these last two blogs and the posts made on the other forums you visit.

  7. Lakh says:

    Playing with stat allocations sounds the most interesting to me. This seems to make the case for not capping hit/exp, if the softcapped rage isn’t able to be used efficiently anyway.

    • xpariah says:

      There is more to be gained from capping or near capping than TDR & smoothing incoming damage alone. Damage output is a serious point of contention for capping these stats. How much? I’m not sure. But it would be interesting to find out. Do not take this as a point of disagreement, if a reallocation of stats showed a significant gain in reducing incoming damage and the spikes in which we receive it, it would be a very interesting toss-up indeed with regards to whether we choose damage out versus damage in– right now the choice is made for us.

      • bryjoered says:

        I think that, in general, tanks should be more worried about surviving and being easy to heal than DPS. I’m pretty sure that it’s not even a question that hit/exp is both the best rage generation and best dps stat. I feel that if your dps are doing their job, tank dps doesn’t need to be very high.

        • xpariah says:

          I’m not sure of the general ranking of the viewership of this blog but at progression level content (pushing for world or US rankings) I feel it most certainly matters. When you hit content under geared, you need DPS from every possible source to be as high as possible to make up for the handicap of a lower average raid’s item level. Obviously this need diminishes as the gear rises but so does the need for damage reduction. Over gearing content allows for suboptimal play in all regards (DPS, healing, AND tanking) and while there may exist an optimal way to play then it is most certainly unnecessary.

          And this is all to be said without considering the control that the hit/expertise preference divides you. Almost no fight is Patchwerk anymore. There are lulls in damage intake as well as heavy spikes. Active mitigation allows for these occurrences and nothing suits active mitigation more than control– control that can be found within hit/expertise gearing.

  8. bryjoered says:

    Yes, you make a good point, but even your very own armory suggests that you favor Mastery over hit/exp. WIth your heroic gear you could easily be capped and you are not.

    • bryjoered says:

      I mean, I tried to get hit/exp capped and I couldn’t unless I were to go with a bunch of pure hit/exp in my gear and I don’t think that is a smart idea. My ilvl is 491, but surely you could get there easily with a couple hybrid hit gems.

    • xpariah says:

      I responded on the AMR forums so as to not clutter up or derail this blog post.

  9. Yaargh says:

    I think stat allocation will be the most interesting thing to look at next. It’d be nice to see the SB queue with a full mastery build (with just enough hit/exp to keep SB up time), the SBr* queue with a full avoidance build (with hit/exp capped), and maybe the F-110 queue with both.

    I’d appreciate you keeping the SBr* queue in the mix since that’s what I currently use. We’re running 10m normals right now so the 80%+ danger zone isn’t as dangerous and the better TDR helps us 2-heal nearly every fight even though we don’t out gear them yet.

  10. tigerlol says:

    Great stuff, thanks!

  11. Pingback: 5.1 Warrior Simulations – Part 3 – Stat Priorities | Sacred Duty

  12. Basoli says:

    How effective would Heroic Strike be as a bleed valve? It wouldn’t contribute to survivability, but it would allow you to bleed rage without pushing Shield Block casts back at all. You would be able to maintain close to 90 rage, or even higher with Deadly Calm. Would there be any other advantages to this over maintaining rage for when a Block/Barrier (depending on the fight) is necessary?

  13. drummer0702 says:

    I have a question pertaining to max Rage gen. Don’t you think there is some sweet spot for max Rage generation between Hit, Exp, Parry, Dodge, and Mastery? I think a perfect example is that of Windlord. Sure, it is an extreme but it helps explain what I’m talking about. Since Dodge or Parry price Revenge and Crit Blocks Enrage with generating Rage don’t you think some mix of all these stats provide best Rage Gen as opposed to just hit and exp cap?

    • Theck says:

      There isn’t really a sweet spot – either one stat is better or it isn’t. In the case of a Patchwerk boss, hit and expertise are always going to be your best rage generation stats. For a boss like Wind Lord, you might have a high enough incoming attack rate to make avoidance or mastery better for rage generation, but my guess is even that wouldn’t be enough. Maybe if you’re solo-tanking all of the mobs?

  14. shade says:

    Thank you for the awesome post!

    I have two questions regarding your priority list, as I follow a rather different approach:
    Your queues seem to follow an – as soon as its ready approach while I like to play with a rather large amount of rage leaving me some space to react, so here’s what I do:

    1. Counter spikes: Shield Barrier if HP drops to less than 30% (or if a non-blockable Spike is expected.)
    2. Mitigate and level incoming dmg: ShieldBlock as primary mitigation spell when Rage is more than 80
    3. Bleed Excess Rage: Shield Barrier if Rage is more than 110 and Shieldblock is not going off CD soon (something like the next one or maybe 2 GCDs)

    In effect I try to spam ShieldBlock as often as possible without leaving me ragestarved, leaving me with the possiblity to react to some hard hits/Cast with a ShieldBarrier. As a downside to this approach this does delay ShieldBlock sometimes.

    -Your sims suggest that bleeding of excess rage is a dumb idea as a potential delay of a ShieldBlock is more severe? Is my conclusion correct? I find it hard to believe? I have to try this, as I find it a very interesting result.
    -Did you think about some reactive elements in your simulation, as I havent seen a single unpredictable (hence unavoidable/unmitigateable) spike that would kill me? You have shown that bleading off excess rage -when it’s there- is not very effective, however, If you condition the weaving to the incoming damage/current HP It might be worth delaying ShieldBock?

    Thanks for your good work!

    • Theck says:

      Yes, the sims suggest that rage bleeding is a bad idea. Again, the reason is that you simply don’t have enough rage generation to cast a 60-rage Shield Barrier without pushing back a Shield Block cast. And pushing back Shield Block is what opens you up to larger spikes.

      I think that using Shield Barrier as you do in #1 is smart. You’re basically *in* a spike, you recognize that you’re in the spike, and you drop back to Shield Barrier to try and combat it. In doing so, you’re risking making the spike even longer, of course (no SBlock coverage for the next few attacks), but in theory you’d be dead before that point anyway.

      However, I can’t implement that in the sim because we don’t track tank health at all. To do that, we’d have to implement a healer, and AI for the healer, and so on. We could approximate it by throwing in a “Shield Barrier if the last 3 hits total more than X damage” or something like that. But again, that’s just going to make the spike metric worse, not better.

      I have no idea why the comment system was screwing up your numbered list, but I merged it into your first post and deleted the extra ones.

    • Ninjouz says:

      I agree with your philosophy. I tend to stock some rage in order to have some room while in a dangerous situation.

      In a pure melee fight I tend to use SBar when I know that my health has dropped to much and the next full hit might be lethal. I prefer to delay one SB than to take the risk to die.

      When I see that with my next GCD, i can cap (and thus waste) my rage bar, I cast a “forced” Sbar.

      And at last, I track how much absorbs remains on my actual Sbar. Depending on how much it’s left, i may wait before casting a Sbar (again on a pure melee fight).

  15. Krennick says:

    I think in this post you’ve largely managed to do some wonderful mathematics on a flawed set of assumptions. I’m not at all surprised that bleed, weave or the combination performs poorly. As a tanking warrior I’ve intuitively understood this from before people started recommending it. If you have committed to using shield block and are looking for ways to spend excess rage on shield barrier for additional total damage reduction bleed and weave are both (imo) intuitively the wrong places to look – both carry great inherent danger of delaying shield blocks.

    To spend rage on shield barrier while focusing on shield block there is a completely different set of questions you need to be asking yourself. They all derive from the basic: What factors allow me to spend rage on shield barrier with no or with very little risk of delaying my next shield block? For timing the answer is obvious: Immediately following a shield block when you presumably have 9 seconds to build the 60 rage you need for shield block. For other factors they will be things like berserker’s rage and/or battle shout off cooldown, and shield slam less than 3 seconds from coming off cooldown – revenge you can’t use as a measure – without any dodge/parry based procs you can use it once per 9 seconds, and it’s dangerous to assume anything else. But 4 piece set bonus is a factor – shield block costing 55 rage. So, if I fire off my shield block and chase it immediately with a shield barrier to empty my rage bar (both ofc not on global cooldown) because my shield slam has below 3 seconds left on cooldown – I can use shield slam twice and revenge once (no fail) and have 55 rage ready for the next shield block in time. That means, fully half the time I use shield block I can empty my rage bar on shield barrier as well (as long as I do it before I use my next rage builder).

    This can extend into the 9 second window between shield block uses if you take rage into account. For instance 3 seconds in you know you will have at least one shield slam, so if you have 100 rage you can use shield barrier. If you have sword and board proc you can lower that rage requirement by 5. If you have revenge on less than 6 second cooldown you can lower that rage requirement by 15. If you have battle shout off or on less than 6 second cooldown you can lower that requirement by 20. If you have berserker’s rage off or on less than 6 seconds cooldown you can lower that rage requirement by 10. For any given time (on or off global cooldown) you can factor in whether you can afford to fire off a shield barrier now. Neither your weave nor your bleed approximate how this decision tree will play out.

    The thing is, even if you use shield block and shield barrier at the same time you will still have some benefit. There’s no reason why that should not be at the very beginning, middle or end of a damage spike. We are, for the most part, considering damage spikes beyond 2 swings (3 seconds) dangerous, no? Intuitively, the first and last 2 seconds of a shield block duration are more likely to be part of the dangerous part of a damage spike than the middle two seconds.

    I’m sure you note some similarity in what I’m saying here to what shade mentioned in an earlier comment. I’m just being a little more specific in describing the factors that go into the decision tree instead of mentioning the rather arbitrary 80 rage, 110 rage and “soon” factors.

    I also use shield barrier to survive spikes – and normally it’s effective, because you have to consider healer inertia. Healers are looking at whoever needs healing so they’ll often be looking at someone else when you need heals the most – if I end up at sub-30% health, put up a 500k shield barrier absorb to keep myself alive my health is very visibly low. Even if the dmg spike is sustained the time which I spend at below 30% will make sure that more and more healers are shooting heals (and their own absorbs) my way. It is one case where in the moment the sub-optimal dmg spike prevention is superior. The absorb makes me safe enough for long enough that healers will take up the slack (just as they would if there were known and anticipated spikes like breath or thrash or focused assault that need a bit of extra healing oomph)

    With regards to overwriting shield barriers already up, there are multiple factors. You have touched on some of them, but a dominant one is whether according to the decision tree I have alluded to above this is a good time to use shield barrier. Sometimes I overwrite one with half or better of the capacity unused to avoid capping out on rage, other times I make the decision that I can afford to use shield barrier AND I can afford to wait until the current one is gone. (ShieldHealth is a fantastic addon btw)

    Also reminder: Shield barrier does not use just 20, 40 or 60 rage. See my comment on part 1 of this series.

    • Theck says:

      Regarding Shield Barrier timing: there’s a school of thought (which I happen to agree with) that it’s better to stagger your mitigation. Popping, e.g., Shield Barrier 1 second after casting Shield Block will give you more total damage reduction than not using SBarr at all, but it doesn’t significantly increase your spike prevention. You’re stacking more mitigation on a high-mitigation period, which is generally less effective than just having more high-mitigation phases overall. See, for example, paladins and the haste vs. mastery discussion.

      In this case, that means one of two things: You either pop SBarr as you describe, shortly after a SBlock cast while having enough of a rage bank that you don’t risk pushing the next SBlock back (i.e. a “bleed” threshold), or you just implement the bleed valve without worrying about SBlock status. Both should be relatively similar in effectiveness for TDR, but the “bleed” version should generally be better at mitigating spikes because some of those Barrier casts will fall into those 3-second gaps.

      It’s also worth noting that the problem with any of the bleed/weave queues is simply rage starvation. Even at hit/exp caps, you simply don’t have enough rage generation to pop out a 60 rage Barrier [i]without[/i] delaying Shield Block. So it always comes down to a trade-off between “more mitigation now” via SBarr or “smoother mitigation overall” with SBlock.

      More complicated decision trees are obviously something we could try, but it quickly becomes cumbersome to try too many of them because the parameter space gets pretty big. Another thing I’d like to try is to base usage off of instantaneous damage intake – for example, we’re using a Markov approximation here by ignoring what’s happening on the intake side. But you could imagine adding a “if damage in the last N swings exceeds X” conditional in your SBarr usage, which would help bias the decision towards mitigating spikes and pooling rage if you’re already “safe.”

      That said, I’m already working under the assumption that a smart warrior uses Shield Barrier to respond to a spike rather than blindly spamming Shield Block all the time. The code is determining the optimal steady-state rotation for minimizing the number of those spikes you encounter. When something dangerous happens, it’s expected you’ll go “off-script” and dig into your toolkit to survive better.

      Regarding the discretization of SBarr: I wasn’t aware the ability worked that way, but it would be easy to fix in the simulation. That said, it won’t have a large effect on the results. Stochastically, it should all average out. If anything it may make use of Shield Barrer at <60 rage even worse, simply because there's no chance of retaining 10-15 rage by missing a threshold value.

      • Krennick says:

        “Regarding Shield Barrier timing: there’s a school of thought (which I happen to agree with) that it’s better to stagger your mitigation.”

        While I do agree with this school of thought I think the mechanics and rage economy of the warrior class makes this less true for the warrior. Or indeed, perhaps not true at all. Particularly, if we assume a 2 attack spike is not sufficient to be a threat to a tank, the shield block gap goes from being a critically important period of no mitigation to a reasonably important period of low mitigation.

        Anyway, above all I must apologize for entering the discussion so late – because I feel the real issue is that you have chosen to model finisher queues that are unsuitable. So you now have an investment in queues that have given you results that you are naturally inclined to value. And I’m sitting here rooting for you to dismiss them and maybe use some other queues instead.

        Additionally, if my feedback had been timely I would have strongly suggested you take into account the T14 4 piece set bonus. Now that we have T15 to look forward to that becomes a matter of vanishingly small importance.

        I think the most productive thing I can do is run a critique of each proposed queue and argue for use or dismissal – and give a detailed description of any additional queues I think should be used.

        Part one queues:
        (shield block only queues)
        SB – This queue uses less rage than it gains – this queue should be dismissed because noone would ever play this way and sit on overflowing rage and never use it.
        In conclusion, I do not think we should have any shield block only queues (unless we’re working with a rage starved tank)

        (shield barrier only queues)
        SBr – does use all the rage – but it overwrites shield barriers uncritically. Considered overwriting might be appropriate, but uncritical is not. Should be dismissed
        SBr* – this a simplistic fix to SBr that makes it immediately usable – because rage capping is not a concern.
        SBr60 – should be dismissed. If you mainly use Shield Barrier there is no reason why you would ever sit on your rage and wait to get to 60. You get the same absorb per rage, but the only thing you achieve by waiting for rage is making your dmg more spikey.
        SBr60* – should be dismissed for the same reason SBr60 should.
        In conclusion, I do think we need a shield barrier only queue – but just one. SBr* is it, as long as rage generation is low enough that rage capping cannot occur even when shield barrier decays due to a string of misses.

        Part two queues:
        We need queues that aim for optimal total shield block coverage over the course of the fight – one that tries to do this without delaying any shield blocks so every gap between shield blocks is 3 seconds (bleed), and one that allows that gap to increase and investigates if filling it with shield barriers makes for better spike prevention (weave).
        (bleed queues)
        Basic idea is shield block uptime optimal with excess rage bled into shield barriers.
        B-100, B-105, B-110 – these queues allow allow shield block to be delayed up to 6 seconds if you use shield barrier a fraction of a second before shield block comes off cooldown and after just having used shield slam (if revenge, berserkers rage and battle shout are on a longer cooldown). Because they allow a 9 second gap between shield blocks with only a single shield barrier in the middle thiese.queues should be dismissed.
        B-115 – if the warrior does not have 4 piece T14 set bonus the problem is the same as the above bleed queues. If the warrior does have the 4 piece set bonus the threshold is so close to the cap that wasted rage is a guarantee and not acceptable. Should be dismissed
        B-120 – wasted rage is guaranteed and not acceptable, should be dismissed.
        In conclusion, we do need a bleed queue, but I think the ones used are all unacceptable. The simplest form of bleed queue that would give useful results is:
        IF rage > 60 AND shield block cooldown remaining = 0 USE shield block
        ELSIF rage > 100 AND shield block cooldown remaining > shield slam cooldown remaining USE shield barrier

        (weave queues)
        Basic idea is never using shield barrier when shield block is already up and vice versa.
        W4 – obviously a flawed idea – not sure there was any value including it in the first place. Should be dismissed
        W3, W2, W1, W0 – the critical flaw here is in having a rage requirement of >= 20. Not only will rage always be >=20 after 6 seconds of spending no rage (since shield block activation) it is also absolutely maximizing the shield block delay. These should be dismissed.
        In conclusion, we do need a weave queue, but none of the proposed are fit for purpose. If we do decide to weave we should mainly use shield barrier the instant shield block expires, if we use it at all. The only other question is if we should weave in a shield barrier if we are below 60 rage or if we want to avoid maximizing the shield block delay (which we would do if we empty our rage bar). This is an area where I think multiple variants on the same principle may be useful – like one where shield barrier is used every time regardless, one only if rage is 60 or above and another couple at 80 and 100 rage.

        (weave-bleed queues)
        Since weave queues in principle have the risk of capping rage (especially if it is possible to have a shield block gap without a shield barrier woven in) a rage bleed valve can be a useful addition to a weave queue.
        W3-105, W3-110, W3-115, W3-120 – since the weave you implemented has a rage requirement of 20 there is a guaranteed dump of up to 60 rage as every shield block ends – the next shield block may or may not be delayed a little bit, but shield block will always be used with no great excess of rage on hand and hitting any rage bleed valve above 100 will hardly ever happen. These should be dismissed for the same reason the weave queues themselves should be dismissed – it’s the wrong way to implement a weave queue. Additionally the rage expenditure is underestimated – the posited rage levels will never be achieved
        In conclusion, weave queues may benefit from a bleed valve, especially if the weave queue does not require dumping rage aggressively as soon as shield block expires.

        (FCFS queues)
        This one is magic.
        F-120 – I am not a fan of queues that require you to cap rage.
        F-115, F-110 – I think these are a bit to close to rage capping. Any shield slam or battle shout when rage is above 100 will waste rage. I know it says no rage is wasted on F-110, but it seems unintuitive to me that you will never have been sitting on 101-109 rage while using shield slam or battle shout. I guess the cooldowns on those abilities and the rage expenditures programmed in makes it impossible to land on 101-109 rage without battle shout and shield slam both being on cooldown, but in general I find rage valves above 100 suspicious.
        In conclusion, I love what FCFS does and what it shows – very valuable addition to the modelling of tank ability usage. While I am intuitively concerned about any rage valves that do not go down to 100 (or 95 with sword and board tbh) and I always think 120 and 115 rage valves are automatically unusable due to rage capping I can accept that the highest rage valve that has an xsR(k) of 0.0000 must be viable.

        Special mention.
        SB is an idiot check – if we put together a queue that performs worse than SB then we’ve achieved a special kind of stupid. I do not object to its presence as an idiot check, but if we are comparing viable queues it has no place.

        Now, these are the queues I think we need:

        Additionally I think we need to consider the situation where we aim for an S% of 0.6667 – for this I think we need 3 types of queues. We need a sensible bleed queue, a sensible weave queue and a lazy bleed queue. The lazy bleed queue is the one I mentioned where we pop shield barrier together with shield block to empty our rage bar and have 9 seconds to build up the 60 (55) rage for the next shield block.

        The complete, sensible bleed queue. I pre-empted this in the bleed section above, but this is the full pseudo code for it. The basic idea is that I am looking only one ability into the future. Doing more is doable but unnecessarily complicated – better to just continue using abilities until we get to the threshold.

        IF (rage >= 60 AND remaining shield block cooldown = 0) USE shield block
        ELSIF (rage >= 95 AND sword and board active AND remaining global cooldown = 100 AND remaining shield slam cooldown = 100 AND remaining battle shout cooldown = 105 AND remaining revenge cooldown = 110 AND remaining berserkers rage cooldown = Y factor used below is not a rage valve because it is not checked at all times, only when at the beginning of a shield block gap. That said, it may obviate the need for a rage valve.

        Note that it is possible to use shield block while shield block is up to add 6 seconds to its duration. There is a built-in delay (though it doesn’t show as a global cooldown) so with 120 rage you can use shield block two times maybe 1 or 1.5 seconds apart ending up with a total uptime of 12 seconds with 10+ seconds remaining shield block buff duration after shield block has been used the second time.

        IF (rage >= 60 AND shield barrier is not up AND remaining shield block cooldown = 0) USE shield block
        ELSIF (shield block is not up AND shield barrier is not up AND remaining shield block cooldown > 1.5 AND rage >= Y) USE shield barrier

        Shield barrier will only be used if we are in a shield block gap that has 2-3 seconds left. If the shield barrier is cast at the earliest possible time and a string of misses occur so it decays after 6 seconds the following shield block gap will be exactly 0 seconds. If rage influx is erratic and that subsequent shield block gap becomes longer as a result shield blocks will continue to take priority for rage expenditure until both shield block charges are within one second of being fully on cooldown at which point shield barrier can once again occur. By requiring shield block cooldown to be above 1.5 seconds (and it will of course always be below 3 seconds) we should avoid using shield barrier twice in one shield block gap as well as using shield barrier in shield block gaps that are so small that the value of weaving in a shield barrier is questionable.

        I listed AND rage >= Y. It can be excluded (or have Y set to 20) for a pure weave queue. The question is (as asked above in the weave critique section) if a weave queue will perform differently if it maximizes the shield block delays or is modified to minimize them. The values I think are interesting to investigate are 20, 60, 80 and 100.

        I am intuitively opposed to Y below 60 – and even 60 I’m not too fond of. We’re staring in the face of dropping a low-rage shield barrier and emptying our rage bar with no imminent prospects of a shield block. If sitting on low rage at the end of a shield block it seems wiser to me to reserve that rage for the next shield block so it may occur with not too big a delay. For this reason I think the real decision is going to be between the 80 and 100 rage versions of this. Maybe the problem is not so much emptying the rage bar as it is emptying the rage bar if all you can put up is a pathetic shield barrier. A strong shield barrier may justify emptying the rage bar. For that reason, maybe 40 is also a value that bears investigation. I do expect 20 to fare particularly poorly though.

        The lazy bleed queue. There are a couple of reasons I want to include this. First, I believe that if a sub-optimal queue takes a lot less attention to maintain it can end up performing better in a real situation – it gives the tank more mental freedom to react to mechanics and situations and use emergency buttons. Second, it’s what I currently sometimes do (when busy with mechanics, calling things on ventrilo etc) and I’d be curious to see how much I actually lose by doing it this way. As I described before I think most spikes (3 attacks or more) will include either the first or last attacks under shield block and for that reason a shield barrier that covers the first or last part of shield block can help with those spikes. I completely agree that mitigation on top of mitigation when there are periods with no mitigation at all is probably not ideal, but since 2 attacks are rarely enough to kill a tank having the third attack in the spike both blocked and fully absorbed should not be completely disregarded. Of course, this argument only applies when the dangerous spike has first and second attacks in the block gap so it’s good for probably half the of the dangerous 3 attack spikes, but a larger and larger proportion as we move to 4, 5 and 6 attack spikes.

        IF (remaining shield block cooldown = 0) USE shield block; USE shield barrier

        Remember both are off the global cooldown so can be used in the same fraction of a second – just make sure to hit shield block first. The hidden global cooldown that prevent you from using shield block twice in the same fraction of a second does not apply to using first shield block and then shield barrier. They can land at effectively the same time.

        Due to rage generation cooldowns this queue may end up with shield block gaps above 3 seconds – it would be interesting to know the impact on dangerous damage spikes.

        • Krennick says:

          Complete sensible bleed queue has an error in parsing. Try this:

          IF (rage >= 60 AND remaining shield block cooldown = 0) USE shield block
          ELSIF (rage >= 95 AND sword and board active AND remaining global cooldown = 100 AND remaining shield slam cooldown = 100 AND remaining battle shout cooldown = 105 AND remaining revenge cooldown = 110 AND remaining berserkers rage cooldown <= remaining shield block cooldown) USE shield barrier

        • Krennick says:

          Nope, not parsing right. Too close to code I guess.

          If you have enough rage to shield block and it’s off cooldown, use it.
          Otherwise, if you have 95 rage, sword and board proc and global cooldown allows you to use shield slam before you need to hit shield block – go shield barrier
          Similarly, if you have 100 rage, no sword and board proc and cooldown on shield slam is less than cooldown of shield block – go shield barrier
          And, if you have 100 rage, battle shout on less cooldown than shield block – go shield barrier.
          Also, if you have 105 rage and will be able to use revenge before shield block becomes available – go shield barrier
          Last, if you have 110 rage and will be able to use berserkers rage before shield block becomes available – go shield barrier.

        • Krennick says:

          Also missing lots of explanatory text after the sensible bleed queue. Here goes – first paragraph relates to bleed queue, subsequent ones are the beginning to the sensible weave queue that got cut.

          Basically the question is whether incoming rage would make you cap before shield block comes off cooldown – if yes, bleed now. I’m well aware that the 1 rage per 3 seconds is overlooked. This is deliberate and the impact is minute.

          The complete, sensible weave queue. The idea is that shield barrier can be used in the 3 second gap between shield blocks, and that the value of that shield barrier outweighs any cost that may be incurred if shield blocks are occasionally delayed.

          An underlying goal is to still strive for an S% of 0.6667 so it may be sensible to have the weave decision contingent on whether the last shield block (or couple of shield blocks) have already been delayed. Fortunately, shield block has two charges, so if we just first check if shield block is off cooldown and use it if it is, when a shield block delay has built to 3 seconds we will automatically have two shield blocks in a row.

          Additionally, we need to decide if we want to use shield block while shield barrier still has some absorb left in it. On the one hand, S% at 0.6667 is a stated objective and waiting for shield barrier to decay or be hit can prolong the shield block delay – but because shield barrier duration is only 6 seconds and shield blocks can be used back to back even the worst case does not compromise our target S%. On the other hand a shield barrier with only very little absorb left in it is perhaps best considered not up. While it is simple in-game with addons to make decisions based on this, for modelling it becomes a needless complication. It does not introduce a risk of S% going below 0.6667 and therefore is not worth modelling.

          Last, we have the question of the bleed valve. Especially if we somehow manage to have 12 seconds of uninterrupted shield block we may have a situation where rage caps while we are under shield block. For the purpose of the integrity of the weave I would propose such rage capping is accepted and assessed. If it is substantial maybe a bleed valve can be considered. Note that the rage >= Y factor used below is not a rage valve because it is not checked at all times, only when at the beginning of a shield block gap. That said, it may obviate the need for a rage valve.

        • Theck says:

          Great comments, I’m not sure why WordPress is having trouble parsing your conditionals, but your clarifications cleared it up enough to be understandable.

          Regarding the rest of your comments – I think your criticism of the Bleed and Weave/Bleed queues is accurate. Though keep in mind that these weren’t conceived of by me as an optimization strategy. These were me attempting to model the way warriors play based on discussions I’ve had with warriors. In other words, I was modeling what they tell me they are doing, not what I think they should do.

          Your proposals for improved B and W/B queues look good to me. They basically go to the next logical step, which is estimating rage gain before SB comes off of cooldown and making choices accordingly. The reason I avoided these in the past is twofold: first, because you end up with a rather complicated conditional, which makes it hard to track down errors and cause/effect relations when things go wrong. But more importantly, players I spoke to basically said that while such a queue would be rigorous, it would also be very difficult to actually perform. And as a result, it wouldn’t be a realistic model of what a player actually does.

          That said, we’ve seen that the earlier versions of B and WB weren’t beneficial anyway, so it seems sensible to implement your improved versions.

          I also like the idea of the “lazy bleed.” The rationale seems sensible to me: if your serious damage events are always going to involve 2+ full melees from the 3 seconds of SB downtime, then throwing everything you’ve got at the subsequent attack is an targeted spike-mitigation strategy. So I’ll implement that one too.

          And of course, I’ll fix the bugs you’ve pointed out. SBr rage consumption mechanics, primarily – I agree that the T14 tier bonus issue is mostly irrelevant with 5.2 in the near future. Are those the only two, or am I forgetting others?

          • Krennick says:

            I don’t know which players you were talking to, but when tanking I often use something like the bleed queue that I outlined. With the obvious exception that I take much more into account. I look more than one cooldown into the future (triggering at 80 if I have both battle shout and shield slam available for instance), as well as sometimes not bleeding the instant I know that I can afford to bleed – perhaps waiting the last 2 seconds of shield block coverage and triggering my bleed at the beginning of the shield block gap. Sometimes I even compromise my rage generation – like if it’s 2 seconds before shield block expires, shield slam comes off cooldown in 1 second and I am at 114 rage. I can choose then to delay shield slam by 1 second by using first shield barrier then shield slam and both after shield block has expired. While that is a carefully constructed example it is certainly true to say that I often time my bleeds (and shield blocks) to occur at the same time as (but immediately prior to) rage generators. In the model abilities that generate rage are treated completely separately from abilities that use rage. In-game they’re tied together to a much higher degree.

            Imo the bleed queue I described is actually simplistic.

            Funnily enough, the weave queue is difficult for me. For some reason it’s more natural to me to respond to rage levels and take timings into account as a secondary thing than tying myself to relatively close timings. I think that if you were to implement weaving, the way I described it is how you would do it. But should you use a Y of 20, 40, 60, 80 or 100? I frankly have no clue. It’s an area where I wouldn’t even like to test. This is an area where I’d value a model to pinpoint one as optimal or a couple as viable before I even start playing with it. In theory, this should be the absolutely optimal way to tank – as you have pointed out staggering mitigations usually is, and the whole point of this weave queue is to stagger mitigations in as optimal way as possible.

            On the one hand you could say it’s an exercise worth doing to understand the maximum theoretical value of staggering mitigations for a warrior (and a useful benchmark for more manageable queues), but we also know that as soon as we’ve proved that it is clearly superior someone is going to practice it, get it to work, publish a guide, maybe program an addon to support it etc.

            I think the Shield Barrier rage cost being variable from 20 to 60 is the only real bug I found – I’m not sure which other you are referring to. The only other thing I can think of is if you had shield block done wrong. I didn’t know, which is why I made sure to explain that shield block used while shield block is already up will just add 6 seconds to the duration of the shield block buff. Additionally (and of no real importance to the model, it can be safely ignored) shield block has a hidden internal cooldown so you cannot use it twice (by accident either) by pressing the key twice – the key presses have to be at least 1 second or 1.5 second apart. But for modelling it doesn’t really matter if you get 12 seconds shield block now, or 6 seconds now and an additional 6 seconds 1.5 seconds later. It will still end at the same time. Shield block is off the global cooldown.

          • Theck says:

            Yeah, the Shield Block modeling is correct for the charge system. It works additively and properly sets and reduces the cooldown on each charge.

      • Krennick says:

        I’m a bit like a broken record. Re-reading your reply seemed prudent as dialogue is supposed to go two ways and I’m painfully aware that I’m mostly just spouting what I think instead of responding the comments that you make. I treasure your responses, though I do not always feel there would be anything gained by me responding to your responses, if you know what I mean.

        However,in re-reading this something struck me that I forgot to mention – or at least forgot to mention with reference to your points. When a warrior uses shield block a lot his damage intake profile looks a particular way – damage taken during shield block and damage taken in shield block gaps have different damage intake profiles. In a sense my lazy bleed strategy is an unthinking (though intended) way to implement shield barrier as a response to a damage spike. I claim that most dangerous damage spikes will include two hits in the 3 second shield block gap and that following the 3 second block gap with an automatic shield barrier (after rage has been used on shield block) will function as a response to a low-health situation a large percentage of the time low-health situations occur.

        In other words, one additional reason why the lazy bleed strategy may be worth modelling.

        The thought comes partly from your point that damage intake profiles are important to consider if we are to evaluate shield barrier as a survival response. While I agree with the principle that strings of hits (with no dodge/parry/miss) are particularly interesting to investigate, I initially felt that assessing the damage intake over the last few hits seemed an incomplete simulation. Of (deliberately) overlooked and particular importance is whether healers are filling you up or whether they are preoccupied. Similarly, most bosses have varying ways to do more or less dmg at times. Bottom line is that it’s health that matters, not just damage. In some cases healers will use cooldowns when known spikes occur and all of that is completely true, and at the same time completely not necessary to model something useful. While I strain against using a simple “if damage in the last N seconds exceeds X” conditional, I must ultimately accept that it can be useful to model.

        However, it would obviously need to be slightly more complicated than that. At least “if damage LESS the value of any shield barriers erected in the last N seconds exceeds X “. And still, I dovetail back to my lazy bleed strategy – since shield block gaps are of particular importance firing off a shield barrier automatically at the end of each shield block gap could well obviate the need for (and value of) that type of conditional.

        Another interesting factor to consider is the characteristics that a queue must have for that type of conditional to be effective. For instance, a queue that burns rage pretty quickly and never lets it pool very high will maybe never trigger that kind of conditional.

        “Regarding the discretization of SBarr: I wasn’t aware the ability worked that way, but it would be easy to fix in the simulation. That said, it won’t have a large effect on the results. Stochastically, it should all average out. If anything it may make use of Shield Barrer at <60 rage even worse, simply because there's no chance of retaining 10-15 rage by missing a threshold value."

        This is exactly why I wanted it corrected. When a rage remnant is not possible for many uses of shield barrier it changes when the next shield barrier or block becomes available. Also, though I think you have a solid set of stats coming out, I would be curious to have the headline stats expanded. Partly I think there is something missing in the area of number of shield blocks (implied by S% I know) in a way that is comparable to numbers of shield barriers used. Or maybe rage spent on shield block vs shield barrier. Or damage mitigated per point of rage spent in shield block vs shield barrier. Or damage mitigation lost in shield barrier by having shield barrier expire before being used to mitigate damage. I completely agree that the most important part of the output is the damage smoothing section, but these would still be interesting to me to see. SBr(k) and SBr<60(k) I could easily do without though. I think it would be good to remove those two and put in three stats for damage mitigated (by shield block) per rage point spent on shield block, damage mitigated (by shield barrier) per rage point spent on shield barrier and damage mitigation from shield barrier that went unused.

        • Theck says:

          The moving-average damage taken model certainly has limitations. As you say, often what matters is health, not how much damage you’ve taken recently. But that gets far more complicated to simulate, because you basically have to start writing an entire healing AI, amongst other issues. I’ve had some discussions with a friend of mine that does those sorts of things, but I think at that point this is simply the wrong tool for the job. A tool that’s more robust (i.e. Simcraft) is going to do a better job in that case, I think. It’s something I’m already looking into for my Paladin modeling, in fact.

          That said, there are definitely advantages to this sim. For one, It’s fast and easy to modify. But perhaps more importantly, the results still have a good deal of relevance. While your healer is likely to pop a cooldown when your health drops dramatically (or for that matter, you may pop one yourself), you’re also less likely to die in that situation as a result of the cooldown. Cooldowns are the modern tank’s anti-spike mitigation, and we use them liberally.

          However, that means you’re more likely to die when you or your healer fail to react (i.e. preoccupied/distracted). And that’s exactly the situation this sort of simulation tries to address. It’s even got some applicability when you are running a cooldown – for example, having a 50% cooldown active but starting at 50% health.

          • Krennick says:

            I wasn’t really trying to make a point for including a full healing model, just explaining my intuitive concerns with the limited damage taken recently model. I think your model does not take into account boss spike abilities, tank cooldowns or healer cooldowns and in a sense it’s better for it. It models the steady state of tanking, not the exceptions. Since the exceptions are all about tailoring your responses and acting either reactively or proactively, and either on your own or in congress with your healers, it’s not something that lends itself well to this type of modelling.

            I repeat that I do think listing absorbs put up by shield barrier that ended up not being used would be a valuable addition. Removal of the current shield barrier stats and including the blocked/absorbed per rage stats is meh – could go either way – but including the wasted absorbs I think will be valuable in certain situations – not unlike the wasted rage stat in the kinds of things it reveals.

            While it may not be mathematically possible (either in current gear, or ever) to get to that point, the thinking behind it is to account for the situations where high avoidance gear levels cause the absorb of shield barriers to go unused so often that (with that gear set) shield barrier based queues become strictly worse (TDR for instance) and this stat could be an early indication or explanation of why that is.

            On reflection a dodge/parry/miss sequence also reduces the value of shield block. Maybe it isn’t a valuable stat. Or maybe the blocked/absorbed per rage stats combined with the absorbs wasted stat would tell us if shield block or shield barrier is hit worse by prolonged dodge/parry/miss events.

            What such stats may ultimately show is that if you stack avoidance you can get to a point where shield block and shield barrier are so devalued that rage generation stats become devalued too.

            On the subject of additional stats, have you considered adding a 70% and maybe a 60% section to the damage smoothing stats? It’s obvious it will be of no value for 2 attacks, but at 7 attacks it may be. In a sense the question is, at 7 attacks will 70% (or 60%) be enough damage to kill the tank, absent heals? Pre-occupied healers etc. I appreciate the lower we go there the more the rankings of queues and equipment sets will begin to resemble TDR, but bottom line is that the smoothing stats indicate the presence of a potential killing spike. 90% of 2 attacks is not a killing spike. 60% of 7 attacks may be.

          • Theck says:

            I think the “wasted absorb” stat is probably worth adding as well. I probably won’t get to edit the code until after 5.2, but it will definitely be on the list of changes. Absorbed per rage spent is a simple calculation to do in post-processing, but blocked/mitigated per rage spent is trickier because of the way blocking works. First, you have to separate normal blocks and crit blocks from those with Shield Block up, which can’t be done in post-processing without more tracking variables. Second, some of those blocks and crit blocks during SB would have been blocks or crit blocks even in the absence of SB, so you’d need to subtract out those based on a simple probability model. It can be done, but I’m not sure it will tell us enough to be worth the work that goes into it.

            When writing the updated 5.2 paladin simulations (published later this week, most likely) I added the 70% and 60% categories. It’s a trivial change, so I’ll certainly do that for the next round of warrior sims as well.

          • Krennick says:

            Awesome, thanks. The wasted absorb and lower percentage categories for damage smoothing are the stats I suggested I think will be most valuable.

            Even if it’s simple to do I don’t think there’s any reason to include absorbed rage per rage spent if you do not include dmg mitigated through shield block/crit block per rage spent. Those two stats only have value when used in comparison. Adding more stats may appeal to the mathematician and engineer but for the casual reader it’s more important that each stat listed has a distinct value and meaning. This is also why I was arguing for the removal of some stats. It’s the old signal to noise ratio idea.

            Reading your reply my mind did go on a tangent about how a stat for mitigated by shield block per rage could be interesting to show the value of mastery, but on closer reflection that would only tell us something that we already know anyway (that you block more dmg when you have higher mastery) – sure it may qualify it further, but I’m not convinced it would add any value for that.

            While I personally think it’s valuable to include 70% and 60% categories at 7 attacks the value at 2 attacks is pretty slim. It may be worthwhile to either vary the number of categories you include as the number of attacks increases – or point out in the explanatory text why the lower percentage categories are particularly un-useful at the lower attacks and more useful at higher attacks.

Leave a Reply