Out of Insight, Out of Mind

Posted on May 21, 2013 by Theck

In the last post, we discussed a variety of topics related to modeling Seal of Insight.  Now it’s time to put that modeling discussion to work.

The Model

I decided to stick with the conclusion I came to in my last post.  I’m modeling SoI with a backwards-facing method, in which each SoI proc reduces the damage done by the previous attack.  This limits the scope of SoI to one attack in the past and creates incidental overheal whenever that attack was a dodge or parry.  I’m also not applying any sort of overheal function to simulate indirect overhealing, so every Seal of Insight proc acts at full strength.

This will over-represent Seal of Insight’s usefulness in overall damage mitigation (i.e. TDR), because in many cases it will compete with HoTs and other low-throughput healing effects and cause a significant amount of overhealing.  However, it will more accurately represent the behavior during high-throughput periods (i.e. spikes), where that healing is far less likely to be wasted.  Since we’re mostly looking at the top two or three levels of spike damage in these simulations anyway, it makes more sense to bias the results towards accuracy in that region.

I’ll also note that I’ve implemented the 5.3 nerf to Shield of the Righteous, so it’s base mitigation is already 25% in these simulations.

For completeness, and for any newcomers to this blog, here’s a quick overview of how the simulation works:

To better understand the data below, here’s a rough overview of how it’s generated: I run a Monte-Carlo sim that simulates 10k minutes of combat (think Simcraft, but paladin-specific and more limited in scope), making all combat rolls and logging all damage events.  I take the resulting string of attacks (something like “1, 0, 0.7, 1, 0, 0, …” where 0 is an avoid (no damage), 1 is a full hit, 0.7 is a block, and so on) and do some calculations on it.  I calculate the average damage intake normalized to 100% possible throughput (i.e. “1, 1, 1, 1, 1, …”), and report that in the “mean” row, representing mean damage intake (lower is better, represents better TDR).  “std” is just the standard deviation of that mean as averaged over 5 attacks.  “S%” is SotR uptime.

The rest of the rows are smoothing data for strings of N attacks.  For now, let’s just consider the first gear column (C/Ha).  I take the damage event sequence and perform a moving average on it (i.e. an N-attack moving average).  I then calculate how many of those N-attack averages exceed a certain percentage of the player’s health.  So for example, if we look at a 3-attack moving average, the “70%” row tells me how many of those 3-attack averages exceed 70% of the player’s health.  Note that the categories are cumulative, so if 5% of attacks exceed 90% health, those attacks are also being counted in the 80% and 70% rows (thus, if 17% of attacks exceed 80% health, the percentage between 80% and 90% is 17%-5%=12%).  I should add that the repeatability on these simulations is quite good thanks to the long integration time – results usually fluctuate by less than +/- 0.1% (absolute, i.e. 5% +/- 0.1%).

I do this for a bunch of different gear sets, i.e. “C/Ha” for Control/Haste, etc.  The gear list tables provide the stats of each gear configuration so you get a rough idea of what they look like.  They’re roughly equivalent to stats in ilvl 522 gear.

The code can be found in the matlabadin repository, as usual.  The two files in particular are pally_mc.m and pally_mc_smooth.m.

I’m going to dump a lot of data on you here, so bear with me.  I’ll provide as much commentary as makes sense, but there will be a lot of repetition since most of the data sets look roughly similar.

Standard Panels

First, we’ll do our “standard panel” that compares the basic gear sets: Control/Haste, Control/StamGem (where we convert 4k haste into 3k stamina by swapping gems), Control/Mastery, Control/Avoidance, Control/Balance, Control/HasteMastery, Avoidance, Avoidance/Mastery, and Mastery/Avoidance.  Those gear sets are given in the table below:

|    Set: |  C/Ha |  C/Sg |  C/Ma |  C/Av | C/Bal |  C/HM | Avoid | Av/Mas | Mas/Av |
|     Str | 15000 | 15000 | 15000 | 15000 | 15000 | 15000 | 15000 |  15000 |  15000 |
|     Sta | 28000 | 31000 | 28000 | 28000 | 28000 | 28000 | 28000 |  28000 |  28000 |
|   Parry |  1500 |  1500 |  1500 |  7500 |  4125 |  1500 | 10825 |   7717 |   4000 |
|   Dodge |  1500 |  1500 |  1500 |  7500 |  4125 |  1500 | 10825 |   7717 |   4000 |
| Mastery |  1500 |  1500 | 13500 |  1500 |  4125 |  6750 |  1500 |   7716 |  15150 |
|     Hit |  2550 |  2550 |  2550 |  2550 |  2550 |  2550 |   500 |    500 |    500 |
|     Exp |  5100 |  5100 |  5100 |  5100 |  5100 |  5100 |   500 |    500 |    500 |
|   Haste | 12000 |  8000 |     0 |     0 |  4125 |  6750 |     0 |      0 |      0 |

I haven’t updated these for 5.3, mostly because I haven’t had time.  In all likelihood, nothing changes by bumping the ilvl slightly anyway.  First, let’s look at the data for a 10-man normal mode boss that hits for 150k per swing after mitigation:

Finisher = SH1, Boss Attack = 150k, SoI model=nooverheal, data set smooth-10000-77

| Set: |   C/Ha |   C/Sg |   C/Ma |   C/Av |  C/Bal |   C/HM |  Avoid | Av/Mas | Mas/Av |
| mean |  0.227 |  0.251 |  0.248 |  0.254 |  0.244 |  0.222 |  0.253 |  0.258 |  0.262 |
|  std |  0.103 |  0.106 |  0.110 |  0.125 |  0.113 |  0.102 |  0.138 |  0.131 |  0.126 |
|   S% |  0.522 |  0.482 |  0.410 |  0.420 |  0.452 |  0.471 |  0.366 |  0.362 |  0.357 |
|   HP |   755k |   816k |   755k |   755k |   755k |   755k |   755k |   755k |   755k |
|  nHP |  5.034 |  5.439 |  5.034 |  5.034 |  5.034 |  5.034 |  5.034 |  5.034 |  5.034 |
| ---- | ------ |  --- 2 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  10% | 43.049 | 48.638 | 46.573 | 48.233 | 48.137 | 44.968 | 45.969 | 46.010 | 47.654 |
|  20% |  6.546 |  5.883 | 11.663 | 12.846 | 10.383 |  7.632 | 14.289 | 14.371 | 14.275 |
|  30% |  0.165 |  0.036 |  0.665 |  1.117 |  0.682 |  0.266 |  1.774 |  1.448 |  1.304 |
| ---- | ------ |  --- 3 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  20% | 19.140 | 20.327 | 26.172 | 30.344 | 26.195 | 20.294 | 31.925 | 31.083 | 30.555 |
|  30% |  1.131 |  0.808 |  4.640 |  6.188 |  3.544 |  1.718 |  8.119 |  7.231 |  7.526 |
|  40% |  0.001 |  0.005 |  0.259 |  0.390 |  0.147 |  0.004 |  0.841 |  0.750 |  0.747 |
|  50% |  0.001 |  0.000 |  0.001 |  0.014 |  0.006 |  0.000 |  0.064 |  0.037 |  0.035 |
| ---- | ------ |  --- 4 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  20% | 39.889 | 42.935 | 47.796 | 50.088 | 47.584 | 40.228 | 49.763 | 50.423 | 51.479 |
|  30% | 10.957 |  9.586 | 13.558 | 19.193 | 14.404 |  9.897 | 20.855 | 19.195 | 19.098 |
|  40% |  0.679 |  0.707 |  2.204 |  3.037 |  1.757 |  0.941 |  4.865 |  4.176 |  4.346 |
|  50% |  0.017 |  0.012 |  0.150 |  0.257 |  0.111 |  0.041 |  0.709 |  0.600 |  0.629 |
|  60% |  0.001 |  0.000 |  0.000 |  0.001 |  0.000 |  0.000 |  0.025 |  0.020 |  0.017 |
| ---- | ------ |  --- 5 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  30% | 24.849 | 23.976 | 30.836 | 35.357 | 30.603 | 23.005 | 35.410 | 34.973 | 36.024 |
|  40% |  4.000 |  4.359 |  8.320 | 11.603 |  8.412 |  4.380 | 13.892 | 13.213 | 13.085 |
|  50% |  0.404 |  0.283 |  1.177 |  2.515 |  1.182 |  0.344 |  3.978 |  3.317 |  3.211 |
|  60% |  0.008 |  0.005 |  0.130 |  0.206 |  0.088 |  0.011 |  0.632 |  0.519 |  0.539 |
|  70% |  0.000 |  0.000 |  0.004 |  0.011 |  0.001 |  0.001 |  0.069 |  0.055 |  0.043 |
|  80% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.001 |  0.002 |  0.001 |
| ---- | ------ |  --- 6 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  30% | 41.134 | 41.499 | 47.962 | 50.478 | 47.235 | 38.445 | 49.038 | 49.938 | 52.001 |
|  40% | 11.311 | 12.159 | 19.450 | 23.400 | 19.099 | 11.473 | 25.190 | 25.009 | 25.453 |
|  50% |  1.748 |  1.394 |  4.638 |  7.871 |  4.398 |  1.570 | 10.062 |  9.292 |  8.998 |
|  60% |  0.046 |  0.033 |  0.668 |  1.436 |  0.605 |  0.080 |  2.764 |  2.347 |  2.127 |
|  70% |  0.001 |  0.000 |  0.064 |  0.190 |  0.041 |  0.002 |  0.541 |  0.407 |  0.388 |
|  80% |  0.000 |  0.000 |  0.003 |  0.007 |  0.002 |  0.000 |  0.065 |  0.051 |  0.045 |
|  90% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.006 |  0.003 |  0.003 |
| ---- | ------ |  --- 7 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  40% | 23.886 | 25.744 | 33.245 | 36.754 | 32.783 | 23.224 | 37.333 | 38.102 | 39.434 |
|  50% |  6.574 |  6.640 | 11.688 | 16.426 | 10.957 |  5.941 | 18.512 | 18.043 | 17.997 |
|  60% |  0.835 |  0.743 |  2.535 |  4.717 |  2.290 |  0.846 |  6.948 |  6.274 |  5.910 |
|  70% |  0.059 |  0.033 |  0.293 |  0.913 |  0.253 |  0.067 |  1.954 |  1.576 |  1.414 |
|  80% |  0.001 |  0.000 |  0.025 |  0.090 |  0.012 |  0.002 |  0.373 |  0.283 |  0.246 |
|  90% |  0.000 |  0.000 |  0.001 |  0.006 |  0.000 |  0.000 |  0.052 |  0.030 |  0.032 |
| 100% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.004 |  0.002 |  0.001 |

This seems like a pretty clear win for Control/Haste.  You may have been expecting Control/Mastery to pull ahead thanks to the SotR nerf, and if we were ignoring Seal of Insight it does. In fact, without SoI active, Control/Mastery is very competitive across the board.

But Seal of Insight procs push haste significantly ahead.  Remember that each Seal of Insight proc is healing for about 20% of a boss attack, so as long as the previous attack wasn’t avoided each proc acts like a miniature block.  And we get more procs than we do boss attacks, statistically speaking, so we basically have about one 20% block ready for each potential melee attack.  That’s a huge value.

As I noted in the last post, this gives Control/Haste a strong passive mitigation component via Seal of Insight, which is what it lacked in previous simulations.  That’s the main reason that Control/Mastery was able to compete in the higher-number-of-attacks categories before.  But here we see Control/Haste taking that spot.

I should add, however, that Control/Stamina still reigns supreme for raw survivability.  We still get more survivability by converting Haste gems to Stamina gems, even at this low attack size threshold.  The reason I call this category for Control/Haste is that even a 7-attack string doesn’t exceed 80% of the player’s health, so that extra stamina isn’t really necessary.  Note, however, that this assumes a tank with 755k health raid-buffed, and many 10-man tanks are running less than that.  But I still think Control/Haste wins the day for normal-mode 10-man content.

Next, we’ll look at the 250k boss attack data, which is our 10-man heroic / 25-man normal boss:

Finisher = SH1, Boss Attack = 250k, SoI model=nooverheal data set smooth-10000-76

| Set: |   C/Ha |   C/Sg |   C/Ma |   C/Av |  C/Bal |   C/HM |  Avoid | Av/Mas | Mas/Av |
| mean |  0.250 |  0.274 |  0.268 |  0.270 |  0.264 |  0.249 |  0.269 |  0.275 |  0.278 |
|  std |  0.102 |  0.105 |  0.106 |  0.122 |  0.112 |  0.103 |  0.137 |  0.130 |  0.123 |
|   S% |  0.522 |  0.482 |  0.411 |  0.419 |  0.453 |  0.471 |  0.366 |  0.362 |  0.357 |
|   HP |   755k |   816k |   755k |   755k |   755k |   755k |   755k |   755k |   755k |
|  nHP |  3.021 |  3.263 |  3.021 |  3.021 |  3.021 |  3.021 |  3.021 |  3.021 |  3.021 |
| ---- | ------ |  --- 2 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  20% | 42.078 | 36.083 | 45.410 | 45.450 | 45.211 | 44.773 | 42.991 | 44.828 | 46.785 |
|  30% | 14.655 | 14.598 | 17.825 | 20.553 | 18.808 | 16.156 | 22.076 | 22.961 | 22.151 |
|  40% |  1.581 |  1.950 |  4.326 |  4.564 |  3.465 |  2.270 |  7.173 |  7.537 |  7.114 |
|  50% |  0.114 |  0.049 |  0.520 |  0.874 |  0.516 |  0.164 |  1.560 |  1.420 |  1.309 |
|  60% |  0.000 |  0.003 |  0.018 |  0.025 |  0.016 |  0.005 |  0.149 |  0.148 |  0.124 |
| ---- | ------ |  --- 3 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  30% | 39.360 | 38.142 | 37.345 | 44.477 | 41.242 | 38.137 | 42.986 | 44.382 | 42.508 |
|  40% |  8.503 | 10.763 | 15.188 | 18.103 | 14.772 | 10.706 | 21.322 | 21.559 | 20.696 |
|  50% |  1.355 |  1.289 |  4.676 |  5.786 |  3.746 |  2.142 |  8.101 |  7.849 |  7.994 |
|  60% |  0.151 |  0.077 |  1.027 |  1.399 |  0.700 |  0.269 |  2.643 |  2.421 |  2.543 |
|  70% |  0.002 |  0.003 |  0.130 |  0.278 |  0.102 |  0.003 |  0.672 |  0.649 |  0.641 |
|  80% |  0.000 |  0.000 |  0.014 |  0.060 |  0.018 |  0.000 |  0.184 |  0.161 |  0.135 |
|  90% |  0.000 |  0.000 |  0.000 |  0.000 |  0.001 |  0.000 |  0.027 |  0.025 |  0.014 |
| ---- | ------ |  --- 4 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  40% | 32.289 | 35.037 | 36.081 | 39.780 | 37.409 | 33.129 | 39.981 | 42.235 | 42.126 |
|  50% | 14.136 | 11.959 | 15.007 | 21.016 | 16.922 | 13.521 | 22.454 | 22.357 | 21.442 |
|  60% |  4.256 |  3.039 |  5.228 |  8.388 |  5.820 |  3.907 | 10.804 |  9.415 |  9.129 |
|  70% |  0.639 |  0.506 |  1.494 |  2.212 |  1.392 |  0.980 |  4.060 |  3.521 |  3.732 |
|  80% |  0.067 |  0.048 |  0.402 |  0.545 |  0.334 |  0.185 |  1.357 |  1.326 |  1.414 |
|  90% |  0.001 |  0.001 |  0.034 |  0.051 |  0.029 |  0.005 |  0.355 |  0.388 |  0.369 |
| 100% |  0.000 |  0.000 |  0.001 |  0.003 |  0.003 |  0.000 |  0.083 |  0.077 |  0.063 |
| 110% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.003 |  0.003 |  0.001 |
| ---- | ------ |  --- 5 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  50% | 32.320 | 30.188 | 35.995 | 39.665 | 35.861 | 31.226 | 38.853 | 40.103 | 40.903 |
|  60% | 15.028 | 12.682 | 18.679 | 23.359 | 19.306 | 13.900 | 24.320 | 23.745 | 24.010 |
|  70% |  4.623 |  4.047 |  6.961 | 11.113 |  8.347 |  4.777 | 13.320 | 12.426 | 12.309 |
|  80% |  0.799 |  0.773 |  2.132 |  4.000 |  2.715 |  1.320 |  6.258 |  5.748 |  5.314 |
|  90% |  0.100 |  0.063 |  0.496 |  1.027 |  0.610 |  0.215 |  2.419 |  2.207 |  1.948 |
| 100% |  0.009 |  0.004 |  0.097 |  0.205 |  0.119 |  0.028 |  0.824 |  0.727 |  0.672 |
| 110% |  0.000 |  0.000 |  0.015 |  0.033 |  0.016 |  0.001 |  0.227 |  0.206 |  0.207 |
| 120% |  0.000 |  0.000 |  0.001 |  0.003 |  0.001 |  0.000 |  0.059 |  0.054 |  0.055 |
| 130% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.011 |  0.010 |  0.011 |
| 140% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.001 |  0.001 |  0.001 |
| ---- | ------ |  --- 6 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  60% | 31.122 | 28.454 | 36.137 | 39.727 | 35.931 | 28.814 | 38.649 | 39.354 | 40.844 |
|  70% | 13.490 | 12.783 | 18.888 | 24.148 | 19.920 | 13.297 | 25.299 | 24.893 | 25.561 |
|  80% |  3.788 |  3.859 |  7.984 | 11.956 |  8.868 |  4.952 | 14.591 | 14.231 | 13.811 |
|  90% |  0.778 |  0.566 |  2.575 |  4.953 |  2.970 |  1.275 |  7.308 |  7.083 |  6.474 |
| 100% |  0.103 |  0.070 |  0.689 |  1.795 |  0.848 |  0.238 |  3.425 |  3.105 |  2.694 |
| 110% |  0.003 |  0.002 |  0.143 |  0.552 |  0.183 |  0.014 |  1.401 |  1.172 |  1.031 |
| 120% |  0.000 |  0.000 |  0.021 |  0.085 |  0.026 |  0.000 |  0.469 |  0.388 |  0.336 |
| 130% |  0.000 |  0.000 |  0.002 |  0.008 |  0.003 |  0.000 |  0.128 |  0.120 |  0.106 |
| 140% |  0.000 |  0.000 |  0.000 |  0.001 |  0.001 |  0.000 |  0.034 |  0.035 |  0.033 |
| 150% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.007 |  0.007 |  0.006 |
| 160% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.001 |  0.001 |  0.001 |
| ---- | ------ |  --- 7 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  60% | 48.319 | 47.006 | 54.198 | 55.111 | 52.824 | 46.176 | 52.256 | 54.221 | 56.922 |
|  70% | 29.026 | 28.625 | 34.520 | 39.075 | 35.332 | 27.789 | 38.363 | 39.050 | 40.749 |
|  80% | 13.750 | 13.940 | 18.621 | 23.875 | 19.770 | 13.974 | 25.522 | 25.841 | 25.816 |
|  90% |  5.280 |  4.517 |  8.249 | 12.710 |  8.748 |  5.686 | 15.166 | 15.259 | 14.590 |
| 100% |  1.585 |  1.229 |  3.069 |  5.933 |  3.316 |  1.898 |  8.483 |  8.080 |  7.473 |
| 110% |  0.323 |  0.258 |  0.915 |  2.406 |  1.068 |  0.488 |  4.283 |  3.848 |  3.447 |
| 120% |  0.040 |  0.035 |  0.202 |  0.727 |  0.247 |  0.089 |  1.847 |  1.619 |  1.348 |
| 130% |  0.002 |  0.003 |  0.036 |  0.185 |  0.034 |  0.007 |  0.715 |  0.601 |  0.492 |
| 140% |  0.000 |  0.000 |  0.003 |  0.039 |  0.005 |  0.001 |  0.252 |  0.212 |  0.168 |
| 150% |  0.000 |  0.000 |  0.000 |  0.006 |  0.000 |  0.000 |  0.068 |  0.060 |  0.047 |
| 160% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.017 |  0.016 |  0.013 |
| 170% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.003 |  0.003 |  0.002 |

Again, Control/Stamina and Control/Haste lead the pack by a good margin.  Not much else has changed from the 150k swing data; avoidance sets still perform poorly and none of the other secondary stats seem capable of coming close to haste.  The loss going from haste to mastery is significant enough now that we’re not even seeing any advantage from the Control/HasteMastery set.  That said, we’ve seen in the past that the results can fluctuate with small haste changes, so it’s something we’ll have to investigate in more detail in the future.

On to the heroic 25-man boss that hits for 350k per swing:

Finisher = SH1, Boss Attack = 350k, SoI model=nooverheal data set smooth-10000-75

| Set: |   C/Ha |   C/Sg |   C/Ma |   C/Av |  C/Bal |   C/HM |  Avoid | Av/Mas | Mas/Av |
| mean |  0.262 |  0.285 |  0.280 |  0.280 |  0.275 |  0.259 |  0.278 |  0.283 |  0.289 |
|  std |  0.103 |  0.106 |  0.107 |  0.123 |  0.114 |  0.104 |  0.138 |  0.132 |  0.124 |
|   S% |  0.523 |  0.483 |  0.410 |  0.419 |  0.452 |  0.472 |  0.366 |  0.363 |  0.357 |
|   HP |   755k |   816k |   755k |   755k |   755k |   755k |   755k |   755k |   755k |
|  nHP |  2.158 |  2.331 |  2.158 |  2.158 |  2.158 |  2.158 |  2.158 |  2.158 |  2.158 |
| ---- | ------ |  --- 2 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  30% | 32.885 | 36.244 | 40.808 | 38.572 | 38.969 | 36.939 | 38.423 | 40.839 | 43.191 |
|  40% | 15.408 | 18.540 | 20.995 | 21.878 | 21.142 | 16.677 | 23.657 | 23.467 | 25.393 |
|  50% |  5.739 |  5.277 | 10.463 | 11.052 |  9.539 |  7.228 | 13.314 | 13.769 | 13.182 |
|  60% |  1.303 |  1.273 |  4.355 |  4.130 |  3.296 |  2.186 |  6.670 |  7.288 |  6.599 |
|  70% |  0.178 |  0.055 |  1.180 |  1.249 |  0.933 |  0.332 |  2.565 |  2.571 |  2.748 |
|  80% |  0.007 |  0.004 |  0.192 |  0.275 |  0.124 |  0.034 |  0.640 |  0.569 |  0.432 |
|  90% |  0.001 |  0.000 |  0.011 |  0.022 |  0.011 |  0.005 |  0.134 |  0.128 |  0.084 |
| ---- | ------ |  --- 3 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  40% | 41.345 | 45.922 | 44.756 | 46.843 | 47.672 | 39.535 | 45.936 | 45.980 | 47.873 |
|  50% | 20.671 | 20.835 | 27.177 | 30.869 | 27.204 | 21.644 | 32.210 | 32.404 | 30.639 |
|  60% |  7.600 |  7.351 | 15.196 | 16.911 | 13.611 |  9.223 | 20.256 | 20.430 | 19.339 |
|  70% |  2.257 |  2.039 |  6.787 |  7.854 |  5.660 |  2.801 | 11.065 | 10.039 | 11.303 |
|  80% |  0.573 |  0.398 |  2.467 |  3.043 |  1.549 |  0.843 |  5.222 |  4.618 |  4.970 |
|  90% |  0.122 |  0.056 |  0.704 |  1.031 |  0.575 |  0.247 |  2.032 |  2.109 |  1.943 |
| 100% |  0.002 |  0.006 |  0.152 |  0.208 |  0.088 |  0.005 |  0.622 |  0.623 |  0.588 |
| 110% |  0.000 |  0.000 |  0.022 |  0.074 |  0.019 |  0.000 |  0.219 |  0.203 |  0.176 |
| 120% |  0.000 |  0.000 |  0.003 |  0.012 |  0.002 |  0.000 |  0.076 |  0.071 |  0.036 |
| 130% |  0.000 |  0.000 |  0.000 |  0.002 |  0.000 |  0.000 |  0.023 |  0.022 |  0.009 |
| ---- | ------ |  --- 4 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  50% | 46.101 | 48.063 | 53.848 | 52.875 | 51.408 | 46.459 | 51.488 | 53.661 | 55.098 |
|  60% | 29.993 | 29.341 | 35.771 | 38.316 | 35.793 | 29.800 | 38.827 | 40.483 | 39.444 |
|  70% | 16.269 | 15.744 | 20.123 | 24.773 | 21.738 | 14.960 | 26.918 | 25.458 | 25.876 |
|  80% |  7.343 |  5.809 |  9.455 | 14.266 |  9.213 |  7.089 | 17.064 | 14.897 | 14.156 |
|  90% |  2.505 |  1.944 |  3.698 |  6.638 |  4.040 |  3.146 |  8.845 |  8.408 |  7.297 |
| 100% |  0.629 |  0.550 |  1.679 |  2.031 |  1.473 |  0.862 |  3.761 |  3.634 |  3.773 |
| 110% |  0.100 |  0.106 |  0.560 |  0.719 |  0.428 |  0.214 |  1.728 |  1.601 |  1.741 |
| 120% |  0.024 |  0.007 |  0.191 |  0.272 |  0.173 |  0.068 |  0.830 |  0.862 |  0.810 |
| 130% |  0.001 |  0.001 |  0.041 |  0.056 |  0.034 |  0.007 |  0.378 |  0.400 |  0.344 |
| 140% |  0.000 |  0.000 |  0.004 |  0.006 |  0.003 |  0.000 |  0.127 |  0.128 |  0.112 |
| 150% |  0.000 |  0.000 |  0.000 |  0.001 |  0.000 |  0.000 |  0.030 |  0.021 |  0.013 |
| 160% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.003 |  0.003 |  0.002 |
| ---- | ------ |  --- 5 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  70% | 35.977 | 36.111 | 41.985 | 43.683 | 41.448 | 33.547 | 43.246 | 43.420 | 45.369 |
|  80% | 21.514 | 20.865 | 27.602 | 31.282 | 26.381 | 20.972 | 32.239 | 31.350 | 32.486 |
|  90% | 11.041 | 10.355 | 15.528 | 20.259 | 16.278 | 11.805 | 21.718 | 21.915 | 20.642 |
| 100% |  4.732 |  4.254 |  7.547 | 11.143 |  8.637 |  4.665 | 13.143 | 12.780 | 12.541 |
| 110% |  1.444 |  1.318 |  3.458 |  5.760 |  3.860 |  1.705 |  7.889 |  7.226 |  6.808 |
| 120% |  0.432 |  0.323 |  1.337 |  2.676 |  1.635 |  0.628 |  4.439 |  4.190 |  3.346 |
| 130% |  0.080 |  0.058 |  0.485 |  0.940 |  0.639 |  0.154 |  2.293 |  2.083 |  1.794 |
| 140% |  0.013 |  0.011 |  0.163 |  0.334 |  0.173 |  0.033 |  1.098 |  0.889 |  0.925 |
| 150% |  0.001 |  0.001 |  0.050 |  0.082 |  0.044 |  0.007 |  0.448 |  0.409 |  0.420 |
| 160% |  0.000 |  0.000 |  0.013 |  0.020 |  0.011 |  0.002 |  0.184 |  0.186 |  0.174 |
| 170% |  0.000 |  0.000 |  0.001 |  0.003 |  0.001 |  0.000 |  0.063 |  0.064 |  0.052 |
| 180% |  0.000 |  0.000 |  0.000 |  0.001 |  0.000 |  0.000 |  0.024 |  0.025 |  0.015 |
| 190% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.008 |  0.007 |  0.004 |
| 200% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.002 |  0.002 |  0.001 |
| ---- | ------ |  --- 6 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  80% | 40.461 | 40.647 | 47.076 | 48.097 | 45.131 | 38.743 | 46.983 | 47.697 | 50.313 |
|  90% | 25.807 | 25.747 | 32.971 | 36.104 | 32.510 | 25.812 | 35.946 | 37.248 | 37.413 |
| 100% | 13.941 | 13.685 | 20.968 | 24.599 | 21.034 | 13.747 | 25.613 | 25.758 | 26.552 |
| 110% |  6.410 |  6.079 | 12.042 | 15.716 | 11.953 |  6.662 | 17.727 | 17.135 | 17.270 |
| 120% |  2.491 |  2.278 |  6.197 |  9.342 |  6.245 |  3.192 | 11.550 | 11.481 | 10.490 |
| 130% |  0.786 |  0.576 |  2.721 |  4.881 |  3.065 |  0.959 |  7.133 |  6.803 |  5.942 |
| 140% |  0.148 |  0.120 |  1.121 |  2.209 |  1.311 |  0.253 |  4.166 |  3.639 |  3.378 |
| 150% |  0.023 |  0.016 |  0.416 |  0.981 |  0.411 |  0.067 |  2.282 |  2.020 |  1.680 |
| 160% |  0.001 |  0.001 |  0.113 |  0.385 |  0.139 |  0.014 |  1.162 |  1.000 |  0.816 |
| 170% |  0.000 |  0.000 |  0.031 |  0.104 |  0.035 |  0.001 |  0.497 |  0.415 |  0.377 |
| 180% |  0.000 |  0.000 |  0.006 |  0.027 |  0.005 |  0.000 |  0.227 |  0.177 |  0.149 |
| 190% |  0.000 |  0.000 |  0.001 |  0.006 |  0.002 |  0.000 |  0.095 |  0.084 |  0.078 |
| 200% |  0.000 |  0.000 |  0.000 |  0.001 |  0.000 |  0.000 |  0.039 |  0.034 |  0.030 |
| ---- | ------ |  --- 7 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  90% | 43.690 | 45.119 | 51.532 | 51.648 | 50.017 | 43.265 | 49.747 | 52.171 | 53.999 |
| 100% | 30.208 | 30.859 | 37.827 | 39.954 | 37.183 | 29.006 | 39.154 | 40.469 | 42.328 |
| 110% | 18.998 | 18.736 | 25.529 | 29.152 | 25.283 | 18.275 | 29.816 | 30.055 | 30.993 |
| 120% | 10.886 | 10.197 | 15.879 | 20.203 | 15.635 | 10.932 | 21.752 | 22.116 | 21.480 |
| 130% |  5.243 |  4.758 |  8.926 | 12.754 |  8.948 |  5.267 | 15.153 | 14.860 | 14.171 |
| 140% |  2.103 |  1.868 |  4.458 |  7.229 |  4.739 |  2.301 |  9.946 |  9.269 |  9.033 |
| 150% |  0.689 |  0.703 |  2.115 |  3.889 |  2.124 |  1.030 |  6.316 |  5.840 |  5.478 |
| 160% |  0.196 |  0.202 |  0.909 |  1.959 |  0.918 |  0.362 |  3.784 |  3.466 |  2.881 |
| 170% |  0.052 |  0.039 |  0.310 |  0.889 |  0.322 |  0.105 |  2.073 |  1.787 |  1.471 |
| 180% |  0.011 |  0.005 |  0.093 |  0.398 |  0.088 |  0.030 |  1.148 |  0.893 |  0.705 |
| 190% |  0.001 |  0.000 |  0.020 |  0.138 |  0.023 |  0.004 |  0.558 |  0.433 |  0.328 |
| 200% |  0.000 |  0.000 |  0.004 |  0.035 |  0.003 |  0.000 |  0.251 |  0.183 |  0.156 |

No surprises here, as the haste sets continue to dominate.  The other control sets still lag the haste sets, and the avoidance sets continue to trail even further in the distance.  There’s no question that, going into 5.3, you’re going to want to focus your item upgrades on your haste/mastery/hit/expertise gear rather than any gear with dodge or parry on it.

Stamina Panel

Next, I have a few sets here to compare Stamina trades.  We’ve already seen that Stamina is better than haste in gem slots by a slim margin, but this panel includes trinket trades (C/St) and a high-stamina gear set that splits the remaining itemization between mastery and haste.  Here are the stats of the gear sets:

|    Set: |  C/Ha |  C/St |  C/Sg | C/Shm |  C/Ma |
|     Str | 15000 | 15000 | 15000 | 15000 | 15000 |
|     Sta | 28000 | 34000 | 31000 | 31000 | 28000 |
|   Parry |  1500 |  1500 |  1500 |  1500 |  1500 |
|   Dodge |  1500 |  1500 |  1500 |  1500 |  1500 |
| Mastery |  1500 |  1500 |  1500 |  4750 | 13500 |
|     Hit |  2550 |  2550 |  2550 |  2550 |  2550 |
|     Exp |  5100 |  5100 |  5100 |  5100 |  5100 |
|   Haste | 12000 |  8000 |  8000 |  4750 |     0 |

And here’s the data.  Rather than give individual commentary for each section, I’ll just provide a wall-o-data and talk about all of the sets at the end.

150k:

Finisher = SH1, Boss Attack = 150k, SoI model=nooverheal data set smooth-10000-78

| Set: |   C/Ha |   C/St |   C/Sg |  C/Shm |   C/Ma |
| mean |  0.227 |  0.251 |  0.251 |  0.262 |  0.249 |
|  std |  0.103 |  0.106 |  0.106 |  0.109 |  0.111 |
|   S% |  0.523 |  0.482 |  0.482 |  0.454 |  0.410 |
|   HP |   755k |   876k |   816k |   816k |   755k |
|  nHP |  5.034 |  5.843 |  5.439 |  5.439 |  5.034 |
| ---- |  --- 2 | Attack | Moving | Avg.-- | ------ |
|  10% | 43.022 | 40.482 | 48.479 | 48.121 | 46.739 |
|  20% |  6.469 |  3.214 |  5.837 |  8.332 | 11.753 |
|  30% |  0.164 |  0.024 |  0.039 |  0.139 |  0.682 |
| ---- |  --- 3 | Attack | Moving | Avg.-- | ------ |
|  20% | 18.949 | 14.004 | 20.200 | 25.006 | 26.345 |
|  30% |  1.089 |  0.530 |  0.767 |  2.048 |  4.732 |
|  40% |  0.005 |  0.000 |  0.006 |  0.055 |  0.257 |
|  50% |  0.000 |  0.000 |  0.000 |  0.000 |  0.002 |
| ---- |  --- 4 | Attack | Moving | Avg.-- | ------ |
|  20% | 39.772 | 36.744 | 42.836 | 48.174 | 47.968 |
|  30% | 10.888 |  6.091 |  9.454 | 11.538 | 13.719 |
|  40% |  0.666 |  0.241 |  0.689 |  0.884 |  2.252 |
|  50% |  0.012 |  0.002 |  0.012 |  0.024 |  0.153 |
| ---- |  --- 5 | Attack | Moving | Avg.-- | ------ |
|  30% | 24.760 | 17.744 | 23.760 | 28.425 | 30.966 |
|  40% |  3.940 |  2.123 |  4.331 |  5.915 |  8.371 |
|  50% |  0.382 |  0.068 |  0.288 |  0.495 |  1.221 |
|  60% |  0.008 |  0.000 |  0.004 |  0.021 |  0.136 |
|  70% |  0.001 |  0.000 |  0.000 |  0.000 |  0.002 |
| ---- |  --- 6 | Attack | Moving | Avg.-- | ------ |
|  30% | 41.148 | 33.863 | 41.358 | 46.465 | 48.106 |
|  40% | 11.141 |  7.171 | 12.030 | 15.812 | 19.552 |
|  50% |  1.678 |  0.430 |  1.371 |  2.591 |  4.707 |
|  60% |  0.045 |  0.004 |  0.029 |  0.201 |  0.685 |
|  70% |  0.002 |  0.000 |  0.000 |  0.006 |  0.068 |
|  80% |  0.000 |  0.000 |  0.000 |  0.000 |  0.002 |
| ---- |  --- 7 | Attack | Moving | Avg.-- | ------ |
|  40% | 23.781 | 18.316 | 25.654 | 30.083 | 33.487 |
|  50% |  6.487 |  3.211 |  6.569 |  8.118 | 11.848 |
|  60% |  0.799 |  0.220 |  0.715 |  1.045 |  2.554 |
|  70% |  0.055 |  0.003 |  0.030 |  0.047 |  0.309 |
|  80% |  0.002 |  0.000 |  0.000 |  0.000 |  0.023 |

250k:

Finisher = SH1, Boss Attack = 250k, SoI model=nooverheal data set smooth-10000-79

| Set: |   C/Ha |   C/St |   C/Sg |  C/Shm |   C/Ma |
| mean |  0.250 |  0.274 |  0.274 |  0.286 |  0.268 |
|  std |  0.102 |  0.105 |  0.105 |  0.108 |  0.106 |
|   S% |  0.522 |  0.483 |  0.482 |  0.454 |  0.410 |
|   HP |   755k |   876k |   816k |   816k |   755k |
|  nHP |  3.021 |  3.506 |  3.263 |  3.263 |  3.021 |
| ---- |  --- 2 | Attack | Moving | Avg.-- | ------ |
|  20% | 42.151 | 32.857 | 36.254 | 40.191 | 45.407 |
|  30% | 14.668 |  8.370 | 14.755 | 15.533 | 17.767 |
|  40% |  1.567 |  0.737 |  1.982 |  3.311 |  4.335 |
|  50% |  0.121 |  0.037 |  0.062 |  0.218 |  0.506 |
|  60% |  0.001 |  0.000 |  0.003 |  0.016 |  0.016 |
| ---- |  --- 3 | Attack | Moving | Avg.-- | ------ |
|  30% | 39.373 | 26.912 | 38.369 | 39.100 | 37.228 |
|  40% |  8.513 |  5.704 | 10.856 | 13.586 | 15.144 |
|  50% |  1.359 |  0.587 |  1.341 |  2.633 |  4.648 |
|  60% |  0.142 |  0.047 |  0.081 |  0.403 |  1.028 |
|  70% |  0.001 |  0.000 |  0.004 |  0.041 |  0.117 |
|  80% |  0.000 |  0.000 |  0.000 |  0.003 |  0.013 |
| ---- |  --- 4 | Attack | Moving | Avg.-- | ------ |
|  40% | 32.341 | 26.812 | 35.236 | 37.719 | 36.062 |
|  50% | 14.193 |  7.784 | 12.065 | 15.074 | 14.948 |
|  60% |  4.290 |  1.568 |  3.093 |  4.422 |  5.201 |
|  70% |  0.665 |  0.146 |  0.518 |  0.760 |  1.473 |
|  80% |  0.060 |  0.007 |  0.049 |  0.154 |  0.377 |
|  90% |  0.002 |  0.000 |  0.001 |  0.004 |  0.033 |
| 100% |  0.000 |  0.000 |  0.000 |  0.000 |  0.002 |
| ---- |  --- 5 | Attack | Moving | Avg.-- | ------ |
|  40% | 54.097 | 48.919 | 57.263 | 59.186 | 57.725 |
|  50% | 32.478 | 22.916 | 30.390 | 35.916 | 35.990 |
|  60% | 15.061 |  8.617 | 12.834 | 17.288 | 18.606 |
|  70% |  4.652 |  1.601 |  4.092 |  5.910 |  6.957 |
|  80% |  0.789 |  0.254 |  0.800 |  1.501 |  2.061 |
|  90% |  0.101 |  0.014 |  0.068 |  0.290 |  0.477 |
| 100% |  0.007 |  0.001 |  0.004 |  0.025 |  0.095 |
| 110% |  0.000 |  0.000 |  0.000 |  0.003 |  0.014 |
| 120% |  0.000 |  0.000 |  0.000 |  0.000 |  0.001 |
| ---- |  --- 6 | Attack | Moving | Avg.-- | ------ |
|  50% | 52.320 | 42.349 | 51.355 | 56.269 | 55.371 |
|  60% | 31.193 | 21.903 | 28.692 | 34.990 | 36.098 |
|  70% | 13.524 |  6.437 | 12.865 | 16.944 | 18.868 |
|  80% |  3.851 |  1.594 |  3.908 |  6.248 |  7.912 |
|  90% |  0.779 |  0.136 |  0.599 |  1.792 |  2.550 |
| 100% |  0.089 |  0.014 |  0.067 |  0.349 |  0.654 |
| 110% |  0.002 |  0.001 |  0.003 |  0.050 |  0.139 |
| 120% |  0.000 |  0.000 |  0.000 |  0.005 |  0.020 |
| 130% |  0.000 |  0.000 |  0.000 |  0.000 |  0.002 |
| ---- |  --- 7 | Attack | Moving | Avg.-- | ------ |
|  60% | 48.396 | 39.916 | 47.325 | 53.984 | 54.160 |
|  70% | 29.080 | 18.943 | 28.735 | 33.378 | 34.456 |
|  80% | 13.894 |  8.067 | 14.051 | 16.554 | 18.524 |
|  90% |  5.346 |  1.929 |  4.590 |  6.626 |  8.174 |
| 100% |  1.580 |  0.453 |  1.226 |  1.952 |  3.000 |
| 110% |  0.319 |  0.045 |  0.269 |  0.436 |  0.889 |
| 120% |  0.035 |  0.005 |  0.036 |  0.056 |  0.201 |
| 130% |  0.001 |  0.000 |  0.001 |  0.005 |  0.034 |
| 140% |  0.000 |  0.000 |  0.000 |  0.000 |  0.002 |

350k:

Finisher = SH1, Boss Attack = 350k, SoI model=nooverheal data set smooth-10000-80

| Set: |   C/Ha |   C/St |   C/Sg |  C/Shm |   C/Ma |
| mean |  0.261 |  0.286 |  0.285 |  0.296 |  0.279 |
|  std |  0.103 |  0.106 |  0.106 |  0.109 |  0.107 |
|   S% |  0.523 |  0.483 |  0.482 |  0.455 |  0.411 |
|   HP |   755k |   876k |   816k |   816k |   755k |
|  nHP |  2.158 |  2.504 |  2.331 |  2.331 |  2.158 |
| ---- |  --- 2 | Attack | Moving | Avg.-- | ------ |
|  30% | 32.655 | 31.390 | 36.075 | 39.645 | 40.546 |
|  40% | 15.258 | 13.987 | 18.369 | 21.260 | 20.745 |
|  50% |  5.626 |  2.668 |  5.192 |  7.446 | 10.378 |
|  60% |  1.289 |  0.428 |  1.252 |  1.662 |  4.211 |
|  70% |  0.186 |  0.036 |  0.060 |  0.216 |  1.123 |
|  80% |  0.009 |  0.000 |  0.005 |  0.020 |  0.180 |
|  90% |  0.001 |  0.000 |  0.000 |  0.000 |  0.010 |
| ---- |  --- 3 | Attack | Moving | Avg.-- | ------ |
|  40% | 41.125 | 38.171 | 45.569 | 47.260 | 44.575 |
|  50% | 20.420 | 13.837 | 20.588 | 25.682 | 27.031 |
|  60% |  7.512 |  4.311 |  7.327 |  9.046 | 14.943 |
|  70% |  2.261 |  1.006 |  2.026 |  3.562 |  6.643 |
|  80% |  0.560 |  0.080 |  0.396 |  0.873 |  2.381 |
|  90% |  0.110 |  0.005 |  0.061 |  0.204 |  0.669 |
| 100% |  0.003 |  0.000 |  0.004 |  0.040 |  0.134 |
| 110% |  0.000 |  0.000 |  0.000 |  0.003 |  0.016 |
| 120% |  0.000 |  0.000 |  0.000 |  0.000 |  0.001 |
| ---- |  --- 4 | Attack | Moving | Avg.-- | ------ |
|  50% | 45.896 | 41.533 | 47.686 | 52.960 | 53.508 |
|  60% | 29.735 | 22.478 | 29.189 | 31.558 | 35.477 |
|  70% | 15.994 | 10.134 | 15.554 | 17.602 | 19.942 |
|  80% |  7.202 |  3.215 |  5.747 |  6.774 |  9.302 |
|  90% |  2.452 |  0.780 |  1.908 |  2.307 |  3.580 |
| 100% |  0.601 |  0.158 |  0.517 |  0.745 |  1.608 |
| 110% |  0.095 |  0.027 |  0.097 |  0.229 |  0.525 |
| 120% |  0.026 |  0.000 |  0.006 |  0.027 |  0.186 |
| 130% |  0.001 |  0.000 |  0.001 |  0.002 |  0.034 |
| 140% |  0.000 |  0.000 |  0.000 |  0.000 |  0.006 |
| ---- |  --- 5 | Attack | Moving | Avg.-- | ------ |
|  60% | 51.494 | 44.824 | 52.189 | 54.630 | 57.324 |
|  70% | 35.639 | 27.906 | 35.791 | 39.964 | 41.670 |
|  80% | 21.239 | 13.761 | 20.612 | 23.618 | 27.228 |
|  90% | 10.783 |  5.950 | 10.163 | 12.882 | 15.272 |
| 100% |  4.579 |  1.768 |  4.144 |  5.902 |  7.348 |
| 110% |  1.397 |  0.452 |  1.291 |  2.219 |  3.306 |
| 120% |  0.427 |  0.065 |  0.309 |  0.848 |  1.295 |
| 130% |  0.081 |  0.008 |  0.065 |  0.189 |  0.458 |
| 140% |  0.011 |  0.001 |  0.005 |  0.046 |  0.162 |
| 150% |  0.001 |  0.000 |  0.001 |  0.006 |  0.054 |
| 160% |  0.000 |  0.000 |  0.000 |  0.001 |  0.015 |
| 170% |  0.000 |  0.000 |  0.000 |  0.000 |  0.001 |
| ---- |  --- 6 | Attack | Moving | Avg.-- | ------ |
|  70% | 56.207 | 48.772 | 56.781 | 60.612 | 60.808 |
|  80% | 40.135 | 31.100 | 40.264 | 43.807 | 46.758 |
|  90% | 25.368 | 17.472 | 25.388 | 29.499 | 32.593 |
| 100% | 13.595 |  7.749 | 13.518 | 17.807 | 20.617 |
| 110% |  6.246 |  2.696 |  6.007 |  8.688 | 11.776 |
| 120% |  2.429 |  0.627 |  2.185 |  4.207 |  6.054 |
| 130% |  0.768 |  0.120 |  0.565 |  1.397 |  2.603 |
| 140% |  0.132 |  0.014 |  0.120 |  0.489 |  1.041 |
| 150% |  0.025 |  0.001 |  0.014 |  0.136 |  0.405 |
| 160% |  0.002 |  0.000 |  0.002 |  0.028 |  0.114 |
| 170% |  0.001 |  0.000 |  0.000 |  0.005 |  0.033 |
| 180% |  0.000 |  0.000 |  0.000 |  0.000 |  0.007 |
| 190% |  0.000 |  0.000 |  0.000 |  0.000 |  0.001 |
| ---- |  --- 7 | Attack | Moving | Avg.-- | ------ |
|  90% | 43.224 | 35.259 | 44.614 | 49.400 | 51.175 |
| 100% | 29.814 | 21.840 | 30.534 | 35.183 | 37.393 |
| 110% | 18.636 | 11.397 | 18.494 | 21.431 | 25.169 |
| 120% | 10.629 |  5.206 | 10.057 | 12.467 | 15.597 |
| 130% |  5.082 |  2.008 |  4.658 |  5.921 |  8.690 |
| 140% |  2.015 |  0.696 |  1.827 |  2.659 |  4.286 |
| 150% |  0.672 |  0.171 |  0.672 |  1.000 |  2.040 |
| 160% |  0.191 |  0.020 |  0.181 |  0.300 |  0.854 |
| 170% |  0.050 |  0.003 |  0.045 |  0.067 |  0.301 |
| 180% |  0.009 |  0.001 |  0.004 |  0.010 |  0.094 |
| 190% |  0.001 |  0.000 |  0.000 |  0.001 |  0.019 |
| 200% |  0.000 |  0.000 |  0.000 |  0.000 |  0.003 |

There’s not a lot to say about this data, we’re really seeing more of the same.  Stamina is better than haste on gems, and a lot better than haste on trinkets.  Dual stamina trinkets should probably be a given for most tanks unless they’re already exceeding their stamina goals with full haste gemming.  The haste/mastery combination set still looks lackluster, and of course Control/Mastery trails everything else since it’s got much lower haste.

Hit/Exp Panel

A question that came up in one of my discussions on mmo-champion was whether it was still worthwhile to cap hit and expertise.  I had been testing a “pure haste” set that funneled most of that hit and expertise into haste, and it wasn’t really performing well.  But I hadn’t done a breakdown at the various expertise caps that are relevant.  This panel addresses those concerns.

We start with Control/Haste, and then drop back to a set that caps hit but only “soft-caps” expertise (thus 7.5% hit, 7.5% expertise), which we’ll call “Haste/hitexp” or “Ha/he” for short.  The itemization we freed up gets put into haste, obviously.  The next set drops to 500 expertise rating to simulate avoiding expertise entirely, but with some residual left on gear.  That set has 7.5% hit and 1.47% expertise, so we’ll ca” it “Haste/hit” or “Ha/h” for short.  Finally, we have the “pure haste” set that drops all but 500 hit rating and 500 expertise rating but ramps our haste up to 18650 (about 43.8% melee haste).

The stats for these sets are given below:

|    Set: |  C/Ha | Ha/he |  Ha/h |    Ha |
|     Str | 15000 | 15000 | 15000 | 15000 |
|     Sta | 28000 | 28000 | 28000 | 28000 |
|   Parry |  1500 |  1500 |  1500 |  1500 |
|   Dodge |  1500 |  1500 |  1500 |  1500 |
| Mastery |  1500 |  1500 |  1500 |  1500 |
|     Hit |  2550 |  2550 |  2550 |   500 |
|     Exp |  5100 |  2550 |   500 |   500 |
|   Haste | 12000 | 14550 | 16600 | 18650 |

Now let’s look at the data.  Starting with our 150k boss swing set:

Finisher = SH1, Boss Attack = 150k, SoI model=nooverheal data set smooth-10000-86

| Set: |   C/Ha |  Ha/he |   Ha/h |     Ha |
| mean |  0.227 |  0.230 |  0.230 |  0.235 |
|  std |  0.103 |  0.107 |  0.108 |  0.110 |
|   S% |  0.522 |  0.520 |  0.518 |  0.498 |
|   HP |   755k |   755k |   755k |   755k |
|  nHP |  5.034 |  5.034 |  5.034 |  5.034 |
| ---- |  --- 2 | Attack | Moving | Avg.-- |
|  10% | 43.110 | 43.217 | 43.027 | 43.824 |
|  20% |  6.517 |  7.382 |  7.563 |  8.460 |
|  30% |  0.166 |  0.253 |  0.296 |  0.411 |
| ---- |  --- 3 | Attack | Moving | Avg.-- |
|  20% | 19.120 | 21.076 | 22.165 | 24.070 |
|  30% |  1.119 |  1.712 |  2.044 |  2.959 |
|  40% |  0.001 |  0.009 |  0.021 |  0.050 |
| ---- |  --- 4 | Attack | Moving | Avg.-- |
|  20% | 39.923 | 41.081 | 41.467 | 43.293 |
|  30% | 10.978 | 12.263 | 12.344 | 13.360 |
|  40% |  0.667 |  1.059 |  1.245 |  1.759 |
|  50% |  0.013 |  0.044 |  0.058 |  0.121 |
| ---- |  --- 5 | Attack | Moving | Avg.-- |
|  30% | 24.908 | 26.517 | 26.389 | 27.785 |
|  40% |  3.980 |  5.161 |  5.399 |  6.370 |
|  50% |  0.396 |  0.630 |  0.641 |  0.878 |
|  60% |  0.006 |  0.020 |  0.020 |  0.060 |
|  70% |  0.001 |  0.000 |  0.001 |  0.002 |
| ---- |  --- 6 | Attack | Moving | Avg.-- |
|  30% | 41.286 | 42.546 | 42.076 | 43.360 |
|  40% | 11.279 | 13.377 | 14.526 | 16.362 |
|  50% |  1.693 |  2.544 |  3.060 |  4.119 |
|  60% |  0.048 |  0.128 |  0.228 |  0.479 |
|  70% |  0.001 |  0.003 |  0.008 |  0.036 |
| ---- |  --- 7 | Attack | Moving | Avg.-- |
|  40% | 23.930 | 25.998 | 26.529 | 28.571 |
|  50% |  6.519 |  8.063 |  8.533 | 10.285 |
|  60% |  0.814 |  1.266 |  1.463 |  2.292 |
|  70% |  0.062 |  0.120 |  0.161 |  0.338 |
|  80% |  0.000 |  0.002 |  0.008 |  0.027 |
|  90% |  0.000 |  0.000 |  0.000 |  0.002 |

This data is pretty straightforward.  Control/Haste leads the soft-capped set Ha/he, and dropping more expertise or hit only makes things worse.  There’s two reasons for this.  First is the obvious one, the under-capped sets have lower holy power generation, as evidenced by the SotR uptime percentage (S%).  Trading the expertise doesn’t incur a very large loss, as haste is actually pretty competitive with expertise for raw HPG.  Dropping the hit obviously hurts a lot more.

More importantly though, consider that SoI proc triggers are Crusader Strike, Shield of the Righteous, and auto-attacks.  All three of those get the full benefit from expertise, and an attack that doesn’t hit can’t proc Seal of Insight.  So despite breaking even in terms of overall HPG, dropping 7.5% (or 15%) expertise for 6% (or 12%) more haste is a net loss because you get fewer Seal of Insight procs.   So there doesn’t seem to be any advantage to dropping expertise hard-cap for more haste in terms of survivability.

I will note, however, that if you turn off SoI procs entirely, the C/Ha, Ha/he, and Ha/h sets are all about even.  At normal Vengeance levels, Ha/he should end up doing slightly more DPS than C/Ha because haste is a better DPS stat than expertise above the 7.5% dodge “soft-cap.”  So this is another case where you may consider making a survivability-for-DPS trade if you’re hitting a rough enrage timer.

There’s really nothing different about the 250k or 350k data, so I’ll provide them here without further commentary:

Finisher = SH1, Boss Attack = 250k, SoI model=nooverheal data set smooth-10000-87

| Set: |   C/Ha |  Ha/he |   Ha/h |     Ha |
| mean |  0.251 |  0.253 |  0.252 |  0.259 |
|  std |  0.102 |  0.107 |  0.107 |  0.109 |
|   S% |  0.522 |  0.521 |  0.518 |  0.499 |
|   HP |   755k |   755k |   755k |   755k |
|  nHP |  3.021 |  3.021 |  3.021 |  3.021 |
| ---- |  --- 2 | Attack | Moving | Avg.-- |
|  20% | 42.364 | 42.075 | 41.379 | 42.452 |
|  30% | 14.804 | 15.479 | 15.127 | 16.332 |
|  40% |  1.603 |  2.062 |  2.294 |  2.863 |
|  50% |  0.120 |  0.217 |  0.228 |  0.298 |
|  60% |  0.001 |  0.005 |  0.006 |  0.009 |
| ---- |  --- 3 | Attack | Moving | Avg.-- |
|  30% | 39.804 | 39.985 | 39.238 | 40.705 |
|  40% |  8.624 | 10.322 | 11.422 | 13.700 |
|  50% |  1.391 |  1.987 |  2.303 |  3.334 |
|  60% |  0.150 |  0.261 |  0.367 |  0.643 |
|  70% |  0.002 |  0.009 |  0.018 |  0.044 |
|  80% |  0.000 |  0.001 |  0.002 |  0.002 |
| ---- |  --- 4 | Attack | Moving | Avg.-- |
|  40% | 32.701 | 33.328 | 32.916 | 34.879 |
|  50% | 14.472 | 15.458 | 15.110 | 16.482 |
|  60% |  4.444 |  5.239 |  5.370 |  6.320 |
|  70% |  0.677 |  0.982 |  1.100 |  1.632 |
|  80% |  0.063 |  0.140 |  0.172 |  0.312 |
|  90% |  0.001 |  0.010 |  0.014 |  0.037 |
| 100% |  0.000 |  0.001 |  0.002 |  0.006 |
| ---- |  --- 5 | Attack | Moving | Avg.-- |
|  50% | 32.962 | 33.697 | 32.956 | 34.861 |
|  60% | 15.381 | 16.717 | 16.447 | 18.059 |
|  70% |  4.777 |  5.857 |  5.885 |  7.115 |
|  80% |  0.823 |  1.303 |  1.419 |  1.956 |
|  90% |  0.103 |  0.224 |  0.233 |  0.398 |
| 100% |  0.009 |  0.030 |  0.040 |  0.077 |
| 110% |  0.001 |  0.004 |  0.005 |  0.011 |
| ---- |  --- 6 | Attack | Moving | Avg.-- |
|  60% | 31.711 | 33.063 | 32.622 | 34.657 |
|  70% | 13.959 | 15.843 | 16.659 | 18.964 |
|  80% |  3.929 |  5.224 |  6.191 |  8.061 |
|  90% |  0.805 |  1.338 |  1.773 |  2.723 |
| 100% |  0.098 |  0.248 |  0.404 |  0.758 |
| 110% |  0.005 |  0.030 |  0.066 |  0.157 |
| 120% |  0.001 |  0.003 |  0.009 |  0.026 |
| 130% |  0.000 |  0.001 |  0.001 |  0.003 |
| ---- |  --- 7 | Attack | Moving | Avg.-- |
|  60% | 48.902 | 49.435 | 48.666 | 50.557 |
|  70% | 29.619 | 31.090 | 31.034 | 33.518 |
|  80% | 14.198 | 15.685 | 15.964 | 18.612 |
|  90% |  5.547 |  6.577 |  6.817 |  8.753 |
| 100% |  1.646 |  2.259 |  2.452 |  3.562 |
| 110% |  0.334 |  0.605 |  0.714 |  1.245 |
| 120% |  0.041 |  0.105 |  0.142 |  0.310 |
| 130% |  0.002 |  0.018 |  0.024 |  0.069 |
| 140% |  0.000 |  0.003 |  0.004 |  0.014 |
| 150% |  0.000 |  0.000 |  0.000 |  0.002 |

350k

Finisher = SH1, Boss Attack = 350k, SoI model=nooverheal data set smooth-10000-88

| Set: |   C/Ha |  Ha/he |   Ha/h |     Ha |
| mean |  0.261 |  0.263 |  0.262 |  0.270 |
|  std |  0.103 |  0.108 |  0.108 |  0.111 |
|   S% |  0.523 |  0.520 |  0.519 |  0.498 |
|   HP |   755k |   755k |   755k |   755k |
|  nHP |  2.158 |  2.158 |  2.158 |  2.158 |
| ---- |  --- 2 | Attack | Moving | Avg.-- |
|  30% | 32.782 | 33.380 | 33.626 | 35.883 |
|  40% | 15.245 | 16.273 | 16.244 | 17.843 |
|  50% |  5.653 |  6.601 |  6.744 |  7.835 |
|  60% |  1.320 |  1.803 |  1.973 |  2.520 |
|  70% |  0.194 |  0.327 |  0.395 |  0.542 |
|  80% |  0.009 |  0.033 |  0.045 |  0.068 |
|  90% |  0.001 |  0.002 |  0.003 |  0.007 |
| ---- |  --- 3 | Attack | Moving | Avg.-- |
|  40% | 41.101 | 41.710 | 41.461 | 43.507 |
|  50% | 20.429 | 22.534 | 23.262 | 25.979 |
|  60% |  7.533 |  9.316 | 10.294 | 12.646 |
|  70% |  2.282 |  3.240 |  3.750 |  5.124 |
|  80% |  0.595 |  0.962 |  1.120 |  1.827 |
|  90% |  0.131 |  0.205 |  0.260 |  0.516 |
| 100% |  0.002 |  0.010 |  0.019 |  0.048 |
| 110% |  0.000 |  0.001 |  0.001 |  0.003 |
| ---- |  --- 4 | Attack | Moving | Avg.-- |
|  50% | 45.862 | 46.587 | 46.365 | 48.892 |
|  60% | 29.730 | 30.929 | 30.862 | 33.529 |
|  70% | 16.109 | 17.575 | 17.627 | 19.657 |
|  80% |  7.290 |  8.733 |  8.909 | 10.582 |
|  90% |  2.510 |  3.359 |  3.519 |  4.657 |
| 100% |  0.639 |  0.938 |  0.989 |  1.564 |
| 110% |  0.110 |  0.229 |  0.254 |  0.491 |
| 120% |  0.026 |  0.071 |  0.073 |  0.167 |
| 130% |  0.001 |  0.012 |  0.016 |  0.042 |
| 140% |  0.000 |  0.002 |  0.003 |  0.010 |
| ---- |  --- 5 | Attack | Moving | Avg.-- |
|  70% | 35.663 | 36.814 | 36.555 | 39.284 |
|  80% | 21.308 | 23.175 | 22.976 | 25.547 |
|  90% | 10.906 | 12.709 | 12.668 | 14.766 |
| 100% |  4.701 |  5.908 |  5.860 |  7.296 |
| 110% |  1.474 |  2.162 |  2.191 |  2.922 |
| 120% |  0.445 |  0.738 |  0.733 |  1.132 |
| 130% |  0.093 |  0.215 |  0.225 |  0.401 |
| 140% |  0.016 |  0.062 |  0.060 |  0.130 |
| 150% |  0.002 |  0.014 |  0.016 |  0.041 |
| 160% |  0.000 |  0.002 |  0.004 |  0.011 |
| 170% |  0.000 |  0.001 |  0.000 |  0.001 |
| ---- |  --- 6 | Attack | Moving | Avg.-- |
|  80% | 40.086 | 41.524 | 40.823 | 43.481 |
|  90% | 25.437 | 27.621 | 27.811 | 30.764 |
| 100% | 13.756 | 15.994 | 16.776 | 19.629 |
| 110% |  6.423 |  8.139 |  9.110 | 11.391 |
| 120% |  2.511 |  3.591 |  4.242 |  5.898 |
| 130% |  0.818 |  1.397 |  1.773 |  2.776 |
| 140% |  0.161 |  0.407 |  0.568 |  1.095 |
| 150% |  0.030 |  0.118 |  0.190 |  0.427 |
| 160% |  0.005 |  0.028 |  0.052 |  0.145 |
| 170% |  0.001 |  0.006 |  0.012 |  0.042 |
| 180% |  0.000 |  0.002 |  0.002 |  0.011 |
| 190% |  0.000 |  0.000 |  0.001 |  0.004 |
| ---- |  --- 7 | Attack | Moving | Avg.-- |
|  90% | 43.220 | 44.588 | 44.158 | 46.917 |
| 100% | 29.850 | 31.686 | 31.638 | 34.768 |
| 110% | 18.732 | 20.614 | 20.875 | 23.980 |
| 120% | 10.758 | 12.378 | 12.615 | 15.407 |
| 130% |  5.213 |  6.419 |  6.732 |  8.979 |
| 140% |  2.094 |  2.902 |  3.120 |  4.675 |
| 150% |  0.728 |  1.182 |  1.305 |  2.248 |
| 160% |  0.208 |  0.443 |  0.511 |  1.023 |
| 170% |  0.057 |  0.170 |  0.190 |  0.423 |
| 180% |  0.015 |  0.060 |  0.072 |  0.172 |
| 190% |  0.002 |  0.014 |  0.020 |  0.058 |
| 200% |  0.000 |  0.004 |  0.005 |  0.017 |

Conclusions

There’s a lot of data in this post, but the conclusions are pretty straightforward.  We’ve been ignoring Seal of Insight for a long time based on a hand-wavy overheal argument, and this data clearly shows that we weren’t getting the whole picture.  We knew haste was good, of course – the old model got that much correct, at least – but led us to incorrect conclusions about how haste compared with its nearest competitor, mastery.

The old model would have told us that the recent nerf to SotR’s base mitigation dropped haste behind mastery in terms of survivability value, primarily due to the strong passive mitigation value of blocking.  But Seal of Insight gives us a competing effect that, quite frankly, blows blocking out of the water.  We get more than one Seal of Insight proc per boss attack – in fact, with the C/Ha set we get approximately 1.3 procs per boss attack – and each one of those procs gives us a guaranteed 20% “mini-block” on damage already taken.  Combine that with a more favorable rating-to-percent conversion for haste than mastery, and haste looks like the better passive mitigation stat.

In short, Seal of Insight tips the scales solidly in favor of the Control/Haste gearing paradigm.  The only argument you could make for Control/Mastery is that it doesn’t rely on the player operating a strong rotation.  But it does still require that the player times Shield of the Righteous well, which may not be a compatible assumption.  A player that can’t maintain a rotation is probably less likely to be precise with their Active Mitigation too, which pulls the entire claim that Control/Mastery excels at passive mitigation into question.  It’s still got the “no skill required” benefit of blocking, but Seal of Insight procs from auto-attacks don’t require any player interaction either.

In fact, I’d have to argue at this point that there’s very little reason to pursue a Control/Mastery gearing paradigm at all.  Stamina is still the king survivability stat, and it’s truly passive.  A strong player will still want to gear for as much haste as they can while maintaining a comfortable level of stamina.  A weak player would be better-off stam-stacking and taking whatever stats they get on gear.  A truly abysmal player may just use traditional tanking gear, which will give them high stamina and lots of passive survivability via avoidance and blocking.  I’m not sure that any level of player would find a mastery build optimal outside of special cases (the standard “Heroic Sha” disclaimer).

Some players have suggested that maybe it would be beneficial to drop expertise for haste, but the data solidly refutes that hypothesis. The data confirms that it’s still a priority to maintain hit (7.5%) and expertise (15%) caps before piling on the haste.  Nowadays, that should be easy to do with reforges alone, possibly with a few expertise/stamina or expertise/haste gems to dance around the cap more effectively.

So, the TLDR summary:

  • Stamina is still your best survivability stat, haste is a reasonably close second, mastery a distant third, dodge and parry tied for an even more distant fourth.
  • Capping hit (7.5%) and expertise (15%) are still your most important secondary stat goals (i.e. Control comes before Haste).  It’s not clear from the data whether stamina is better or worse than hit and expertise – my guess is that stamina is better, but it should rarely come up in practice since you can’t reforge into stamina anyway.
  • Control/Haste should be the default gearing strategy for pretty much everyone nowadays, augmented by as much stamina as you need to feel comfortable in the encounter.  Rule of thumb: if you keep going splat, pick up some more stamina.
Posted in Tanking, Theck's Pounding Headaches, Theorycrafting | Tagged , , , , , , , , , , , , , , | 17 Comments

Modeling Seal of Insight

Posted on May 13, 2013 by Theck

Seal of Insight is the last major paladin mechanic that has yet to be added to the simulation.  The last piece of the puzzle, as it were.  There are a number of reasons I’ve put off adding SoI, some of which I discussed in the last two posts.

SoI is a more complicated beast than effects like Sacred Shield, for starters.  It has a lot of “moving parts” as far as the simulation is concerned.  While we don’t have to cast it, it requires adding melee swings to the simulation, which means adding another event type.  It also adds another buff to track in the form of our fake absorb bubble, and we’ll need a model to calculate the effectiveness of that bubble.  And since we’re adding melee swings, we also need to add parry-hasting if the model is to be completely accurate.  That doesn’t mean any of the logic is particularly hard, just that it has tendrils in several sections of the simulation, which makes it annoying to implement and bug-check.

It also causes a moderate performance hit.  First, from the inclusion of another event type (melee swings), and then from the additional calculation being performed each time that event occurs.  There’s also a small performance decrease due to the extra calculations on the SoI absorb bubble.  Together, that all added up to be a bit of an issue.  Performance had been a problem with the simulation in general even before this point, and now seemed like an appropriate time to fix it.

I enlisted the help of a friend of mine who happens to be a real computer scientist type, and he promptly told me to stop thinking like a physicist and start thinking like a computer scientist.  Together we (and by we, I mean he) hashed out a few improvements that would drastically improve performance.  To give you an idea of how significant that improvement was, it now runs about five to six times faster than it did before I added Seal of Insight.  Runtime dropped from about 400-500 seconds per simulation to around 60 seconds.

So now that it’s implemented, I can spit out lots and lots of data relatively quickly.  But first, we need to discuss exactly how we’re modeling Seal of Insight, and provide some justification for that model.  That will be the topic of today’s post.

Effectiveness – Logs

The first part of modeling is figuring out exactly what we’re aiming for.  One of the big arguments about Seal of Insight is how much of it ends up simply being overhealing.  It’s going to be important to get that right, so rather than guess, we go to the logs and see what they say.  I scrutinized about 20 different logs from the last month for a variety of guilds ranging from normal-mode to heroic-mode content in both 10- and 25-man categories.  While this only gives me a few data points per individual boss, it’s enough to get a rough idea of how much overhealing we expect.  Here are the numbers:

Boss 10N 10H 25N 25H
Jin’Rokh 66% 68% 66% 77%
Horridon 53% 62% 74% 74%
Council of Elders 51% 31% 64% 60%
Tortos 54% N/A 68% N/A
Megaera 41% 44% 46% 60%
Ji-Kun 62% 52% 65% 77%
Durumu 57% 60% 56% 68%
Primordius 38% 32% 60% 46%
Dark Animus 52% 58% 46% 49%
Iron Qon 47% 61% 46% 60%
Twin Consorts 59% 72% 72%
Lei Shen 51% 60%

That’s a lot of overhealing.  This data doesn’t suggest that there’s a huge difference between 10- and 25-mans.  And note that there’s a mix of data in here.  Some logs are from solo-tanking a boss, while some are from multiple-tanking;  some tanks are on boss duty while others are on adds.  So there are larger variations to be had on a situational basis.

The lack of distinction between 10- and 25-man seemed a little strange at first.  My intuition is that in 25-mans, you’d expect a dedicated tank healer, leading to higher overheal values for SoI.  In 10-mans, I’d expect the “tank healer” to split his attention a lot more to help with raid healing, and thus allow SoI to pull more weight.  But while there may be a little of that happening, it’s not a large effect.  We’re not seeing many cases where we get double the overhealing in 25-mans (Primordius stands out, but I suspect that’s due to 1- vs. 2-tanking distinctions).

To take a look at why that is, I looked a little more carefully at my own healing taken breakdowns.  And I was actually a bit surprised by what I found.

First, Sacred Shield and Seal of Insight regularly produce 35%-50% of my total healing taken.  That Sacred Shield is consistently 20%-30% isn’t all that surprising – absorption effects are your first line of defense against damage, so they’ll naturally be pretty efficient and will tend to get utilized.  But Seal of Insight fairly regularly shows up in second place, accounting for 10%-20%.  That’s a bit higher than I expected, to be honest – I thought that when we’re pushing 60%-70% overheal, it would account for much less.

But what’s more surprising is the sheer amount of healing that’s coming from passive sources.  When I totaled up the amount of healing coming from “passive” sources, including HoTs and incidental absorbs, it was 75%-80% of all healing I received.  Only 20%-25% is due to “direct” healing, like Holy Light, Divine Light, Nourish, Healing Touch, etc.

Now, that’s considering all healing done, including overhealing.  You might assume that the passive sources show a much higher amount of overhealing than the direct sources.  And to a limited degree, that intuition seems correct.  But even the direct heals are seeing a large amount of overheal.  Holy Light and Nourish regularly clocked 60%-80% overheal in my logs.  Big heals like Healing Touch and Divine Light tended to be lower, ranging from 30% to 50% from boss to boss.

From all of that, we can draw a few conclusions.  First, we’re a long way from the “spam Holy Light on the tank” healing model of Wrath.  The triage model seems to be working correctly, with healers dropping efficient, low-cost heals (HoTs, Holy Light) on the tank when the situation is relatively safe, and only resorting to big or fast direct heals when they’re needed.  This also explains the similarities between the 10- and 25-man data; in both cases, a dedicated “tank-spamming” healer really isn’t necessary most of the time.

Second, I think it reinforces this idea that spike damage is the only dangerous damage.  We’re blanketed with an incredible amount of healing from passive sources, so low-throughput sections of an encounter will rarely cause a death.  It’s really those situations where we take a sudden spike of damage that our healers even reach into their toolkit for the big, fast heals.  And the best thing we can do to survive is to reduce the number of times they need to do that and buy them as much time as possible in the cases where they do.

But most importantly, it’s somewhat amazing how much self-healing we really do.  In many cases, we’re not even receiving direct heals, and just being kept afloat by HoTs and our own healing contributions.  It also means that it’s probably not fair to toss aside SoI as irrelevant because of the sheer amount of overhealing it does.  A lot of that overhealing happens during the stable, low-throughput situations that we don’t care that much about.  But during a spike, the amount of overheal will be very small.  And while it’s not guaranteed healing since SoI is a proc mechanism, it’s still going to give us some degree of buffer against those spikes because it’s passive.  There’s no reaction time involved – it just happens when it happens, which means some of the time it will be there exactly when it needs to be.

Overhealing and Effective Overhealing

The other thing to consider is that this isn’t the entire story.  This is the overhealing that World of Logs registers, but it’s not representative of the effective overhealing.  To explain that thought, consider the following situation.  You take 30k damage, and within the next second you get a 30k SoI proc, a 30k Rejuvenation tick, and a 60k Holy Light.  Any one of them brings you up to full health individually, so which one overhealed?

The game and World of Logs will register the first heal received as being effective, while the latter two will be recorded as overhealing.  But that’s not very realistic – for example, if the SoI proc hadn’t happened, the Rejuvenation tick would have healed you to full anyway.  So you end up in the same state whether the SoI proc occurred or not.  In some sense, the SoI proc was completely irrelevant, because it didn’t do anything effective for your survivability in that situation thanks to the competing heals.  Right?

Well, you could make the same argument about the Rejuvenation, or the Holy Light.  It’s not entirely clear which of the three should get credited with overhealing, because any two of the three are irrelevant depending on your perspective.  But they weren’t all irrelevant, because clearly one of them did something.

This is one problem with logging.  It will always credit the early heals, but can’t easily figure out how much overhealing those heals create later on.  In the case of Seal of Insight and Rejuvenation, I think you could argue that the difference comes out in the wash.  It’s probably about equally likely that the Rejuv tick follows the SoI proc as it is for the reverse to happen.  So the logs probably already account for this interaction between passive effects.  But when it comes to the direct heals that have a cast time, these periodic ticks and procs eat away at the effectiveness.  You may have benefited from the entire Holy Light at the time the cast started, but half of it may be overheal by the time the cast finishes.

So while we might see 60% overhealing for Seal of Insight in a given log, it’s likely that it’s created some non-trivial amount of overhealing in our direct heal accrual.  It’s very hard to say exactly how much that will be without looking at specific logs, and it’s likely to vary significantly based on healer composition.  A tank being healed by a Restoration Druid and a Holy Paladin’s Beacon of Light is going to have a very different amount of direct heal contribution than, say, a Restoration Shaman and an Atonement/Discipline priest.

But this raises some obvious questions about how to accurately model SoI.  Do we try and model it with the overheal values given by World of Logs?  Do we aim a little higher to account for heal-sniping?  If so, how much higher?  And how exactly do we implement that overhealing?

Overhealing Implementations

I’ve had a number of conversations about this topic over the past week, and gotten a lot of different answers. If you recall, we model heals in the code by granting small absorption bubbles that last for a limited amount of time.  We model overhealing by adjusting the size of these bubbles.

Of course, there’s the simple method that we’ve used previously with Word of Glory, which is to just reduce the size of every single heal by a certain amount to account for overhealing.  In other words, if we want approximately 50% overhealing, we just halve the size of each SoI proc.  The downside is that this version doesn’t adapt to damage intake, so an SoI proc occurring after a few avoids gives us the same absorb bubble as one occuring after three full melee hits in a row, even though the latter is far less likely to be overhealing than the former.

We could be a little more sophisticated and include a degree of randomness to the size of the overheal bubbles.  Rather than using a half-sized bubble to represent 50% overhealing, we could just roll the dice for each proc.  We’d grant a full-sized bubble 50% of the time, and no bubble the other 50% of the time.  That “random binary” model would probably mimic the randomness of heal-sniping pretty well, but it still doesn’t give us a method that adapts to damage intake.  In the comments of a previous blog post, Weeby and I discussed using a discrete set of different probability distributions, dynamically choosing which one we use based on prior damage intake.

The method I originally thought about using was to implement an adaptive overhealing function.  Basically, every time we got an SoI proc we would calculate the amount of overheal for that proc based on the previous few boss attacks.  The functional form is a little bit arbitrary, but the essential characteristics I had in mind were as follows:

  • If we took very little damage in the last few attacks, then the SoI proc should do basically nothing, because passive heals from other sources will top us off.
  • If we took a lot of damage in the last few seconds, the SoI proc should be 100% effective, as we can use all the healing we can get.
  • In between those extremes we should have a continuous variation in effectiveness.

The function I had in mind is one encountered commonly in solid-state physics: the Fermi-Dirac distribution, or “Fermi function” for short.  The Fermi function is actually the inverse of what we want – it takes on a value of one for small $x$ and a value of 0 for large $x$, and we want the reverse, so the modified form I used is this:

$$\large f(x)=\frac{1}{1+e^{-(x-x_0)/\sigma}} $$

where $x_0$ and $\sigma$ control the size and shape of the transition.  If we plot this function, it looks something like this:

Example of the fermi function for $x_0=1.5$ and $\sigma = 0.15$.

Example of the fermi function for $x_0=1.5$ and $\sigma = 0.15$.

On the y-axis we have the effectiveness of Seal of Insight, while the x-axis it the sum of the damage from the last three boss attacks.  By setting the halfway point at $x_0=1.5$ we end up with about 75% overheal, which is a little on the high end of our estimates.  But we can tweak $x_0$ and $\sigma$ to match the function to whatever level of overheal we’d like.

There are a few problems with this method, though.  It’s very deterministic by design, so if you take 2-3 full attacks in a row, you’re always going to get full strength SoI proc.  But there are situations where that isn’t an accurate model.  For example, if you receive a Lay on Hands immediately after the third attack, any subsequent SoI procs are basically useless.  And on the other extreme, if you only take a few very weak hits in a row while your healer is distracted, those SoI procs will just heal you up and allow the healer to focus on whatever they’re doing.

So while I like this idea, I also think it introduces a lot of complexity without really accomplishing much.  We could probably get a similar effect by just assuming a flat amount of overhealing on every SoI proc or using one of our random models (binary or discrete set).

One school of thought is to not include overhealing interactions at all – every SoI acts at full strength, no matter what.  The reasoning is pretty simple: we can’t turn it off.  It’ll be there when it occurs no matter what, regardless of what or how many healers you have.  The healers can choose to use that GCD in another way, but our only choice is to swap seals to a mediocre DPS seal.

There’s another argument for full-strength SoI.  We care most about the high-damage spikes, and those are situations where SoI tends to do less overhealing.  We care about healing during that critical time between the start of the spike and our  healers reacting and dumping heals on us, and pretty much every SoI heals for its full amount during that window.  So by assuming SoI is full strength, we probably get a fairly accurate representation of how it works during the danger periods that we care about most.  The downside is that during low-damage periods, we’ll be overestimating its value during the low-damage periods, which will skew our TDR metrics.  But if we’re not that concerned about those low-damage periods anyway, maybe that’s OK.

Backwards-Facing vs. Forward-Facing Modeling

There’s another issue that I’ve been wrestling with for the past few weeks, which is how to model healing more effectively.  The absorb bubble method I’ve been using is a little artificial, in that it makes healing apply to future attacks rather than previous attacks.  But of course, in practice healing replaces damage that’s already occurred. I think you could make a good argument that healing is essentially giving you extra hit points that future attacks need to chew through.  But it’s also not a very intuitive model for most people.

Instead of this “forward-facing” method, we could use what I call a “backward-facing” method.  For example, when we get an SoI proc, we just apply it to a previous attack and reduce the damage that attack did retroactively.  This better matches peoples intuition for how healing works, and doesn’t end up to be much more computationally expensive than the forward-modeling method.

In a pure stochastic sense, it shouldn’t matter which we do as long as the size of the SoI proc doesn’t depend on the attacks surrounding it.  We’re just as likely to avoid the attack before an SoI proc as we are to avoid the attack afterward.  But when you start putting any sort of time dependency into the simulation you get some subtle differences in the results the two modeling methods give you.  And we have a lot of that going on in our system.

For example, SotR itself biases the results.  SotR is a proc trigger for Seal of Insight, and the attack after a SotR cast is about 50% smaller on average than the attack before a SotR cast.  As a result, if you use the forward-facing model, you’ll get more overhealing overall because those procs are being applied to smaller attacks.  The backward-facing model doesn’t have that same bias.  Parry-hasting causes a similar effect, but in reverse: a parry results in 0 damage taken and increases the likelihood of a proc, which causes slightly higher overhealing in the backwards-facing model.

Dynamic overhealing models and Sacred Shield absorbs can enhance or suppress some of those effects, causing further perturbations.  And the SH finisher models create even more complicated interactions between all of those components, because they moderate SotR usage based on damage taken in the last few attacks.  Thus, SoI procs can suppress SotR casts in the backwards-facing model or exacerbate the overhealing caused in the forward-facing model.

I’ve modified the code to be able to handle both methods, but I think I’m probably going to transition to the backwards-modeling case.  It’s easier to explain, for starters, and I think it’s a little more intuitive.  But most importantly, I think it tends to be a little more realistic due to the interactions with SotR, especially for conditional finisher queues.  I’ll probably convert WoG over to the backwards model as well so that I can more naturally incorporate the effects of overhealing, and even come up with queues that only use WoG if it will not be wasted.

Going Forward (But Healing Backward!)

Now that the code’s been updated, we just have to settle on the correct way to do the modeling.  We have a lot of options, but despite all of the sophisticated techniques we have to employ overheal modeling, I’m actually leaning towards the “no-overheal” method, where every SoI proc occurs at full strength.  If we’re mostly concerned with large damage spikes, then this model seems like it would do the best job of accurately representing how SoI affects those peaks.  It does come at the cost of reducing the accuracy of our information during the low-damage periods, though.

It’s possible we could use the Fermi function to adjust for that by setting a fairly low threshold $(x_0)$.  But I’m a little hesitant to do that, because the whole thing feels fairly artificial to me.  It might give us the behavior we think we want, but it’s hard to trust data if we’re not sure we trust the model.  At least with the “full-strength” SoI model, we’re aware that we may be over-estimating its effectiveness in certain situations, as well as which situations those are in particular.  And the backward-facing SoI method tends to reduce the impact of dynamic overhealing modeling anyway, so maybe it’s unnecessary.

Even with the “full-strength” SoI model, we get a fair bit of overhealing.  For starters, we’re only applying Seal of Insight to adjacent melee attacks – in other words, with the backward-facing model we only look one attack into the past.  So if we avoided the previous attack, that SoI proc is all overhealing, because there’s no damage to remove.  The same can be said of the forward-facing model if we avoid the following attack.

And on top of that, we get some overhealing due to other mitigation effects.  Multiple SoI procs, for example, can reduce a blocked or mitigated attack to zero damage.  Keep in mind that each SoI proc is approximately 20% of a boss attack, making it almost as large as a block.  Three SoI procs following a SotR-mitigated block is enough to null out all of that damage.  And in a high-haste set, we get about 25% more SoI procs than we do boss attacks, so we expect about least one SoI proc per attack, and often get clumps of 3 (melee+SotR+CS all falling within 1.5 seconds).

When you throw Sacred Shield absorbs into the mix, you can get situations where even a single SoI proc is predominantly overheal.  In my testing, with Sacred Shield turned off we get about 19% overhealing due to our ~19% avoidance, but with Sacred Shield turned on we rocket up to about 33% overhealing.  About 6% of that difference is due to full absorbs via Sacred Shield, but the last 8% is due to multiple SoI procs.

I think that it’s worth dwelling on the block analogy here.  In the past, we’ve discussed how mastery gives us an active benefit (SotR mitigation) and a passive benefit (block chance), while haste primarily gives us an active benefit.  But if we include Seal of Insight, that’s not really the case.  Haste also gives us more passive SoI procs, which act like slightly smaller blocks.  So both stats give us a fairly significant passive benefit, though in haste’s case it does still rely on us following a rotation and attacking the target.

In any event, I think that many people, myself included, haven’t been giving Seal of Insight enough credit.  I’ve generally written it off as a fairly small effect, and didn’t think too much about it because of the sheer amount of overhealing involved.  But if you asked me if I’d like a bunch of free 20% mitigation blocks, I certainly wouldn’t pass that off as irrelevant.  As long as some of them are occurring during a spike period, I’d care.  And given how frequently we get procs in a haste set, we’re almost guaranteed to have at least $N$ procs within any given string of $N$ attacks.

I hope to have some data ready to publish later this week, as things are finally starting to slow down in real life.  I may put up a post comparing and contrasting several of the different SoI modeling techniques to see what, if any, difference they make in the overall data.  It’s possible that for all of my agonizing over the different models, they all give more or less the same results, at which point maybe we don’t need to worry as much about scrutinizing the model in the first place.

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

On Measuring Survivability

Posted on April 23, 2013 by Theck

The last few posts have garnered a lot of comments, and some of them have indicated that there’s some misunderstandings about the simulations we’re performing.  This set of simulations started back in September, and has been evolving ever since.  And the rationale behind how we perform the simulations is spread out over 6 months of posts.  It seemed like a good idea to consolidate that information in one place.

Basic Modeling Problems

First, let’s consider the point of modeling.  Obviously we want to generate data that helps us make more informed decisions about how we gear and play.  For modeling to be of any benefit, it has to generate information that’s useful.  And generally, that means that you want the model to be accurate.

Most people would assume that means you want the model to be perfect – all-inclusive, with tanks and healers that play perfectly and react with mechanical precision.  But in fact that’s not the case.  Consider what would happen if we did have perfect tanks and perfect healers.  Your perfect tanks would execute their rotation flawlessly, never miss an encounter cue, and would always apply their mitigation skills in the most optimum way.  Your perfect healers would react flawlessly to spikes in damage intake, always select the correct heal at the right time, and would be as mana-efficient as possible.  In your perfect model, you’d have at least enough healing to cover damage intake given perfect conditions, so your perfect healer would never run out of mana.  And the net result would be a tank that never dies.

Unfortunately, that perfect simulation wouldn’t be very useful.  If the tank plays perfectly and never dies, then it barely matters how they gear or what they do.  They’ll be unkillable with any reasonable gear set.  Which highlights the flaw with a perfect simulation: it’s not accurate.  It doesn’t reflect reality. Because in real encounters, players make mistakes and tanks die.  And there’s a fairly high correlation between those mistakes and tank deaths.  Which means that if we want a good, useful simulation, we need to account for that imperfection.

Imperfect Tanks

Unfortunately modeling imperfection is almost as hard as modeling perfection is.  For example, let’s consider how many ways there are to model an imperfect tank.

  • Active Mitigation Usage – You could do it by varying the precision of their active mitigation.  For example, a sloppy player might be macro-ing Shield of the Righteous to Crusader Strike – essentially the “S” rotation we’ve used in the past.  On the other extreme, you could model a near-perfect tank that pools holy power and only blows SotR early during what seems to be a spike – the “SH1″ and “SH2″ rotations we’ve used.  And there are hundreds of variations in-between that differ in effectiveness based on the logic used to control SotR usage.  But which one of those best models a real tank?
  • Rotation – Maybe your tank is perfect and follows CS>J>AS>SS to the letter.  That’s pretty easy to model.  On the other hand, maybe your tank slips up and prioritizes J over CS once in a while by accident.  But how often do they do that?  Are they just as likely to push AS ahead of CS as well, or forget to cast SS when it’s available? Again, we have an infinite number of variations based on the probability distribution you use to determine whether the player makes these errors.
  • Latency – Maybe the player lives next to the server farm, and has sub-millisecond latency.  On the other hand, maybe they’re playing from Australia, and regularly struggle with pings of 350 ms or greater.  Cast queuing helps quite a bit to mitigate these problems, but it still affects events that you need to react to in-game, because even with perfect reactions you’re behind by your latency value.  How much latency should our imperfect player have to deal with?
  • Player Reaction – And even if you live next to the server farm, nobody’s reaction time is instant.  So a player’s response to an event will always be delayed somewhat based on their reaction time and attentiveness.  They may react more slowly to an event if they were watching some other information stream, like DBM timers or their action bars.  How often does our imperfect tank stand in the fire?

It should be evident from this that there’s a huge parameter space to work in here.  And the problem is that it’s very, very difficult to determine what’s “average.”  A reaction time of a full second is certainly below average, but there are players who operate at that capacity.  A completely perfect rotation is possible, but awfully difficult – arguably difficult enough that even the best players can’t manage it.  Everyone slips up once in a while.

Meloree posted a great comment on the last article that I’d like to quote, because it seems fairly relevant here:

As far as imperfect play goes – during wrath/Cataclysm the best I managed to do over the course of a full fight was roughly a 1.53s GCD average over 10 minutes. Thats roughly 98% efficient, and it’s pretty close to an upper bound – not many people ran a tighter rotation than I did. ….

I regularly saw parses from good tanks – in well progressed heroic mode guilds – who weren’t better than ~80% efficient at their rotations. ….

Being more than 90% efficient in your rotation places you in the upper half a percent of tanks in WoW.

So if even the greats are struggling to beat 95% efficiency, what’s our estimate for an average tank?  90%?  80%? 70%?  More to the point, do we really want to be running simulations for an average tank?  The readership of this blog in particular is decidedly skewed towards above-average.  Not many tanks of average or below-average play quality actively seek out blogs to try to improve their play in the first place.  And of the ones that do, how many are willing to struggle through my verbose and technical blog posts?  Probably a small minority.

Imperfect Healers

More problematic yet is the matter of healers.  How do we model an imperfect healer? They have many of the same complications that tanks do.  Latency and reaction time are obvious factors one can tweak.  But the difficult part is really the healer “rotation,” because there really isn’t one in most cases.

For starters, their rotation varies based on the situation – they may be focusing on single-target healing if they’re assigned to a tank, or on area-of-effect healing if they’re assigned to the raid.  And in a 10-man raid, often one healer will be switching back and forth between those two play styles constantly based on the demands of the encounter.  So the type of healing you get depends not just on your play, but on what’s going on with the rest of the raid as well.

Further, a healer’s play style is far more reactive than tanking or DPS play. They may have a basic rotation they use as a default during less dangerous periods, but they switch gears and change cast priorities during a crisis.  They’ll use different spells if the tank has four or five GCDs to live than they will if death could happen in two or three.  And while healers don’t have active mitigation, they do have cooldowns they can throw at the tank if the shit really hits the fan.

So there’s a huge number of variations in how you model an imperfect healer.   Is the healer a little slow to switch modes when the tank takes a spike?  Or do they over-commit to expensive heals and run out of mana too early?  Or do they just not make effective use of their emergency buttons? We could model a “dumb healer” that just spams their mana-efficient heal on the tank regardless of what else is happening, but that’s probably not an accurate model of even the worst healers.

And just as for tanks, each healer plays a little differently.  The model of one imperfect healer may not give accurate results for a different healer.  Not to mention the inherent variations between healers of different classes with slightly different toolkits.  The results may be totally different for a healer that relies heavily on HoTs than they would be for a healer that heavily leans on absorption effects or direct heals.  How do you build a model that’s general and widely applicable when the inputs are so widely varied?

The short answer is: you don’t!

Rethinking The Approach

It’s clear that there’s way too much variation involved here to write the sort of modeling software that most people think of when they talk about wow.  We could certainly write an equivalent to Simcraft, given enough time and effort, but it isn’t clear that it would give us much in the way of useful results.  Tracking things like “how often does the tank die” would vary significantly based on the details of your imperfect healers and tanks.

Not to mention that, while we could model a healer any way we wanted, in practice we have no control over how they play.  We might even have a different healer from week to week or encounter to encounter.  Tying ourselves down to a particular healer model is doomed from the start to be too specific – it just won’t give us results that we can apply everywhere.   We need something that is both more general and simpler to implement.

So we go back to the drawing board.  All the way back to the beginning, in fact.  We reconsider what survivability means at a fundamental level.  What is the root cause of tank death?  I’ll put forth the following hypothesis:

Hypothesis: Tanks are in the most danger of dying when their instantaneous average damage taken per second (DTPS) greatly exceeds their instantaneous average healing received per second (HRPS).

Now, that certainly shouldn’t be very controversial.  I’ve basically said “you die when you don’t get enough heals,” but put it in a more technically rigorous form.  We all know what it means to not receive enough healing.  That happens when our healers are distracted or otherwise incapacitated – in other words, when they make a mistake.

And we’re also familiar with the first half of that statement.  Our time-averaged DTPS goes up when we take a lot of damage in a short period of time.  In other words, a damage spike.  To illustrate that thought, let’s consider some data.  Here’s what the DTPS profile may look like for a tank over an entire encounter (this happens to be Council of Elders):

Tank DTPS

Tank DTPS plotted against time for an entire encounter.

This is the broad overview, showing how damage fluctuates over long periods of time.  We have extended periods of high intake and periods where the tank isn’t actively tanking anything.  Rather than look at the broad view, let’s narrow our focus to the section in the middle, with the large spike followed by three smaller spikes.  That looks like this:

DTPS

Tank DTPS plotted against time for a ~two minute period.

So over a two-minute period, our tank sees massive fluctuations in damage intake.  It drops as low as 40k DTPS, and spikes as high as 150k-230k DTPS for 5- to 10-second periods. The danger periods are obviously these peaks, where damage intake abruptly increases – these are the moments when we’re most at-risk of dying.

From the same log, the tank healers’ average healing throughput is about 100k HPS.  Of course, during this period it gets ratcheted up to around 220 HPS (and other healers chime in to help).  But then again, this is from a log where the tank didn’t die.  If the healer hadn’t cranked his output up fast enough to meet this new level of damage intake, we’re very likely looking at a dead tank.

Let’s assume for the moment that we don’t have any control over our imperfect healers.  Let’s also assume that they screw up every so often during the encounter – maybe they fail to react to a spike quickly enough, or maybe they just stood in fire too long and have to move or break off of the tank to heal themselves.  If one of those screw-ups coincides with one of the damage spikes, we’re probably going to die.

If we accept the premise that we have no control over what our healers do, just what they perceive, then what can we as tanks do to minimize the chance of this happening?  This is what a scientist would call an “overlap integral” problem.  We can increase our survivability by reducing the likelihood that a spike and a healer screw-up overlap in time.  And how do we do that?  Well, consider what would happen if we had a way to perfectly smooth our damage intake, such that instead of the pink line, it looks like the blue line on this plot:

DTPS over a 2-minute period before and after a perfect smoothing algorithm.

DTPS over a 2-minute period before and after a perfect smoothing algorithm.  And by “perfect smoothing algorithm,” I mean “Photoshop’s Line Tool.”

Suddenly everything changes.  First, we don’t have any big spikes to worry about – our mean intake is a little over half of our peak intake (and higher than our average), but it’s very steady.  So it’s far less likely that the healer’s screw-up coincides with a period of extremely high intake, because there simply aren’t any periods of extremely high intake.  More subtly, and perhaps more importantly, the fact that there aren’t any big spikes that require the healer to change modes means that it doesn’t matter if they’re a little slow in doing so.  In practice, that’s a big deal because the “slow to react” healer model is far more likely to cause the sort of overlap that kills you than random healer movement is.  So our “perfect smoothing” mechanism turns a tank that dies some of the time into a tank that never dies.

Now of course, this is an unrealistic model – we have no way to perform this perfect smoothing (outside of Photoshop, at least).  But it gives us a clear goal to aim for.  As tanks, we can’t make our healers play better.  But we can give them an easier damage profile to work with: one that doesn’t require rapid fluctuations in healer throughput.

So I propose the following corollary to our hypothesis:

Corollary: If spike damage is dangerous, then minimizing the frequency and magnitude of high-damage periods is the most direct way to increase survivability.

This is a nice, tidy little statement.  It narrows our focus from an all-encompassing simulation with many variables to a much smaller subset of parameter space.  Instead of worrying about what the healer is doing, we just concern ourselves with the damage intake profile we receive.  In essence, we’ve removed healers from the equation.

Of course, without healers, we don’t have much use for health either.  If we’re only concerned with the plot of damage taken per second, it doesn’t matter how much health we have.    So if we’re ignoring healers, and we’re not tracking tank deaths, then keeping track of the tank’s current hit points is no longer necessary, and we can add “tank health” to the list of things we can cut from the simulation.

Now, that sounds awfully controversial when taken in isolation.  What use is a simulation without healers or tank health? But it follows rather naturally from the corollary.  We’ve been conditioned to think that for a simulation to be useful, it must model everything down to the last detail with near-infinite precision.  But that just isn’t always the case.  It’s great if you want details about a specific situation.  But not if you want general, portable results that apply to a great variety of situations.  By eliminating healers and health from the equation, we can focus our efforts on variables we can control and make sure our modeling of those factors is as accurate as possible.

Building the Simulation

Now that we’ve defined the problem, we can go about building the simulation.  This part is pretty boring unless you’re enthralled by mathematical detail and code, so I’ll try and summarize it as briefly as possible.  We want our sim to do the following:

  1. Simulate a tank being attacked by a boss
  2. Track the damage intake as a function of time
  3. Take the resulting series of damage events and perform calculations on that sequence

Each of these steps has a number of details to consider.  For example, we need to choose the boss’s damage so that we can appropriately assign Vengeance values.  We’ll also need to estimate the player’s gear so that we can appropriately calculate avoidance and block chances.  And of course, later on we’ll want to be able to vary both of these parameters.

Likewise, since we’re tracking damage intake, we need to properly calculate mitigation and absorption effects.  Since our mitigation depends on the tank’s rotation and active mitigation usage, we need to model all of that as well.

The simulation I’ve written does all of those things and more.  It’s a Monte-Carlo style simulation, which means that it simulates combat the same way the game calculates it – making rolls for each event as they happen.  So for example, it cycles through a loop, incrementing time until an event (like a boss attack) occurs.  It then rolls to see if that boss attack is avoided.  If so, it rolls again for a grand crusader proc.  If not, it rolls to see if it was blocked, and so on.  It works the same way for our rotation, following a priority queue (which we can modify) to cast spells and update the system according to their result.

We run it for a very long time (10k minutes of combat, generally) to smooth out random fluctuations and get stable, statistically significant results.  And the output is a string of numbers that looks something like this (but a lot longer):

[... 100 55 0 70 0 100 55 55 38 0 100 55 38 100 0 0 0 100 55 55 100 0 ...]

Where each number represents an amount of damage.  So 100 would be a full boss attack taken to the face, 70 would be a blocked attack, 55 would be an attack mitigated by a 45% mitigation Shield of the Righteous, 38 would be an attack that was blocked and mitigated by SotR, and so on.  In practice these values vary a bit more because of absorption effects (Sacred Shield), but that’s the basic gist of it.

Once we have that string of events, we perform some post-processing on it.  We perform a moving average to generate the sort of data you would see in a World of Logs plot like the one I’ve shown above.  We then take that moving average and calculate how many of its elements exceed a given threshold – say, 100% of the player’s health.  This is the data I present in the tables.  In essence, it’s telling you the two things we care about most: how many spikes are there, and how large are they?

A Word on Healing

One drawback of this style of modeling is that without player health tracking, healing becomes awkward.  That wouldn’t be a problem if it weren’t for the fact that we have a non-trivial amount of self-healing abilities.  For example, how do you model a Word of Glory or Seal of Insight heal if you can’t… well… heal?

The answer is that you treat them as short-term absorption bubbles.  If WoG heals us for 200k health, we instead give ourselves a 200k absorption bubble.  We keep the duration short because this healing is only relevant over short time windows.  In the case of WoG I’ve been using 3 seconds, which is probably too generous; for Seal of Insight I’m using 1.5 seconds.  It wouldn’t make sense to grant a 200k absorption bubble that lasts for 10 seconds, because in 10 seconds a real healer would react and top us off.  So the absorption needs to only apply to boss attacks that happen shortly after the heal occurs.  Another way to think of this is that, by not modeling healers, we’re assuming perfect healers that never let you die, and they react within a few seconds.  Thus, if the absorption bubble isn’t used up within a few seconds, it just gets wasted (i.e. turns into overheal).

Which brings up another issue with healing in this model: overhealing and efficiency.  We need to make assumptions about how much overhealing occurs. For Seal of Insight, you can think of this as trying to estimate how many procs occur when we’re already at full health since our simulation doesn’t have health.  But the issue is a little more subtle than that, even.

To illustrate why, consider the following example: lets say you take a 200k attack from a boss, and react by casting a 200k WoG on yourself.  Your healer also drops a 200k Holy Light on you in response to the attack.  Which one of you overhealed, and how efficient were you?

Logs will base the answer on whomever acted first.  But that doesn’t cut it for our analysis.  Either way, there was 200k worth of overhealing happening in that scenario, and whether it was my WoG or the healer’s Holy Light, one of them was wasted.  No matter who the combat log credits with the overhealing, I would have been better off letting the healer top me off and using that holy power on a Shield of the Righteous instead.

I tend to take a rather pessimistic view on healing efficiency for that reason.  I generally assume that the healer is going to do what they do regardless of whether I WoG or not, because they can’t assume that I will WoG at any given moment.  And likewise, I can’t assume they’ll stop healing me because I know where my WoG button is.  Since neither of us can reliable predict the others’ actions, we’re bound to cause a good chunk of overhealing.  This is less true with incoming healing notifications on unit frames, but not all frames have this capability, nor do all healers use it on frames that do.  However, since opinions vary on this, I generally present results for a variety of overheal levels when I’m discussing results involving WoG.

A Word on Patchwerk

To wind down this post, I want to have a quick discussion about one of the more common criticisms of this sort of modeling.  The simulation is a Patchwerk model, which for newer players means “a boss that blindly melees you and does nothing else.”  But real fights rarely look like Patchwerk.  Real fights have tank swaps, movement, different phases, magical damage.  The criticism I often see is that because of all of those factors we’re ignoring, these simulation results have no relevance to real play.

I think that attitude is a bit narrow-minded, and I don’t think it’s entirely valid.  Sure, there are tank swaps.  Sure, you’ll use cooldowns during a fight.  But you’re obviously not going to die when you don’t have aggro. And you’re probably not going to die while you have Holy Avenger up and are coasting along on 100% uptime of a 50+% damage mitigation buff. You’re not very likely to die when you have a big cooldown running either, for that matter. You’re not even that likely to die right after a tank swap, since you’ll have extra SotR uptime during that period if you’ve pooled holy power.

You’re most likely to die when you get a big damage spike, and that really only happens when you don’t have any of those safety nets. It happens when you just get unlucky and take a couple big unmitigated melees because you’re rebuilding Holy Power.  In other words, it happens in the in-between sections of a fight, when you’re essentially tanking Patchwerk.  By that logic the simple, Patchwerk simulation much more relevant than it would initially appear.  Thus, I think a boss mindlessly hitting you is a pretty good model for the bulk of our death scenarios.

The “big, predictable boss attack” death scenario is pretty dangerous too, and shows up a lot in current content.  But I think it’s less dangerous than many seem to think if you’re using active mitigaton properly.  Shaving 50% off of the predictable spike, and likely one of the neighboring melees as well, usually makes it quite manageable.  Often it reduces the big attack to less than a regular melee swing.  And since it’s a predictable spike, your healers know its coming – they have DBM timers telling them that you’re going to take a big spike in X seconds, so they are more likely to use proactive tools, like absorption shields, small cooldowns, or simply pre-casting a heal on you so that it lands right after the large attack does.

In any event, the “big predictable attack” is something I plan on adding to the simulation once I get time – possibly even before the next round of data posts, since the Seal of Insight code is almost finished.

Despite all of that, it’s worth remembering that specific bosses or mechanics can lead to different strategies being optimal.  We’re trying to model the most general situation possible so that it’s applicable to as many fights as possible.  But mechanics like Dread Thrash can certainly trump steady-state modeling.  A boss like Lei Shi forces us to reconsider whether the model is applicable to that particular boss.  If we had another Algalon-like encounter where you have three healers spamming the tank just to keep up with the damage, you may care a lot less about smoothness and a lot more about stamina, armor, or even avoidance.  This model abstracts all of those things out, so it’s important to keep in mind that this is a guideline for when all of those other effects are already taken care of.  A good tank needs to know when the model is appropriate and when to break from the model to handle specific problems.

Summary

This post doesn’t really have a conclusion.  I haven’t presented anything incredibly new here.  Tanks doing high-end content have been focusing on spike damage for years now.  But up until recently, we really haven’t had good tools to quantify those concerns.  We’ve been able to calculate total damage reduction fairly reliably in the past, and often that metric was used as a stand-in to approximate smoothness.  But the simulations I’ve run in the past six months have demonstrated the inadequacy of that approach.  A stat like haste can be absolutely terrible at reducing total damage taken while being fantastic at reducing spike events.

I hope that the logic behind the simulation is more apparent now, though.  It should, at least, address the common criticism that the results can’t be valid or useful without including healers.  While it’s definitely important to consider what healers think and how they react, I don’t think it’s critical to have a specific healer model in mind when answering the question, “what makes me more survivable.”  While our simulation doesn’t model healers at all, the thought process that we used to arrive at our observables certainly did.  So they are included in the simulation in an indirect manner, in that rather than participating in the simulation explicitly, they determined how we perform the simulation and assess the results.  Healers are the lens we look through when we decide what metrics accurately reflect our survivability.

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

Stamina: Updated Smoothness Data

Posted on April 16, 2013 by Theck

In the last post, I mentioned in passing that there was an odd thing happening when a gear set dropped from 7k to 6k haste.  I elaborated a little on what I thought was the cause: we were crossing the 33.33% spell haste mark, which dropped Sacred Shield’s tick interval to less than 4.5 seconds, thus ensuring it was up for every third boss attack.  That all made sense, and seemed like a good explanation for the strange jump in spike presence when dropping below that haste breakpoint.

What didn’t make sense was that we were getting a very large jump in damage taken at that point too.  The damage mitigation of Sacred Shield should be very continuous and slowly-varying, so that was a hint that something else was going on, and warranted further investigation.  So I did….

… and found out that it was being caused by a bug.  The code was occasionally resetting Sacred Shield a little early thanks to a debugging line that had been commented out (i.e. made inactive), but managed to get un-commented at some point along the way.  Thus, some of the time it would arbitrarily grant your next Sacred Shield bubble earlier than it should have if the previous one had been consumed.

This had a few noticeable effects on the results.  First, it exaggerated the discontinuity at the 33% spell haste threshold, which is the effect that alerted us to it in the first place.  The reason we saw the jump in damage mitigation at that point is that all of the sudden we were getting a lot more early refreshes due to a Moire-like effect.

The second effect is that it obviously made Sacred Shield stronger than it should have been.  It’s still quite powerful, but this bug was causing the code to overestimate its value.  Thus, in the corrected results I present below, we expect higher damage intake across the board as well as less effective spike prevention.

Finally, it has an odd effect on stats.  Since we’re getting free refreshes early, it actually means that it was undervaluing haste.  Haste gives you SS bubbles faster, but that advantage is reduced somewhat when the code was artificially gives you a bubble early some of the time.  Thus, we expect haste to increase in value relative to other stats in both the smoothing department and the TDR department.

Since we have a lot of data to slog through, let’s get started.  This post will be data-heavy and analysis-light, since most of the analysis given in previous posts is still accurate.  I’m going to try and highlight the things that have changed.

Secondary Stat Smoothness Analysis – Gear

First, let’s return to the secondary stat smoothness analysis.  This is the one where we try all sorts of gear sets with different secondary stat allocations.  The gear sets are the same as before, though I’ve brought back Control/Haste+Mastery and the pure Haste build just for completeness.  The stats on each gear set are given below:

|    Set: |  C/Ha |  C/Ma |  C/Av | C/Bal |  C/HM |    Ha | Avoid | Av/Mas | Mas/Av |
|     Str | 15000 | 15000 | 15000 | 15000 | 15000 | 15000 | 15000 |  15000 |  15000 |
|     Sta | 28000 | 28000 | 28000 | 28000 | 28000 | 28000 | 28000 |  28000 |  28000 |
|   Parry |  1500 |  1500 |  7500 |  4125 |  1500 |  1500 | 10825 |   7717 |   4000 |
|   Dodge |  1500 |  1500 |  7500 |  4125 |  1500 |  1500 | 10825 |   7717 |   4000 |
| Mastery |  1500 | 13500 |  1500 |  4125 |  6750 |  1500 |  1500 |   7716 |  15150 |
|     Hit |  2550 |  2550 |  2550 |  2550 |  2550 |   500 |   500 |    500 |    500 |
|     Exp |  5100 |  5100 |  5100 |  5100 |  5100 |   500 |   500 |    500 |    500 |
|   Haste | 12000 |     0 |     0 |  4125 |  6750 | 18650 |     0 |      0 |      0 |

Data – 150k Swings

Here’s the data for the 10N model boss:

Finisher = SH1, Boss Attack = 150k, data set smooth-10000-54

| Set: |   C/Ha |   C/Ma |   C/Av |  C/Bal |   C/HM |     Ha |  Avoid | Av/Mas | Mas/Av |
| mean |  0.370 |  0.361 |  0.354 |  0.360 |  0.362 |  0.355 |  0.323 |  0.331 |  0.341 |
|  std |  0.128 |  0.129 |  0.152 |  0.139 |  0.128 |  0.128 |  0.158 |  0.148 |  0.139 |
|   S% |  0.522 |  0.410 |  0.419 |  0.452 |  0.472 |  0.499 |  0.366 |  0.363 |  0.357 |
|   HP |   755k |   755k |   755k |   755k |   755k |   755k |   755k |   755k |   755k |
|  nHP |  5.034 |  5.034 |  5.034 |  5.034 |  5.034 |  5.034 |  5.034 |  5.034 |  5.034 |
| ---- | ------ |  --- 2 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  20% | 22.700 | 29.013 | 23.363 | 24.014 | 26.152 | 20.559 | 20.444 | 23.374 | 26.473 |
|  30% |  6.953 |  4.207 |  8.496 |  2.608 |  2.516 |  4.532 |  6.757 |  3.614 |  4.156 |
| ---- | ------ |  --- 3 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  20% | 54.132 | 57.541 | 48.624 | 52.663 | 58.336 | 49.501 | 42.242 | 48.225 | 48.747 |
|  30% | 27.413 | 19.642 | 25.915 | 14.937 | 14.729 | 23.603 | 20.554 | 16.322 | 18.614 |
|  40% |  1.513 |  3.732 |  3.881 |  2.584 |  2.450 |  1.978 |  3.709 |  3.920 |  4.283 |
|  50% |  0.000 |  0.023 |  0.274 |  0.024 |  0.000 |  0.000 |  0.280 |  0.158 |  0.122 |
| ---- | ------ |  --- 4 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  30% | 51.312 | 47.154 | 47.174 | 42.967 | 45.038 | 46.142 | 38.660 | 38.607 | 41.522 |
|  40% | 16.894 | 16.704 | 17.272 | 16.254 | 17.122 | 12.803 | 13.689 | 15.421 | 13.154 |
|  50% |  4.832 |  2.201 |  5.650 |  2.156 |  2.157 |  3.678 |  4.483 |  2.808 |  3.111 |
|  60% |  0.061 |  0.209 |  0.335 |  0.233 |  0.193 |  0.099 |  0.517 |  0.583 |  0.510 |
| ---- | ------ |  --- 5 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  40% | 39.951 | 39.884 | 35.843 | 37.449 | 40.071 | 35.061 | 28.730 | 33.249 | 33.285 |
|  50% | 16.712 | 13.088 | 18.232 | 14.927 | 13.321 | 12.918 | 13.923 | 12.362 | 12.036 |
|  60% |  1.823 |  2.506 |  4.506 |  2.852 |  2.049 |  0.612 |  3.569 |  3.563 |  2.547 |
|  70% |  0.080 |  0.230 |  0.745 |  0.200 |  0.058 |  0.128 |  0.766 |  0.540 |  0.556 |
|  80% |  0.000 |  0.009 |  0.025 |  0.009 |  0.005 |  0.000 |  0.082 |  0.062 |  0.069 |
| ---- | ------ |  --- 6 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  40% | 61.898 | 60.106 | 53.983 | 58.784 | 62.406 | 56.114 | 44.454 | 50.722 | 52.255 |
|  50% | 36.677 | 32.226 | 33.623 | 32.905 | 32.038 | 30.645 | 26.056 | 25.518 | 27.926 |
|  60% | 12.653 | 11.299 | 13.852 | 11.918 | 10.236 | 10.124 | 10.410 | 11.511 | 10.098 |
|  70% |  1.428 |  1.728 |  3.906 |  2.605 |  0.857 |  1.482 |  3.269 |  2.675 |  2.055 |
|  80% |  0.019 |  0.079 |  0.620 |  0.139 |  0.022 |  0.089 |  0.620 |  0.389 |  0.338 |
|  90% |  0.000 |  0.004 |  0.043 |  0.005 |  0.001 |  0.011 |  0.100 |  0.071 |  0.069 |
| 100% |  0.000 |  0.000 |  0.001 |  0.000 |  0.000 |  0.000 |  0.006 |  0.001 |  0.002 |
| ---- | ------ |  --- 7 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  50% | 55.597 | 52.773 | 49.689 | 52.379 | 53.030 | 49.731 | 39.605 | 41.014 | 45.659 |
|  60% | 30.524 | 26.001 | 27.718 | 28.772 | 27.060 | 25.182 | 20.731 | 23.245 | 22.259 |
|  70% |  9.065 |  8.487 | 10.887 | 10.841 |  8.191 |  6.198 |  8.438 |  7.881 |  7.726 |
|  80% |  2.241 |  1.160 |  3.455 |  2.287 |  1.667 |  1.444 |  2.748 |  2.315 |  1.705 |
|  90% |  0.076 |  0.068 |  0.489 |  0.260 |  0.103 |  0.066 |  0.578 |  0.378 |  0.262 |
| 100% |  0.000 |  0.002 |  0.005 |  0.002 |  0.001 |  0.003 |  0.039 |  0.027 |  0.034 |
| 110% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.008 |  0.005 |  0.007 |

Not a whole lot has changed here.  Haste has seen a little improvement, but not very much.  It’s still better than mastery at eliminating the highest spikes in a category until we get into the 7-attack category, where mastery’s stochastic block inches it ahead.  C/HM performs pretty well in this low-damage category as well, arguably as good as C/H, albeit at a DPS cost.

Data – 250k Swings

Now for the 10H/25N boss:

Finisher = SH1, Boss Attack = 250k, data set smooth-10000-53

| Set: |   C/Ha |   C/Ma |   C/Av |  C/Bal |   C/HM |     Ha |  Avoid | Av/Mas | Mas/Av |
| mean |  0.390 |  0.377 |  0.368 |  0.375 |  0.378 |  0.377 |  0.336 |  0.345 |  0.355 |
|  std |  0.129 |  0.129 |  0.152 |  0.140 |  0.129 |  0.129 |  0.159 |  0.150 |  0.140 |
|   S% |  0.523 |  0.410 |  0.419 |  0.452 |  0.471 |  0.499 |  0.366 |  0.362 |  0.357 |
|   HP |   755k |   755k |   755k |   755k |   755k |   755k |   755k |   755k |   755k |
|  nHP |  3.021 |  3.021 |  3.021 |  3.021 |  3.021 |  3.021 |  3.021 |  3.021 |  3.021 |
| ---- | ------ |  --- 2 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  20% | 54.327 | 57.943 | 50.704 | 54.520 | 57.903 | 52.367 | 45.420 | 51.608 | 54.981 |
|  30% | 44.852 | 39.832 | 42.398 | 43.459 | 45.381 | 42.809 | 37.786 | 39.011 | 37.803 |
|  40% | 16.688 | 18.278 | 17.627 | 17.476 | 18.118 | 14.038 | 14.979 | 16.213 | 16.977 |
|  50% |  6.991 |  4.890 |  8.450 |  2.683 |  2.680 |  4.604 |  6.693 |  3.520 |  4.838 |
|  60% |  0.156 |  0.746 |  1.021 |  0.689 |  0.527 |  0.143 |  1.103 |  1.029 |  0.644 |
| ---- | ------ |  --- 3 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  40% | 49.264 | 39.300 | 42.411 | 43.781 | 48.055 | 44.661 | 35.319 | 37.762 | 36.571 |
|  50% | 29.561 | 23.042 | 26.579 | 15.851 | 16.212 | 26.999 | 21.023 | 16.317 | 21.391 |
|  60% |  6.911 | 10.785 | 10.271 |  9.627 |  8.853 |  7.761 |  8.966 |  9.600 |  9.269 |
|  70% |  1.536 |  3.492 |  2.785 |  2.683 |  2.704 |  2.026 |  2.957 |  3.781 |  4.223 |
|  80% |  0.323 |  0.616 |  0.865 |  0.647 |  0.558 |  0.542 |  1.110 |  1.093 |  0.833 |
|  90% |  0.000 |  0.047 |  0.048 |  0.015 |  0.000 |  0.000 |  0.076 |  0.084 |  0.053 |
| ---- | ------ |  --- 4 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  50% | 56.781 | 52.448 | 49.803 | 45.523 | 48.859 | 53.922 | 40.873 | 39.346 | 46.674 |
|  60% | 33.474 | 31.087 | 31.783 | 34.582 | 33.344 | 30.369 | 25.869 | 26.871 | 25.203 |
|  70% | 17.003 | 12.678 | 16.798 | 16.233 | 14.823 | 12.906 | 13.223 | 13.225 | 13.060 |
|  80% |  8.689 |  4.933 |  9.319 |  6.910 |  4.197 |  6.643 |  7.492 |  4.765 |  4.966 |
|  90% |  1.136 |  1.688 |  1.770 |  1.271 |  1.424 |  1.058 |  1.786 |  1.850 |  1.981 |
| 100% |  0.300 |  0.414 |  0.658 |  0.327 |  0.284 |  0.281 |  0.827 |  0.654 |  0.628 |
| 110% |  0.008 |  0.061 |  0.107 |  0.077 |  0.042 |  0.029 |  0.206 |  0.186 |  0.108 |
| ---- | ------ |  --- 5 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  60% | 59.483 | 55.688 | 51.792 | 56.686 | 56.561 | 55.647 | 43.142 | 45.840 | 47.831 |
|  70% | 40.480 | 37.121 | 35.733 | 37.290 | 38.462 | 36.053 | 28.242 | 31.063 | 33.100 |
|  80% | 27.276 | 21.955 | 25.709 | 23.432 | 21.921 | 23.470 | 19.943 | 18.292 | 17.793 |
|  90% | 11.237 |  9.947 | 12.957 | 10.586 | 10.110 |  9.378 |  9.840 |  9.320 |  8.741 |
| 100% |  4.183 |  3.352 |  6.709 |  3.880 |  2.789 |  3.361 |  5.288 |  3.884 |  3.615 |
| 110% |  0.309 |  0.911 |  1.791 |  1.461 |  0.740 |  0.351 |  1.700 |  1.577 |  1.384 |
| 120% |  0.027 |  0.267 |  0.293 |  0.213 |  0.100 |  0.120 |  0.423 |  0.521 |  0.515 |
| 130% |  0.001 |  0.043 |  0.088 |  0.051 |  0.012 |  0.031 |  0.180 |  0.180 |  0.151 |
| 140% |  0.000 |  0.002 |  0.004 |  0.001 |  0.000 |  0.000 |  0.030 |  0.037 |  0.016 |
| ---- | ------ |  --- 6 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  70% | 63.681 | 58.649 | 54.080 | 58.665 | 61.755 | 58.844 | 44.043 | 49.095 | 51.853 |
|  80% | 49.886 | 42.187 | 43.512 | 43.182 | 43.426 | 44.341 | 34.345 | 34.477 | 35.127 |
|  90% | 30.485 | 27.290 | 27.892 | 26.206 | 25.868 | 26.951 | 21.186 | 21.653 | 22.258 |
| 100% | 17.015 | 14.738 | 17.648 | 14.466 | 12.701 | 15.379 | 13.362 | 12.233 | 12.433 |
| 110% |  6.924 |  5.901 |  8.643 |  7.910 |  5.064 |  6.212 |  6.617 |  6.431 |  5.914 |
| 120% |  1.512 |  1.780 |  3.449 |  2.732 |  1.066 |  1.601 |  2.830 |  2.746 |  2.187 |
| 130% |  0.344 |  0.419 |  1.454 |  0.765 |  0.076 |  0.492 |  1.336 |  1.007 |  0.882 |
| 140% |  0.019 |  0.079 |  0.349 |  0.077 |  0.018 |  0.084 |  0.424 |  0.358 |  0.300 |
| 150% |  0.001 |  0.014 |  0.091 |  0.006 |  0.001 |  0.023 |  0.163 |  0.102 |  0.103 |
| 160% |  0.000 |  0.001 |  0.005 |  0.002 |  0.000 |  0.002 |  0.035 |  0.036 |  0.025 |
| 170% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.006 |  0.005 |  0.005 |
| 180% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.001 |  0.001 |  0.000 |
| ---- | ------ |  --- 7 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  80% | 67.922 | 63.019 | 59.700 | 61.358 | 63.740 | 63.525 | 48.731 | 51.069 | 53.904 |
|  90% | 52.045 | 48.114 | 45.093 | 46.050 | 47.873 | 47.795 | 35.112 | 37.118 | 39.348 |
| 100% | 38.218 | 31.246 | 33.097 | 32.830 | 32.301 | 34.092 | 25.051 | 24.625 | 25.820 |
| 110% | 23.400 | 17.473 | 21.107 | 21.873 | 18.835 | 19.504 | 15.385 | 14.997 | 15.775 |
| 120% | 11.159 |  9.020 | 10.803 | 10.849 |  8.886 |  8.928 |  8.120 |  8.162 |  8.504 |
| 130% |  4.807 |  3.897 |  5.992 |  4.860 |  3.490 |  3.574 |  4.703 |  4.199 |  4.294 |
| 140% |  1.187 |  1.164 |  2.434 |  1.750 |  1.348 |  1.214 |  2.204 |  2.013 |  1.311 |
| 150% |  0.270 |  0.202 |  0.970 |  0.602 |  0.396 |  0.320 |  1.004 |  0.707 |  0.443 |
| 160% |  0.025 |  0.020 |  0.198 |  0.162 |  0.073 |  0.031 |  0.277 |  0.209 |  0.156 |
| 170% |  0.000 |  0.003 |  0.001 |  0.002 |  0.002 |  0.006 |  0.045 |  0.044 |  0.058 |
| 180% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.001 |  0.015 |  0.015 |  0.015 |
| 190% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.003 |  0.005 |  0.002 |

Again, we see haste continue to perform well at the higher spike categories, but there isn’t a huge difference with previous data sets.  It still falls behind in the stochastic limit, and trails in isolated spots, but does a better job of reducing spikes overall than the other options.

Data – 350k Swings

Finally, our 25H boss:

Finisher = SH1, Boss Attack = 350k, data set smooth-10000-52

| Set: |   C/Ha |   C/Ma |   C/Av |  C/Bal |   C/HM |     Ha |  Avoid | Av/Mas | Mas/Av |
| mean |  0.397 |  0.382 |  0.373 |  0.383 |  0.386 |  0.385 |  0.343 |  0.351 |  0.362 |
|  std |  0.128 |  0.130 |  0.152 |  0.141 |  0.130 |  0.129 |  0.159 |  0.150 |  0.141 |
|   S% |  0.523 |  0.410 |  0.419 |  0.452 |  0.472 |  0.499 |  0.366 |  0.362 |  0.358 |
|   HP |   755k |   755k |   755k |   755k |   755k |   755k |   755k |   755k |   755k |
|  nHP |  2.158 |  2.158 |  2.158 |  2.158 |  2.158 |  2.158 |  2.158 |  2.158 |  2.158 |
| ---- | ------ |  --- 2 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  30% | 54.184 | 57.816 | 50.504 | 54.584 | 57.929 | 52.341 | 45.553 | 51.635 | 54.312 |
|  40% | 48.931 | 43.293 | 45.537 | 48.438 | 47.393 | 46.907 | 40.798 | 41.732 | 41.059 |
|  50% | 22.808 | 28.980 | 23.253 | 24.346 | 26.366 | 20.853 | 20.356 | 23.287 | 25.939 |
|  60% | 15.162 | 15.085 | 16.635 | 17.418 | 15.120 | 13.183 | 14.506 | 15.113 | 14.394 |
|  70% | 11.912 |  8.926 | 13.651 |  7.842 |  7.404 | 11.136 | 12.303 |  8.761 |  9.103 |
|  80% |  0.161 |  1.459 |  0.999 |  0.695 |  0.506 |  0.146 |  1.126 |  1.175 |  1.483 |
|  90% |  0.127 |  0.418 |  0.844 |  0.546 |  0.348 |  0.143 |  0.990 |  0.982 |  0.639 |
| ---- | ------ |  --- 3 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  50% | 57.074 | 57.812 | 48.826 | 53.168 | 58.627 | 54.232 | 42.471 | 48.295 | 48.161 |
|  60% | 46.547 | 35.270 | 40.640 | 43.544 | 37.484 | 41.770 | 34.365 | 33.883 | 32.861 |
|  70% | 32.767 | 26.239 | 32.499 | 30.979 | 20.905 | 31.113 | 28.618 | 23.522 | 25.511 |
|  80% | 10.379 | 14.224 | 12.970 | 10.229 |  9.710 | 11.248 | 11.193 | 11.643 | 13.991 |
|  90% |  5.008 |  5.126 |  7.770 |  6.719 |  5.890 |  5.976 |  7.096 |  7.111 |  5.798 |
| 100% |  1.494 |  3.457 |  2.733 |  2.708 |  2.717 |  2.041 |  2.970 |  3.647 |  4.036 |
| 110% |  0.333 |  0.805 |  1.027 |  0.764 |  0.556 |  0.596 |  1.303 |  1.195 |  1.099 |
| 120% |  0.000 |  0.052 |  0.114 |  0.036 |  0.000 |  0.000 |  0.162 |  0.186 |  0.146 |
| 130% |  0.000 |  0.026 |  0.048 |  0.017 |  0.000 |  0.000 |  0.076 |  0.074 |  0.052 |
| ---- | ------ |  --- 4 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  70% | 59.217 | 54.900 | 54.673 | 57.632 | 53.989 | 57.008 | 48.098 | 47.227 | 50.113 |
|  80% | 40.377 | 40.341 | 37.417 | 37.736 | 38.705 | 37.945 | 31.175 | 32.140 | 36.523 |
|  90% | 30.866 | 21.198 | 27.995 | 27.665 | 27.966 | 28.556 | 22.937 | 23.090 | 19.457 |
| 100% | 13.576 | 12.627 | 14.346 | 16.291 | 14.281 | 11.201 | 12.021 | 13.097 | 10.900 |
| 110% |  8.694 |  5.762 |  9.495 |  8.043 |  8.025 |  7.142 |  7.949 |  6.898 |  6.312 |
| 120% |  5.019 |  2.807 |  5.585 |  2.410 |  2.977 |  3.928 |  4.458 |  3.110 |  3.561 |
| 130% |  0.489 |  1.368 |  1.098 |  1.254 |  1.459 |  0.585 |  1.345 |  1.720 |  1.976 |
| 140% |  0.263 |  0.429 |  0.690 |  0.357 |  0.352 |  0.385 |  0.920 |  0.782 |  0.782 |
| 150% |  0.009 |  0.092 |  0.102 |  0.086 |  0.057 |  0.030 |  0.204 |  0.202 |  0.170 |
| 160% |  0.006 |  0.044 |  0.087 |  0.068 |  0.038 |  0.028 |  0.181 |  0.177 |  0.110 |
| ---- | ------ |  --- 5 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  80% | 65.490 | 62.774 | 57.587 | 61.874 | 63.608 | 62.398 | 49.518 | 52.278 | 57.261 |
|  90% | 56.952 | 48.754 | 48.803 | 49.451 | 51.764 | 53.463 | 40.807 | 41.324 | 42.984 |
| 100% | 39.003 | 36.552 | 33.508 | 37.486 | 38.130 | 35.898 | 27.221 | 31.054 | 30.808 |
| 110% | 27.878 | 25.264 | 26.175 | 27.833 | 27.280 | 24.884 | 21.065 | 21.061 | 20.984 |
| 120% | 18.893 | 14.895 | 18.804 | 15.440 | 16.556 | 16.016 | 14.447 | 13.948 | 12.795 |
| 130% | 10.296 |  7.161 | 10.998 | 10.182 |  9.577 |  8.751 |  8.554 |  8.108 |  7.450 |
| 140% |  4.290 |  3.355 |  6.775 |  5.162 |  3.002 |  3.550 |  5.648 |  4.335 |  4.062 |
| 150% |  0.783 |  1.349 |  2.841 |  1.591 |  1.240 |  0.603 |  2.423 |  2.100 |  1.819 |
| 160% |  0.191 |  0.657 |  1.305 |  0.855 |  0.366 |  0.222 |  1.330 |  1.044 |  0.978 |
| 170% |  0.030 |  0.267 |  0.285 |  0.235 |  0.103 |  0.125 |  0.419 |  0.473 |  0.518 |
| 180% |  0.003 |  0.104 |  0.156 |  0.104 |  0.057 |  0.034 |  0.263 |  0.281 |  0.301 |
| 190% |  0.000 |  0.015 |  0.028 |  0.011 |  0.007 |  0.000 |  0.094 |  0.111 |  0.088 |
| 200% |  0.000 |  0.003 |  0.003 |  0.001 |  0.000 |  0.000 |  0.030 |  0.031 |  0.022 |
| ---- | ------ |  --- 6 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
| 100% | 63.532 | 58.136 | 52.739 | 58.916 | 61.791 | 59.520 | 43.661 | 49.346 | 50.626 |
| 110% | 51.860 | 46.531 | 44.403 | 50.157 | 49.884 | 47.543 | 36.245 | 37.720 | 38.793 |
| 120% | 40.761 | 35.198 | 34.973 | 33.654 | 35.808 | 36.376 | 27.296 | 28.500 | 29.747 |
| 130% | 29.361 | 23.450 | 26.015 | 25.456 | 25.301 | 25.646 | 20.029 | 19.633 | 20.487 |
| 140% | 20.548 | 14.873 | 18.660 | 18.012 | 14.284 | 18.427 | 14.605 | 13.646 | 13.831 |
| 150% |  8.730 |  8.894 | 11.042 |  9.770 |  7.942 |  8.419 |  8.660 |  8.185 |  8.265 |
| 160% |  5.244 |  4.011 |  7.239 |  5.430 |  4.020 |  5.141 |  5.703 |  5.331 |  4.196 |
| 170% |  2.411 |  1.779 |  3.834 |  2.763 |  1.053 |  2.296 |  3.101 |  2.500 |  2.371 |
| 180% |  0.483 |  0.637 |  1.808 |  1.282 |  0.511 |  0.688 |  1.701 |  1.438 |  1.123 |
| 190% |  0.265 |  0.242 |  0.989 |  0.197 |  0.067 |  0.381 |  0.964 |  0.667 |  0.584 |
| 200% |  0.004 |  0.081 |  0.190 |  0.079 |  0.016 |  0.043 |  0.296 |  0.313 |  0.281 |
| ---- | ------ |  --- 7 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
| 120% | 61.023 | 57.190 | 51.807 | 54.107 | 57.313 | 57.034 | 41.765 | 45.130 | 48.563 |
| 130% | 50.736 | 44.161 | 43.401 | 44.980 | 47.764 | 46.326 | 34.243 | 34.933 | 37.238 |
| 140% | 41.940 | 31.846 | 34.947 | 37.077 | 34.785 | 38.072 | 27.156 | 27.042 | 27.614 |
| 150% | 28.043 | 22.872 | 24.477 | 26.571 | 25.060 | 24.928 | 18.812 | 18.451 | 19.944 |
| 160% | 18.939 | 14.241 | 18.328 | 17.192 | 15.452 | 15.934 | 13.799 | 13.304 | 12.601 |
| 170% | 12.203 |  9.027 | 12.248 | 10.905 |  9.212 |  9.447 |  9.056 |  8.053 |  8.848 |
| 180% |  6.625 |  4.665 |  7.329 |  7.161 |  5.257 |  4.806 |  5.649 |  5.165 |  5.066 |
| 190% |  2.948 |  2.272 |  4.421 |  3.007 |  2.739 |  2.313 |  3.694 |  3.177 |  2.467 |
| 200% |  1.079 |  1.138 |  2.061 |  1.529 |  1.395 |  1.141 |  1.834 |  1.837 |  1.281 |

As before, haste excels in the top 3 or 4 damage ranges in each category.  Not a whole lot of new information here either.  The most surprising part is that the bug didn’t seem to be overvaluing haste as much as I expected.  It may simply be that the bug wasn’t as problematic as it could have been due to other interactions that similarly affected the mastery set.  Or maybe I just over-estimated how much of an effect the bug had in the first place.

Let’s see if the stamina data has changed much.

Stamina Comparisons – Gear

We’re using the same five gear sets as the last post. C/Ha and C/Ma for our benchmarks, and then three stamina sets.  The first is the trinket conversion rate (4k haste for 6k stamina), the second is the gem conversion rate (4k haste for 3k stamina).  C/St3 just converts some of the 8000 haste of C/St2 into mastery.

|    Set: |  C/Ha | C/St1 | C/St2 | C/St3 |  C/Ma |
|     Str | 15000 | 15000 | 15000 | 15000 | 15000 |
|     Sta | 28000 | 34000 | 31000 | 31000 | 28000 |
|   Parry |  1500 |  1500 |  1500 |  1500 |  1500 |
|   Dodge |  1500 |  1500 |  1500 |  1500 |  1500 |
| Mastery |  1500 |  1500 |  1500 |  4750 | 13500 |
|     Hit |  2550 |  2550 |  2550 |  2550 |  2550 |
|     Exp |  5100 |  5100 |  5100 |  5100 |  5100 |
|   Haste | 12000 |  8000 |  8000 |  4750 |     0 |

Data – 150k Swings

Again, we’ll test our 10N boss first:

Finisher = SH1, Boss Attack = 150k, data set smooth-10000-56

| Set: |   C/Ha |  C/St1 |  C/St2 |  C/St3 |   C/Ma |
| mean |  0.371 |  0.397 |  0.397 |  0.391 |  0.362 |
|  std |  0.128 |  0.133 |  0.133 |  0.132 |  0.129 |
|   S% |  0.523 |  0.482 |  0.482 |  0.454 |  0.410 |
|   HP |   755k |   876k |   816k |   816k |   755k |
|  nHP |  5.034 |  5.843 |  5.439 |  5.439 |  5.034 |
|  has |  12000 |   8000 |   8000 |   4750 |      0 |
| ---- |  --- 2 | Attack | Moving | Avg.-- | ------ |
|  20% | 22.749 | 20.931 | 26.875 | 28.063 | 29.033 |
|  30% |  6.979 |  0.627 |  2.114 |  3.325 |  4.183 |
| ---- |  --- 3 | Attack | Moving | Avg.-- | ------ |
|  30% | 27.641 |  9.657 | 13.986 | 17.342 | 19.706 |
|  40% |  1.491 |  0.781 |  0.853 |  1.152 |  3.740 |
|  50% |  0.000 |  0.000 |  0.000 |  0.011 |  0.023 |
| ---- |  --- 4 | Attack | Moving | Avg.-- | ------ |
|  30% | 51.621 | 39.828 | 46.886 | 48.352 | 47.278 |
|  40% | 17.041 | 12.727 | 16.866 | 14.805 | 16.793 |
|  50% |  4.853 |  0.969 |  1.557 |  1.537 |  2.250 |
|  60% |  0.064 |  0.000 |  0.073 |  0.071 |  0.208 |
| ---- |  --- 5 | Attack | Moving | Avg.-- | ------ |
|  40% | 40.307 | 34.595 | 40.056 | 39.117 | 40.028 |
|  50% | 16.833 |  8.102 | 13.235 | 12.060 | 13.173 |
|  60% |  1.873 |  0.700 |  1.393 |  1.758 |  2.527 |
|  70% |  0.074 |  0.010 |  0.076 |  0.075 |  0.232 |
|  80% |  0.000 |  0.000 |  0.000 |  0.000 |  0.007 |
| ---- |  --- 6 | Attack | Moving | Avg.-- | ------ |
|  50% | 37.026 | 22.789 | 34.094 | 29.987 | 32.365 |
|  60% | 12.829 |  4.994 |  8.961 |  9.746 | 11.411 |
|  70% |  1.418 |  0.045 |  1.099 |  0.951 |  1.731 |
|  80% |  0.017 |  0.000 |  0.001 |  0.029 |  0.090 |
|  90% |  0.000 |  0.000 |  0.000 |  0.000 |  0.003 |
| ---- |  --- 7 | Attack | Moving | Avg.-- | ------ |
|  50% | 55.902 | 44.770 | 55.480 | 52.236 | 52.989 |
|  60% | 30.812 | 18.308 | 27.914 | 26.135 | 26.232 |
|  70% |  9.193 |  3.293 |  8.847 |  7.201 |  8.632 |
|  80% |  2.270 |  0.199 |  1.557 |  1.063 |  1.203 |
|  90% |  0.081 |  0.001 |  0.104 |  0.007 |  0.076 |
| 100% |  0.000 |  0.000 |  0.000 |  0.000 |  0.002 |

As before, stamina continues to come out ahead.  The trinket version (C/St1) shows a considerable margin, the gem version’s less so.  Both versions have seen their leads considerably lessened though.  We’re no longer seeing as many large order-of-magnitude gaps as before, though a few are still there.  Stamina shouldn’t have had any interaction with the bug, so this seems to confirm that we were overvaluing haste and mastery in the last few posts.

Data – 250k Swings

Finisher = SH1, Boss Attack = 250k, data set smooth-10000-55

| Set: |   C/Ha |  C/St1 |  C/St2 |  C/St3 |   C/Ma |
| mean |  0.389 |  0.415 |  0.415 |  0.407 |  0.376 |
|  std |  0.128 |  0.133 |  0.133 |  0.134 |  0.130 |
|   S% |  0.522 |  0.482 |  0.482 |  0.455 |  0.411 |
|   HP |   755k |   876k |   816k |   816k |   755k |
|  nHP |  3.021 |  3.506 |  3.263 |  3.263 |  3.021 |
| ---- |  --- 2 | Attack | Moving | Avg.-- | ------ |
|  30% | 44.835 | 27.844 | 47.965 | 48.519 | 39.834 |
|  40% | 16.695 | 16.685 | 19.379 | 20.753 | 18.229 |
|  50% |  6.928 |  0.627 |  2.096 |  3.128 |  4.911 |
|  60% |  0.147 |  0.000 |  0.466 |  0.730 |  0.751 |
| ---- |  --- 3 | Attack | Moving | Avg.-- | ------ |
|  40% | 49.074 | 49.012 | 50.430 | 51.822 | 39.107 |
|  50% | 29.299 |  9.782 | 14.358 | 18.038 | 22.977 |
|  60% |  6.939 |  2.851 |  7.055 |  8.487 | 10.796 |
|  70% |  1.529 |  0.795 |  0.848 |  1.119 |  3.533 |
|  80% |  0.306 |  0.000 |  0.000 |  0.042 |  0.626 |
|  90% |  0.000 |  0.000 |  0.000 |  0.013 |  0.042 |
| ---- |  --- 4 | Attack | Moving | Avg.-- | ------ |
|  50% | 56.611 | 43.105 | 47.910 | 51.596 | 52.273 |
|  60% | 33.395 | 22.972 | 34.675 | 34.049 | 30.926 |
|  70% | 16.869 |  9.358 | 13.501 | 14.602 | 12.670 |
|  80% |  8.617 |  1.583 |  3.025 |  3.463 |  4.923 |
|  90% |  1.115 |  0.292 |  0.967 |  1.144 |  1.731 |
| 100% |  0.268 |  0.000 |  0.066 |  0.117 |  0.433 |
| 110% |  0.007 |  0.000 |  0.000 |  0.000 |  0.072 |
| ---- |  --- 5 | Attack | Moving | Avg.-- | ------ |
|  60% | 59.442 | 48.023 | 59.659 | 58.173 | 55.535 |
|  70% | 40.213 | 32.244 | 38.413 | 38.677 | 36.919 |
|  80% | 27.083 | 12.842 | 23.219 | 20.973 | 21.773 |
|  90% | 11.140 |  2.939 |  9.958 |  9.575 |  9.918 |
| 100% |  4.097 |  0.759 |  2.364 |  2.304 |  3.380 |
| 110% |  0.298 |  0.071 |  0.233 |  0.387 |  0.955 |
| 120% |  0.028 |  0.000 |  0.038 |  0.089 |  0.281 |
| 130% |  0.002 |  0.000 |  0.000 |  0.000 |  0.045 |
| 140% |  0.000 |  0.000 |  0.000 |  0.000 |  0.003 |
| ---- |  --- 6 | Attack | Moving | Avg.-- | ------ |
|  80% | 49.834 | 34.352 | 48.294 | 43.318 | 41.953 |
|  90% | 30.239 | 17.863 | 28.385 | 25.971 | 27.184 |
| 100% | 16.774 |  6.042 | 12.333 | 11.954 | 14.625 |
| 110% |  6.853 |  1.275 |  5.252 |  4.275 |  5.820 |
| 120% |  1.466 |  0.033 |  0.828 |  1.139 |  1.777 |
| 130% |  0.333 |  0.001 |  0.017 |  0.109 |  0.429 |
| 140% |  0.017 |  0.000 |  0.001 |  0.009 |  0.086 |
| 150% |  0.000 |  0.000 |  0.000 |  0.000 |  0.013 |
| ---- |  --- 7 | Attack | Moving | Avg.-- | ------ |
|  90% | 51.853 | 39.900 | 51.290 | 48.524 | 47.951 |
| 100% | 37.961 | 22.500 | 33.930 | 31.424 | 31.089 |
| 110% | 23.201 | 10.541 | 19.930 | 16.645 | 17.281 |
| 120% | 10.984 |  3.282 |  8.909 |  7.780 |  8.934 |
| 130% |  4.684 |  1.053 |  3.053 |  2.699 |  3.845 |
| 140% |  1.168 |  0.208 |  1.050 |  0.741 |  1.172 |
| 150% |  0.249 |  0.002 |  0.189 |  0.139 |  0.223 |
| 160% |  0.021 |  0.000 |  0.001 |  0.002 |  0.018 |
| 170% |  0.000 |  0.000 |  0.000 |  0.000 |  0.003 |

Again, a solid win for stamina, but at a much reduced lead, at least for gem swaps.    Trinket swaps are still a flat-out win by a large margin.

Data – 350k Swings

Finisher = SH1, Boss Attack = 350k, data set smooth-10000-51

| Set: |   C/Ha |  C/St1 |  C/St2 |  C/St3 |   C/Ma |
| mean |  0.398 |  0.422 |  0.422 |  0.413 |  0.383 |
|  std |  0.129 |  0.133 |  0.133 |  0.134 |  0.130 |
|   S% |  0.522 |  0.483 |  0.482 |  0.455 |  0.411 |
|   HP |   755k |   876k |   816k |   816k |   755k |
|  nHP |  2.158 |  2.504 |  2.331 |  2.331 |  2.158 |
| ---- |  --- 2 | Attack | Moving | Avg.-- | ------ |
|  40% | 49.022 | 40.344 | 48.450 | 48.483 | 43.319 |
|  50% | 22.900 | 19.886 | 26.298 | 28.645 | 29.060 |
|  60% | 15.323 | 15.355 | 17.130 | 16.479 | 15.022 |
|  70% | 12.052 |  0.613 |  2.084 |  3.072 |  8.893 |
|  80% |  0.161 |  0.000 |  0.619 |  0.712 |  1.453 |
|  90% |  0.131 |  0.000 |  0.000 |  0.000 |  0.403 |
| ---- |  --- 3 | Attack | Moving | Avg.-- | ------ |
|  60% | 46.718 | 39.737 | 49.339 | 40.739 | 35.243 |
|  70% | 32.919 | 13.398 | 14.730 | 17.745 | 26.191 |
|  80% | 10.503 |  6.912 |  9.690 | 10.376 | 14.237 |
|  90% |  5.178 |  0.838 |  2.989 |  3.719 |  5.121 |
| 100% |  1.525 |  0.759 |  0.860 |  1.085 |  3.465 |
| 110% |  0.353 |  0.000 |  0.000 |  0.039 |  0.795 |
| 120% |  0.000 |  0.000 |  0.000 |  0.016 |  0.055 |
| 130% |  0.000 |  0.000 |  0.000 |  0.000 |  0.032 |
| ---- |  --- 4 | Attack | Moving | Avg.-- | ------ |
|  70% | 59.459 | 46.700 | 51.823 | 51.213 | 54.834 |
|  80% | 40.727 | 32.743 | 39.771 | 38.545 | 40.335 |
|  90% | 31.198 | 17.590 | 26.492 | 21.848 | 21.237 |
| 100% | 13.789 |  9.362 | 13.329 | 14.323 | 12.595 |
| 110% |  8.843 |  2.703 |  8.292 |  3.881 |  5.795 |
| 120% |  5.101 |  0.924 |  1.630 |  1.940 |  2.796 |
| 130% |  0.499 |  0.063 |  0.968 |  0.557 |  1.380 |
| 140% |  0.278 |  0.052 |  0.066 |  0.111 |  0.436 |
| 150% |  0.009 |  0.000 |  0.052 |  0.087 |  0.080 |
| 160% |  0.007 |  0.000 |  0.000 |  0.000 |  0.034 |
| ---- |  --- 5 | Attack | Moving | Avg.-- | ------ |
|  90% | 57.303 | 42.564 | 53.495 | 47.479 | 48.820 |
| 100% | 39.424 | 32.256 | 38.364 | 38.293 | 36.630 |
| 110% | 28.273 | 17.653 | 28.107 | 23.406 | 25.308 |
| 120% | 19.148 |  8.624 | 16.206 | 14.246 | 14.852 |
| 130% | 10.426 |  2.628 |  8.215 |  5.924 |  7.099 |
| 140% |  4.357 |  0.796 |  2.640 |  2.318 |  3.398 |
| 150% |  0.804 |  0.177 |  0.910 |  1.249 |  1.339 |
| 160% |  0.215 |  0.039 |  0.183 |  0.197 |  0.630 |
| 170% |  0.034 |  0.000 |  0.037 |  0.081 |  0.258 |
| 180% |  0.005 |  0.000 |  0.007 |  0.018 |  0.108 |
| 190% |  0.001 |  0.000 |  0.000 |  0.001 |  0.014 |
| 200% |  0.000 |  0.000 |  0.000 |  0.000 |  0.002 |
| ---- |  --- 6 | Attack | Moving | Avg.-- | ------ |
| 110% | 52.349 | 39.300 | 52.428 | 46.700 | 46.664 |
| 120% | 41.139 | 27.819 | 38.181 | 34.191 | 35.300 |
| 130% | 29.689 | 13.639 | 27.188 | 21.015 | 23.417 |
| 140% | 20.845 |  7.252 | 13.596 | 12.826 | 14.926 |
| 150% |  8.896 |  2.891 |  8.533 |  7.673 |  8.858 |
| 160% |  5.392 |  0.779 |  2.896 |  2.209 |  3.968 |
| 170% |  2.504 |  0.041 |  0.828 |  1.089 |  1.733 |
| 180% |  0.507 |  0.002 |  0.039 |  0.231 |  0.631 |
| 190% |  0.280 |  0.000 |  0.013 |  0.066 |  0.240 |
| 200% |  0.006 |  0.000 |  0.002 |  0.007 |  0.074 |
| ---- |  --- 7 | Attack | Moving | Avg.-- | ------ |
| 130% | 51.289 | 36.460 | 49.677 | 44.510 | 44.160 |
| 140% | 42.462 | 24.666 | 36.270 | 32.524 | 31.861 |
| 150% | 28.426 | 14.059 | 26.602 | 23.477 | 22.944 |
| 160% | 19.249 |  8.613 | 16.063 | 12.465 | 14.234 |
| 170% | 12.436 |  3.379 |  8.884 |  7.693 |  9.014 |
| 180% |  6.783 |  1.510 |  5.022 |  4.267 |  4.707 |
| 190% |  3.008 |  0.491 |  1.891 |  1.533 |  2.233 |
| 200% |  1.099 |  0.132 |  0.827 |  0.692 |  1.112 |

I think we can still call this one for stamina, though there are a few areas where haste is catching up to the gem swap set.  Overall though, the stamina set still outperforms C/Ha. For every category in which they tie, there are 2-3 where stamina wins.  And we’re still seeing factors of 2 or more improvement in many areas.  But relatively few of the factors of 10 that we saw in earlier sims.

Conclusions

So, the bug in the code was definitely inflating the relative value of stamina compared to haste by undervaluing the latter.  I think it’s safe to say that stamina is still the survivability king, but it’s not as head-and-shoulders above haste as the earlier simulations made it seem.  It’s still the dominant choice for trinket slots though, secondary effects nonwithstanding.

And again, this entire comparison is based on purely physical boss throughput.  In practice, a decent chunk of fights contain non-trivial amounts of magical damage, which shifts the comparison much farther towards stamina.  And on top of that, stamina doesn’t take the same sort of micromanaging that it does to get the levels of performance we’re seeing out of haste with the SH1 queue.

That said, the gem trades are getting close enough that we’re not losing that much survivability by gemming haste.  It’s still a net loss, but experienced tanks might feel more comfortable making that trade for DPS knowing that the loss isn’t as severe as previously predicted.

Mel and I discussed this over e-mail, and I felt his insight was worth quoting:

I think the sim now underrates Stamina, though – I think healing effects and healer reactions (and just general all around quality as an oops-proof stat) give a somewhat larger edge to Stam for raw survival.  While the sim probably offers an upper-bound for the value of haste/mastery, given that it plays almost perfectly, it probably offers a lower bound for stamina’s value.

…..
I suspect fairly strongly that just allowing for some incidental healing will vastly inflate the value of stamina, and somewhat inflate haste and mastery.

I think he’s probably correct in that prediction.  Apart from the differential benefits that the bug was introducing between the different secondary stats, which was a relatively small effect, the majority of what the bug did was introduce a chunk of excess passive absorption, which is basically how we’d model incidental healing.  It seems quite likely that if we implemented a passive, “dumb healer” that just cast Power Word: Shield or Renew on the tank, stamina would leap out ahead again like it did in previous sims.

Which is enough of a motivator that I think I need to buckle down and implement the one mechanic I’ve been avoiding for quite some time: Seal of Insight.  I’ve been avoiding it for a few reasons.  It will be time consuming to implement and bug-check, for starters.  And I expect it to be a large performance hit – the code will probably run about two times slower, maybe more, with the addition of melee swing tracking and another short-term buff.  And there are still a lot of unanswered questions about how to properly model the benefits of SoI.  But it’s exactly the sort of “dumb healing” that Mel wants, with the caveat that it scales with our haste as well.  The common-sense assumption is that SoI healing will inflate haste’s value, but the “dumb healing” aspect may very well provide a stronger benefit to stamina than haste.

Luckily, Weeby and I have had some good discussions in the comments that have given me a good idea how to model it effectively.  I’m still not looking forward to it, but at this point it’s one of the last puzzle pieces, and it really needs to be put in.

Before I get to that (and partly to buy myself some time to do it), I do have two more analyses I want to do with the current code, looking at haste->mastery and haste->stamina trades in finer detail.  And I still have the T15 4-piece to test now that it’s implemented.  So there’s plenty of stuff I can be simulating and posting about while I work on the new code.

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

Stamina Addendum: Socket Stuffer?

Posted on April 12, 2013 by Theck

Earlier this week, I made a pretty lengthy post discussing the merits of stamina as a smoothing stat.  One of the common (and expected) criticisms was that I used the usual itemization ratio of 1 haste : 1.5 stamina for the comparisons.  Those results are thus accurate for things like trinkets and socket bonuses, but what many people are interested in is whether they should gem stamina.  And in Mists of Pandaria, gems were tweaked to be more favorable to secondary stats, giving a 2 haste : 1.5 stamina ratio.  That’s a pretty significant swing (basically doubling the haste cost to add 1 stamina), so it would be nice to know how that affects the results.

All of the simulation details and analysis are the same as in the previous post, so I’ll skip the nitty-gritty details – if you’re interested, you can (and should, if you haven’t already) go back and read the first one.

Gear

This time around, we’re going to narrow our view to 5 gear sets.  We’ll keep Control/Haste and Control/Mastery, since those are interesting and serve as useful benchmarks.  Since fewer people care about the avoidance sets, we’ll axe those.  The results don’t change for any of the gear sets we simmed last time anyway, so there’s no point in repeating them.

We’ll look at 3 stamina sets.  C/St1 is the C/StH set from the last post, which trades 4000 haste for 6000 stamina (the 1:1.5 ratio found on trinkets).  C/St2 is a set that uses gem trade ratios (2:1.5), swapping 4000 haste for 3000 stamina.  C/St3 is the same as C/St2, except that we equalize haste and mastery at 4750 just to see if there’s anything to be gained through that synergy.

|    Set: |  C/Ha | C/St1 | C/St2 | C/St3 |  C/Ma |
|     Str | 15000 | 15000 | 15000 | 15000 | 15000 |
|     Sta | 28000 | 34000 | 31000 | 31000 | 28000 |
|   Parry |  1500 |  1500 |  1500 |  1500 |  1500 |
|   Dodge |  1500 |  1500 |  1500 |  1500 |  1500 |
| Mastery |  1500 |  1500 |  1500 |  4750 | 13500 |
|     Hit |  2550 |  2550 |  2550 |  2550 |  2550 |
|     Exp |  5100 |  5100 |  5100 |  5100 |  5100 |
|   Haste | 12000 |  8000 |  8000 |  4750 |     0 |

Data

Again, we’ll run this for 3 different attack sizes: 150k, 250k, and 350k.  The first set is the baby boss (or 10N/LFR boss):

Finisher = SH1, Boss Attack = 150k, data set smooth-10000-48

| Set: |   C/Ha |  C/St1 |  C/St2 |  C/St3 |   C/Ma |
| mean |  0.329 |  0.339 |  0.339 |  0.360 |  0.311 |
|  std |  0.119 |  0.120 |  0.120 |  0.125 |  0.118 |
|   S% |  0.522 |  0.482 |  0.482 |  0.455 |  0.411 |
|   HP |   755k |   876k |   816k |   816k |   755k |
|  nHP |  5.034 |  5.843 |  5.439 |  5.439 |  5.034 |
| ---- |  --- 2 | Attack | Moving | Avg.-- | ------ |
|  10% | 62.748 | 49.850 | 53.108 | 56.912 | 54.227 |
|  20% | 15.187 | 10.243 | 17.256 | 24.057 | 21.396 |
|  30% |  1.569 |  0.002 |  0.050 |  0.868 |  0.834 |
| ---- |  --- 3 | Attack | Moving | Avg.-- | ------ |
|  20% | 43.390 | 38.530 | 45.319 | 55.419 | 47.088 |
|  30% | 16.365 |  4.907 |  7.150 |  8.052 |  9.811 |
|  40% |  0.638 |  0.165 |  0.173 |  1.000 |  2.375 |
| ---- |  --- 4 | Attack | Moving | Avg.-- | ------ |
|  30% | 38.176 | 25.246 | 33.279 | 36.961 | 31.199 |
|  40% |  4.921 |  2.273 |  3.218 | 10.878 |  9.773 |
|  50% |  1.069 |  0.036 |  0.123 |  0.411 |  0.665 |
|  60% |  0.000 |  0.000 |  0.000 |  0.009 |  0.001 |
| ---- |  --- 5 | Attack | Moving | Avg.-- | ------ |
|  30% | 60.027 | 49.349 | 56.637 | 60.793 | 55.091 |
|  40% | 24.926 | 16.529 | 20.776 | 31.289 | 24.342 |
|  50% |  6.257 |  1.979 |  3.383 |  4.791 |  3.432 |
|  60% |  0.107 |  0.017 |  0.087 |  0.380 |  0.360 |
|  70% |  0.009 |  0.000 |  0.001 |  0.012 |  0.068 |
| ---- |  --- 6 | Attack | Moving | Avg.-- | ------ |
|  40% | 47.572 | 36.588 | 43.843 | 53.476 | 42.834 |
|  50% | 19.931 |  9.618 | 15.542 | 18.535 | 15.640 |
|  60% |  4.769 |  0.209 |  1.917 |  4.980 |  3.674 |
|  70% |  0.138 |  0.004 |  0.047 |  0.447 |  0.292 |
|  80% |  0.003 |  0.000 |  0.000 |  0.001 |  0.000 |
| ---- |  --- 7 | Attack | Moving | Avg.-- | ------ |
|  50% | 38.751 | 24.645 | 33.973 | 40.099 | 33.079 |
|  60% | 16.609 |  3.322 | 10.197 | 16.684 | 12.152 |
|  70% |  2.144 |  0.341 |  1.238 |  3.377 |  1.845 |
|  80% |  0.190 |  0.001 |  0.053 |  0.074 |  0.078 |
|  90% |  0.000 |  0.000 |  0.001 |  0.002 |  0.006 |

Stamina certainly does less well with gem trade ratios than it did with trinket ratios, but it’s still far ahead of C/Ha and C/Ma.   It’s still giving at least a factor of 2 or greater reduction in spike representation in the highest categories, and often more than that.  So even with gem trade ratios, stamina is still ahead for small boss swings.

There doesn’t seem to be any gain by shifting to equal amounts of haste and mastery. That said, I think something more subtle is going on here.  In other data sets where I vary the haste->stamina trade more continuously (i.e. in steps of 1000 haste for 1500 or 750 stamina), I see a distinct discontinuity between gear sets with 7000 and 6000 haste.  This leads me to believe that there’s some sort of break point happening in between those values, but I haven’t had time yet to nail down what exactly is causing it.  Thus, I can’t be sure yet whether it’s real or an artifact of the simulation.  The general trend still holds – despite that discontinuity, dropping more haste for stamina continues to reduce spike presence, but there’s always a small loss going from 7000 to 6000.

My best guess is that it’s the result of crossing the ~33% spell haste threshold, which happens in-between those marks.  That would drop the 6-second SS tick interval to 4.5 seconds, which is an integer multiple of our boss swing timer (1.5).  That ensures SS is active for every third boss swing, which is probably a fairly noticeable survivability gain.  This also means that, provided my guess here is correct, we may want to aim for keeping at least 15.44% haste, or around 6562 haste rating (which gives us 33.33% spell haste after raid buffs and SoI).

And before you ask, yes, I plan on publishing those other sim results. I just haven’t had much time to write.  Probably next week-ish, since it will be a short one and not a 6k+ word monstrosity like the last post was.

Onwards to the mama boss (or 10H/25N):

Finisher = SH1, Boss Attack = 250k, data set smooth-10000-49

| Set: |   C/Ha |  C/St1 |  C/St2 |  C/St3 |   C/Ma |
| mean |  0.336 |  0.349 |  0.349 |  0.380 |  0.330 |
|  std |  0.123 |  0.123 |  0.123 |  0.127 |  0.121 |
|   S% |  0.523 |  0.482 |  0.482 |  0.455 |  0.411 |
|   HP |   755k |   876k |   816k |   816k |   755k |
|  nHP |  3.021 |  3.506 |  3.263 |  3.263 |  3.021 |
| ---- |  --- 2 | Attack | Moving | Avg.-- | ------ |
|  20% | 46.599 | 46.814 | 48.464 | 57.298 | 54.530 |
|  30% | 35.868 | 14.918 | 37.019 | 46.591 | 35.377 |
|  40% |  6.855 |  7.971 |  8.031 | 14.958 |  7.169 |
|  50% |  0.018 |  0.000 |  0.000 |  0.615 |  0.832 |
|  60% |  0.000 |  0.000 |  0.000 |  0.118 |  0.057 |
| ---- |  --- 3 | Attack | Moving | Avg.-- | ------ |
|  30% | 63.002 | 49.433 | 61.058 | 73.028 | 58.701 |
|  40% | 34.228 | 31.659 | 32.583 | 45.229 | 23.134 |
|  50% | 18.947 |  4.995 |  8.538 |  9.924 | 10.781 |
|  60% |  4.140 |  0.571 |  3.294 |  4.391 |  5.532 |
|  70% |  0.284 |  0.034 |  0.037 |  0.958 |  2.515 |
|  80% |  0.003 |  0.000 |  0.000 |  0.000 |  0.402 |
| ---- |  --- 4 | Attack | Moving | Avg.-- | ------ |
|  50% | 44.797 | 28.942 | 32.639 | 43.537 | 35.977 |
|  60% | 19.819 |  2.359 | 14.921 | 26.114 | 19.980 |
|  70% |  1.329 |  0.436 |  0.903 | 10.932 |  8.005 |
|  80% |  0.202 |  0.024 |  0.386 |  1.999 |  1.654 |
|  90% |  0.003 |  0.000 |  0.027 |  0.428 |  0.147 |
| 100% |  0.000 |  0.000 |  0.000 |  0.019 |  0.023 |
| 110% |  0.000 |  0.000 |  0.000 |  0.000 |  0.005 |
| ---- |  --- 5 | Attack | Moving | Avg.-- | ------ |
|  60% | 43.078 | 27.818 | 38.551 | 50.308 | 43.030 |
|  70% | 23.250 | 13.814 | 17.652 | 31.444 | 22.810 |
|  80% | 11.857 |  3.256 |  8.146 | 14.254 |  7.508 |
|  90% |  4.299 |  0.156 |  2.055 |  4.593 |  1.924 |
| 100% |  1.465 |  0.013 |  0.032 |  0.579 |  0.842 |
| 110% |  0.003 |  0.000 |  0.003 |  0.147 |  0.374 |
| 120% |  0.000 |  0.000 |  0.000 |  0.015 |  0.095 |
| 130% |  0.000 |  0.000 |  0.000 |  0.000 |  0.009 |
| ---- |  --- 6 | Attack | Moving | Avg.-- | ------ |
|  70% | 46.328 | 32.299 | 39.334 | 54.475 | 42.759 |
|  80% | 29.121 | 14.994 | 22.867 | 34.062 | 24.130 |
|  90% | 13.768 |  3.917 | 11.938 | 17.375 | 12.623 |
| 100% |  6.363 |  1.068 |  3.794 |  6.670 |  6.001 |
| 110% |  1.315 |  0.009 |  0.022 |  2.553 |  2.107 |
| 120% |  0.006 |  0.000 |  0.002 |  0.614 |  0.431 |
| 130% |  0.000 |  0.000 |  0.000 |  0.015 |  0.032 |
| 140% |  0.000 |  0.000 |  0.000 |  0.001 |  0.002 |
| ---- |  --- 7 | Attack | Moving | Avg.-- | ------ |
|  80% | 48.072 | 33.141 | 43.482 | 55.545 | 45.096 |
|  90% | 31.029 | 16.779 | 28.119 | 38.536 | 29.729 |
| 100% | 19.007 |  6.684 | 14.021 | 22.413 | 17.184 |
| 110% |  8.809 |  1.328 |  5.146 | 10.695 |  7.668 |
| 120% |  3.034 |  0.205 |  1.346 |  4.089 |  2.425 |
| 130% |  0.826 |  0.017 |  0.213 |  0.842 |  0.463 |
| 140% |  0.072 |  0.000 |  0.018 |  0.089 |  0.088 |
| 150% |  0.002 |  0.000 |  0.000 |  0.016 |  0.034 |
| 160% |  0.000 |  0.000 |  0.000 |  0.000 |  0.009 |

Again, we see that C/St2 loses a little ground, but remains way ahead of C/Ha and C/Ma.  C/St3 still brings nothing attractive to the table (and honestly, based on the SS guess, likely never will – a better comparison might be a set that maintains 6562 haste and shifts the rest into mastery).

Finally, the papa boss (25H):

Finisher = SH1, Boss Attack = 350k, data set smooth-10000-50

| Set: |   C/Ha |  C/St1 |  C/St2 |  C/St3 |   C/Ma |
| mean |  0.347 |  0.359 |  0.360 |  0.361 |  0.340 |
|  std |  0.124 |  0.124 |  0.124 |  0.121 |  0.121 |
|   S% |  0.522 |  0.482 |  0.483 |  0.455 |  0.410 |
|   HP |   755k |   876k |   816k |   816k |   755k |
|  nHP |  2.158 |  2.504 |  2.331 |  2.331 |  2.158 |
| ---- |  --- 2 | Attack | Moving | Avg.-- | ------ |
|  30% | 46.649 | 46.804 | 48.485 | 53.357 | 54.784 |
|  40% | 40.467 | 32.002 | 38.552 | 40.765 | 41.178 |
|  50% | 12.476 |  8.093 | 14.797 | 18.589 | 22.078 |
|  60% |  6.717 |  7.785 |  8.067 |  7.577 |  6.567 |
|  70% |  6.428 |  0.001 |  0.000 |  0.009 |  5.921 |
|  80% |  0.000 |  0.000 |  0.000 |  0.000 |  0.407 |
|  90% |  0.000 |  0.000 |  0.000 |  0.000 |  0.002 |
| ---- |  --- 3 | Attack | Moving | Avg.-- | ------ |
|  50% | 46.591 | 37.575 | 41.153 | 47.030 | 48.599 |
|  60% | 30.707 | 26.953 | 32.580 | 27.925 | 22.117 |
|  70% | 23.178 |  7.278 |  9.083 |  9.370 | 17.159 |
|  80% |  7.126 |  3.268 |  5.084 |  4.934 |  8.000 |
|  90% |  3.279 |  0.040 |  0.622 |  1.625 |  3.578 |
| 100% |  0.294 |  0.040 |  0.043 |  0.334 |  2.596 |
| 110% |  0.005 |  0.000 |  0.000 |  0.000 |  0.490 |
| ---- |  --- 4 | Attack | Moving | Avg.-- | ------ |
|  70% | 48.670 | 30.956 | 38.988 | 38.537 | 40.912 |
|  80% | 28.311 | 15.312 | 23.233 | 26.174 | 26.497 |
|  90% | 19.385 |  2.036 | 13.008 |  7.109 | 15.855 |
| 100% |  1.456 |  0.477 |  0.882 |  3.620 |  8.229 |
| 110% |  0.349 |  0.031 |  0.413 |  1.037 |  3.533 |
| 120% |  0.164 |  0.028 |  0.030 |  0.164 |  1.104 |
| 130% |  0.003 |  0.000 |  0.030 |  0.086 |  0.106 |
| 140% |  0.002 |  0.000 |  0.000 |  0.000 |  0.073 |
| 150% |  0.000 |  0.000 |  0.000 |  0.000 |  0.004 |
| ---- |  --- 5 | Attack | Moving | Avg.-- | ------ |
|  80% | 50.821 | 40.924 | 47.852 | 50.591 | 49.889 |
|  90% | 40.712 | 21.826 | 33.670 | 29.017 | 39.184 |
| 100% | 24.706 | 13.841 | 19.906 | 20.333 | 23.498 |
| 110% | 13.498 |  5.529 | 11.756 | 10.496 | 13.020 |
| 120% |  8.299 |  2.016 |  5.130 |  4.226 |  6.211 |
| 130% |  4.082 |  0.163 |  1.953 |  0.763 |  1.716 |
| 140% |  1.598 |  0.016 |  0.150 |  0.212 |  0.966 |
| 150% |  0.066 |  0.000 |  0.016 |  0.096 |  0.482 |
| 160% |  0.002 |  0.000 |  0.003 |  0.044 |  0.145 |
| 170% |  0.000 |  0.000 |  0.000 |  0.002 |  0.106 |
| 180% |  0.000 |  0.000 |  0.000 |  0.000 |  0.015 |
| ---- |  --- 6 | Attack | Moving | Avg.-- | ------ |
|  90% | 60.500 | 45.595 | 55.896 | 53.459 | 58.681 |
| 100% | 47.955 | 32.775 | 43.062 | 43.073 | 44.017 |
| 110% | 34.445 | 17.777 | 31.428 | 27.991 | 30.624 |
| 120% | 22.786 | 11.846 | 16.208 | 16.874 | 20.351 |
| 130% | 13.073 |  3.916 | 10.200 |  8.754 | 11.842 |
| 140% |  9.106 |  1.095 |  3.933 |  3.185 |  6.593 |
| 150% |  2.744 |  0.019 |  1.114 |  1.718 |  3.961 |
| 160% |  1.236 |  0.003 |  0.012 |  0.259 |  1.240 |
| 170% |  0.006 |  0.001 |  0.002 |  0.028 |  0.471 |
| 180% |  0.001 |  0.001 |  0.002 |  0.010 |  0.135 |
| 190% |  0.001 |  0.000 |  0.000 |  0.000 |  0.024 |
| ---- |  --- 7 | Attack | Moving | Avg.-- | ------ |
| 110% | 54.338 | 38.252 | 50.338 | 50.335 | 51.903 |
| 120% | 42.523 | 28.300 | 35.667 | 36.260 | 39.804 |
| 130% | 30.438 | 15.656 | 26.514 | 25.422 | 28.936 |
| 140% | 23.351 |  8.838 | 15.502 | 13.769 | 18.752 |
| 150% | 14.246 |  2.722 |  8.881 |  7.946 | 12.727 |
| 160% |  7.375 |  1.291 |  3.706 |  3.511 |  6.470 |
| 170% |  3.716 |  0.217 |  1.357 |  1.322 |  2.623 |
| 180% |  1.325 |  0.020 |  0.221 |  0.585 |  1.087 |
| 190% |  0.413 |  0.002 |  0.032 |  0.102 |  0.380 |
| 200% |  0.077 |  0.001 |  0.001 |  0.006 |  0.095 |

Nothing surprising here.  Stamina still dominates, even at gem trading ratios.

Conclusions

So, as expected, stamina maintains its lead even when you halve its itemization ratio.  The reason this wasn’t a surprise is the sheer size of the advantage stamina held in the last sim.  It was about an order of magnitude better than haste in most cases, and that means that we’d need to crank the itemization ratio down by a factor of almost 10 to see haste compete.  A factor of 2 just isn’t going to cut it.

Nonetheless, it should be clear that if you’re shifting itemization into stamina from something else, you want to do it in the most efficient way possible. First, start with trinkets, since you get a 1.5:1 stamina:secondary trade on those.  Unfortunately, this tier only has one stamina trinket, so we’re actually stuck making a less efficient trade, often trading ~1500 secondary stats for ~1600-1700 stamina from a lower-ilvl trinket.  That’s still a 1:1 trade though, which is better than the 0.75:1 trade you get from gems.  Trinkets are also the easiest thing to swap out, which makes it convenient to switch to haste trinkets for a farm boss or for DPS parsing.

Enchants and what not are sort of variable – they don’t always use consistent ratios.  For example, you can get 170 haste from Enchant Gloves – Greater Haste, but only 150 stamina from a Sha Armor Kit.  On boots the armor kit competes with the 175 haste from Enchant Boots – Greater Haste or 140 Mastery from Enchant Boots – Pandaren’s Step.  In both cases, I think the armor kit is the better survivability choice, and the ratio is still better than sacrificing haste gems for stamina.  You’ll have to handle these on a case-by-case basis.

Gems should be your last place to give up haste (or conversely, the first place to start shedding stamina for more haste).  They give you the most efficient trade, which is good since you’ll already probably want to use some haste or haste/stam gems to pick up socket bonuses anyway.  It’s worth noting that socket bonuses can skew the results in either direction, depending on what you’re gaining or giving up.  For example, going from a haste/stam gem to a stam gem in a yellow socket that has a 60 haste bonus attached to it will be a steeper loss than normal (240 haste for 120 stam, or 2:1).  A similar trade with a 90 stamina socket bonus is even worse (160 haste for 30 stam, or 5.33:1).  But going from a haste gem to a haste/stam gem in a blue socket with any bonus is going to be a very efficient trade (160 haste for 210 stam, or 100 haste for 120 stam).  So when socket bonuses are involved, you’ll have to evaluate the net loss or gain according to the rest of your gear (this is where tools like AskMrRobot come in handy, since they do the math for you).

In previous expansions, I maintained a table listing all of the potential stamina-to-secondary-stat trade ratios for each potential swap, including socket bonuses and what not.  I haven’t gotten around to doing that this expansion, and time spent doing that is time not spent working on sims, so I probably won’t bother.  However, it’s not a particularly difficult mathematical task, so it might be a good project for someone who’s got more free time on their hands.  If someone does decide to put that together, I’d be happy to link to it to spread the word, or even host it here on the blog (maybe a mini guest post?).

But generally speaking, that’s the order you’ll use to make your stamina-to-haste or haste-to-stamina trades.  When going from haste to stamina, swap trinkets before enchants before gems; when going from stamina to haste, swap gems before enchants before trinkets.

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

Stamina: Keeping You Up Longer

Posted on April 9, 2013 by Theck

What’s the most misunderstood element of tanking?  There are a myriad of topics you could offer as guesses.  But the question I field more often than any others isn’t about rotations, talents, glyphs, or cooldowns.  It’s not even about which secondary stats to focus on, even though this expansion has thrown us for a loop in that department as well.  Without a doubt, the question I get asked most often is “How should I value stamina?”

And I think it’s fair to say that this question is one of the great mysteries of tank theorycrafting.  It’s spawned discussions, arguments, and more than a few blog posts.  Everyone seems to have an opinion on the topic, but few seem to have based that opinion on evidence.

More to the point, I think a lot of the opinions I’ve seen offered are flat-out wrong.  One commonly-held opinion, which came up again a few weeks ago, is that the best survivability strategy is to stack stamina until you have “enough” and then switch to other, better survivability stats like haste.

Now, there are plenty of holes in that argument.  But the biggest, in my mind, is the errant assertion that there are better survivability stats than stamina.  The entire strategy relies on the idea that stamina becomes less valuable the more you have of it, but more importantly that this drop-off is rapid and happens at an attainable threshold (the nebulous “enough” value).  I think there’s no question that the first part is true – going from being able to survive two boss attacks to three boss attacks is certainly a larger survivability gain than going from ten to eleven boss attacks, and there has to be a fairly continuous progression between those two points.

But the second part is misguided.  I could see this argument if we were interested in total damage reduction (TDR), where stamina does draw the short straw. However, I’ve yet to see someone employ the argument to get “enough” stamina and then stack avoidance, which would be the optimal TDR strategy.  And to be frank, TDR is an afterthought in the current tanking environment – anyone trying to optimize for it is doing their raid a disservice to begin with.

No, in every case I’ve seen, the person giving advice was suggesting that the player stop stacking stamina and focus on a smoothing stat.  Generally haste, but on occasion I’ve seen mastery mentioned.  Buried in that advice is the unstated assumption that stamina isn’t as good at smoothing as other secondary stats.   And that assumption is just flat-out wrong.

Since this is a fairly pervasive misunderstanding, it’s about time we proved it.

Model Development

The first question we need to ask is exactly how we’re going to measure the effect stamina has on damage smoothing.  You may remember that in an earlier blog post, I said that we’d run into a number of problems with adding stamina (or health) to the simulation.  If we wanted to be truly rigorous about it, we’d need to include healers, health tracking, and some sort of AI that models how a healer reacts to damage spikes.  While I think all of that is true in the strict sense, I also think we can cheat a little bit.

For example, in our recent simulations we haven’t included the differences in healer reactions for a haste tank versus a mastery tank or an avoidance tank.  Your healers certainly do react differently to each of those gearing strategies, but we haven’t even considered it.  We narrowed our view down to a metric we can easily deduce: damage spike size.  It stands to reason that we can do the same with stamina.  The only caveat is that when comparing haste and mastery, healer reaction differences is a fairly small effect, so we can reasonably expect our comparison to be a pretty close approximation to the real world.  Stamina has a much larger effect on healer reaction than either of the other stats though, so by throwing out any pretense of modeling healers, we are ignoring a significant portion of stamina’s benefit.

In other words, we can estimate stamina’s worth with this sort of simulation, but in doing so we necessarily undervalue stamina.  We get a lower bound on its value, but the true value is going to be higher in practice.  That’s OK though – having a lower bound is better than having nothing at all.

Updating the model is fairly easy otherwise.  The formulas that convert stamina to hit points are well known, and were easy to insert into the sim.  I needed to make some changes to the gear sets, which we’ll discuss shortly, but those weren’t difficult either.  The biggest change that needed to be made was, ironically enough, updating the data reporting scheme.

Data Reporting Changes

The data reporting scheme we’ve been using up until now will not be sufficient once we include stamina.  We’ve been reporting spike representation as a function of “maximum throughput” – comparing the size of a N-attack spike to a string of N full hits.  But that metric doesn’t include health at all, so the impact stamina has on spike damage is transparent to it.  We need to come up with a different way to report the data that is a little more universal.  And to be fair, I think this change has been a long time coming.  While working in normalized units is convenient for the mathematician, it’s not always very intuitive.  I think that many readers have had trouble parsing the data tables on these posts because of the “unnaturalness” of the metric.

To illustrate why this is, note that in the last post we were discussing damage “spikes” of 30%-40% maximum throughput.  This led to a discussion between Mel and I about what really constitutes “spike damage” in the first place.  Your healers are going to have to deal with strings of 2-3 full hits in a row from time to time, so they are definitely going to plan their healing setup around having enough throughput to keep up with the occasional back-to-back or back-to-back-to-back hit.  Their throughput healing is almost guaranteed to exceed 50% of the boss’s maximum throughput, because on occasion they need to be able to heal through 100% throughput.  So is a string of attacks that doesn’t exceed 30% of maximum throughput really a spike? Or is it something we shouldn’t even be concerned with?

I think Mel makes a strong argument here that the categories we cared about were generally the highest one or two in each column rather than the bulk of the distribution.  And that argument makes haste an even more solid victor in the last round of simulations, though I think it was a pretty clear winner anyway.  But even I got a little too focused on the numbers and didn’t give enough thought to what the numbers meant, and I think that primarily happened because the metric isn’t as clear as it could be.

So it’s about time we came up with a better, more intuitive metric that people can look at and instantly understand.  And the logical way to do that is to think about the data the same way a healer would.  What a healer notices when you take damage is the size of the chunk that disappears from your health bar.  In other words, they care about how big a hit is compared to your maximum (or current) health.  As such, it seems logical to normalize our data the same way.  Thus, in the tables in this and future posts will list the size of the spike in terms of percentage of total health.

This metric has two major advantages.  First, it’s very intuitive – if I see that a spike is 100% of my max health, it’s very clearly deadly, while a 30% spike probably isn’t.  Second, it automatically includes stamina, because increasing your total health reduces the relative spike size accordingly.  And it’s a logical way to incorporate stamina, as turning a 100% spike into a 90% spike by stacking stamina has a very clear meaning (namely that you can now survive something you couldn’t before).

Gear

With the metric “fixed,” we need to consider how to modify our gear setups.  I could include stamina options for each of the different strategies, but that seems like overkill.  The Control/Haste set has been dominating the charts, so it seems reasonable to build our stamina set out of that one.  Stamina doesn’t have any sort of synergy with any of our secondary stats, so there’s little point in trying different versions of stamina strategies if our trial case is a clear winner or loser.

We do, however, need to assume a baseline stamina value for all of the sets.  After doing a little research, I settled on a value of around 28k stamina from gear.  Note that this is before the modifiers for Plate Specialization and Guarded by the Light, so your character sheet will generally show a value that’s about 31% higher than this.  That 28k stamina will look like around 37k stamina on your character sheet once base stamina is included.  And of course, Power Word: Fortitude and Flask of the Earth will increase that value further.  The simulation assumes all of these effects are present to generate the player’s hit points.  Once all of that is factored in, this gives the player 755k health fully buffed.

For our stamina set, we’ll stay conservative.  We’ll only sacrifice 4000 of the 12k haste that the Control/Haste set is packing, which gives us an additional 6000 stamina.  Our stamina set, which we’ll call “C/StH” to indicate that it’s a Control/Stam+Haste set, then has a total of 34k stamina before flask and raid buff are considered, or a little less than 45k stamina on the character sheet.  This is equivalent to 876k health fully buffed.

The stats for all of the gear sets are given in the table below.  Note that the Strength value is after buffs, not before (unlike stamina).  Also note that at Blizzhoof’s insistence, I’ve added the 3000 mastery raid buff to the simulation, though it doesn’t show up on the table below.

|    Set: |  C/Ha | C/StH |  C/Ma |  C/Av | C/Bal |  C/HM | Avoid | Av/Mas | Mas/Av |
|     Str | 15000 | 15000 | 15000 | 15000 | 15000 | 15000 | 15000 |  15000 |  15000 |
|     Sta | 28000 | 34000 | 28000 | 28000 | 28000 | 28000 | 28000 |  28000 |  28000 |
|   Parry |  1500 |  1500 |  1500 |  7500 |  4125 |  1500 | 10825 |   7717 |   4000 |
|   Dodge |  1500 |  1500 |  1500 |  7500 |  4125 |  1500 | 10825 |   7717 |   4000 |
| Mastery |  1500 |  1500 | 13500 |  1500 |  4125 |  6750 |  1500 |   7716 |  15150 |
|     Hit |  2550 |  2550 |  2550 |  2550 |  2550 |  2550 |   500 |    500 |    500 |
|     Exp |  5100 |  5100 |  5100 |  5100 |  5100 |  5100 |   500 |    500 |    500 |
|   Haste | 12000 |  8000 |     0 |     0 |  4125 |  6750 |     0 |      0 |      0 |

 

Data Tables and Simulation Details

The new tables are a little longer, but contain most of the same information.  The top section still lists the mean damage intake, the standard deviation of damage intake (using a 5-attack moving average), and average SotR uptime, “S%”.  However, it now also gives us two new rows describing hit points.  The first is fully-buffed hit points in thousands, “HP”.  The second is that value normalized by the size of a boss attack, “nHP”.  In other words, if you  have 600k hit points and the boss hits you for 150k on average, “HP” is 600k and “nHP” is 4.

After that comes the usual breakdown of spike representation, but this time it’s given in terms of percentage of maximum health.  So for example, if a row is labeled  “40%” in the “4-attack moving average” section, it is telling  you what percentage of 4-attack sequences exceeded 40% of your total health.  For clarity, the new tables automatically filter out rows that are all zeros, so you can safely assume that rows above the highest shown are trivial (i.e. all zeros).  It also suppresses rows where each set has greater than 50% representation – this is our semi-arbitrary cut-off for “spike damage.”  The theory being that your healers can trivially handle anything spike that’s less than 50% of your maximum health, so they’re not worth considering either.

I’m using the SH1 finisher because it generally performs better for C/Ha than the SH2 finisher does. I’ve simmed out both just to check, and this is still the case in these simulations.  I’m also including Sacred Shield in the model.  Again, I’m trying to give Control/Haste every possible advantage it can get just to make sure we’re getting a fair comparison.

Data – 150k Swings

Since there’s a large disparity in damage intake between both 10- and 25-man raids as well as normal and heroic modes, we’ll look at a few different boss attack sizes.  We’ll start with a boss that hits the tank for 150k damage per swing after armor mitigation.  This is our model for a “10-man normal mode” boss.  Many people suggest that since 10-man bosses hit for so much less than 25-man bosses, stamina is far less valuable in that format.  If that’s true, then this simulation should reveal that weakness.  In terms of normalized health, we’re looking at values a little over 5 boss attacks for the usual sets and about 5.8 boss attacks for the stamina set.  Note that this is intentionally shy of a new breakpoint; the stamina set will not survive 6 boss attacks, so we’re not seeing any discrete effects due to being able to survive one more full boss hit (not that those effects are very strong or relevant anyway, but some people seem to erroneously think they are, so we may as well indulge them just in case).

Here’s what the data looks like:

Finisher = SH1, Boss Attack = 150k, data set smooth-10000-41

| Set: |   C/Ha |  C/StH |   C/Ma |   C/Av |  C/Bal |   C/HM |  Avoid | Av/Mas | Mas/Av |
| mean |  0.329 |  0.339 |  0.310 |  0.312 |  0.329 |  0.302 |  0.282 |  0.286 |  0.291 |
|  std |  0.120 |  0.120 |  0.118 |  0.142 |  0.132 |  0.114 |  0.144 |  0.135 |  0.126 |
|   S% |  0.522 |  0.482 |  0.410 |  0.419 |  0.452 |  0.471 |  0.366 |  0.362 |  0.357 |
|   HP |   755k |   876k |   755k |   755k |   755k |   755k |   755k |   755k |   755k |
|  nHP |  5.034 |  5.843 |  5.034 |  5.034 |  5.034 |  5.034 |  5.034 |  5.034 |  5.034 |
| ---- | ------ |  --- 2 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  10% | 62.691 | 49.929 | 54.016 | 54.026 | 50.931 | 48.579 | 46.493 | 45.292 | 50.230 |
|  20% | 15.057 | 10.363 | 21.207 | 18.159 | 20.220 | 16.530 | 16.262 | 18.871 | 18.945 |
|  30% |  1.555 |  0.002 |  0.835 |  3.220 |  0.752 |  0.103 |  2.081 |  0.484 |  0.583 |
| ---- | ------ |  --- 3 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  20% | 43.186 | 38.691 | 46.775 | 40.820 | 47.142 | 43.082 | 34.946 | 40.453 | 37.135 |
|  30% | 16.292 |  4.971 |  9.730 | 15.009 |  7.841 |  6.885 | 11.310 |  7.236 |  9.301 |
|  40% |  0.627 |  0.170 |  2.346 |  1.877 |  2.070 |  1.035 |  1.697 |  2.133 |  2.353 |
| ---- | ------ |  --- 4 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  30% | 38.041 | 25.490 | 30.972 | 34.316 | 34.587 | 25.874 | 27.377 | 25.821 | 27.281 |
|  40% |  4.878 |  2.293 |  9.641 | 10.464 | 11.735 |  3.720 |  7.840 |  9.014 |  7.525 |
|  50% |  1.046 |  0.034 |  0.684 |  2.954 |  1.111 |  0.413 |  2.305 |  1.061 |  1.014 |
|  60% |  0.000 |  0.000 |  0.001 |  0.039 |  0.022 |  0.000 |  0.034 |  0.022 |  0.009 |
| ---- | ------ |  --- 5 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  30% | 59.866 | 49.691 | 54.815 | 52.069 | 57.158 | 49.828 | 43.297 | 43.952 | 47.461 |
|  40% | 24.880 | 16.673 | 24.063 | 24.710 | 29.552 | 18.935 | 18.827 | 22.079 | 20.083 |
|  50% |  6.191 |  2.008 |  3.396 |  9.911 |  9.260 |  3.279 |  7.322 |  4.778 |  3.981 |
|  60% |  0.102 |  0.018 |  0.354 |  0.884 |  0.665 |  0.091 |  0.738 |  0.589 |  0.594 |
|  70% |  0.004 |  0.000 |  0.069 |  0.095 |  0.071 |  0.009 |  0.147 |  0.117 |  0.120 |
| ---- | ------ |  --- 6 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  40% | 47.392 | 36.848 | 42.403 | 41.896 | 50.114 | 38.803 | 32.995 | 37.109 | 36.236 |
|  50% | 19.806 |  9.678 | 15.496 | 21.328 | 24.322 | 13.762 | 15.784 | 13.368 | 13.865 |
|  60% |  4.727 |  0.223 |  3.562 |  6.052 |  6.288 |  1.774 |  4.452 |  4.244 |  3.545 |
|  70% |  0.121 |  0.005 |  0.296 |  1.205 |  1.321 |  0.060 |  1.011 |  0.643 |  0.396 |
|  80% |  0.002 |  0.000 |  0.001 |  0.042 |  0.008 |  0.000 |  0.061 |  0.022 |  0.011 |
|  90% |  0.000 |  0.000 |  0.000 |  0.001 |  0.000 |  0.000 |  0.003 |  0.001 |  0.000 |
| ---- | ------ |  --- 7 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  40% | 65.495 | 55.517 | 59.491 | 56.730 | 65.748 | 57.023 | 46.694 | 51.129 | 52.506 |
|  50% | 38.579 | 24.792 | 32.720 | 35.224 | 42.416 | 29.837 | 27.022 | 26.237 | 27.976 |
|  60% | 16.473 |  3.415 | 11.878 | 16.301 | 19.863 |  8.017 | 11.599 | 11.432 | 10.355 |
|  70% |  2.131 |  0.363 |  1.859 |  5.008 |  6.172 |  1.181 |  3.655 |  2.699 |  2.023 |
|  80% |  0.173 |  0.000 |  0.075 |  1.182 |  0.616 |  0.057 |  0.845 |  0.357 |  0.185 |
|  90% |  0.000 |  0.000 |  0.006 |  0.042 |  0.015 |  0.000 |  0.053 |  0.030 |  0.033 |
| 100% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.002 |  0.000 |  0.001 |

For 150k swings, none of the categories regularly exceed 100% of our health, so it’s questionable whether we can call any of these highly dangerous.  That said, there’s no doubt about it – stamina beats the pants off of everything else in terms of damage smoothing.  Even for these very weak boss hits – the regime where stamina should perform worst – converting 4k haste to 6k stamina creates a significant reduction in spike representation.  And it’s not a small reduction either; it’s often reducing spike representation by a factor of 10 or more in the highest categories, which are the ones that matter most.

The C/StH set does take about 3% more damage than the C/Ha set and sacrifices about 4% SotR uptime (absolute, about 8% relative uptime).  But the 3% higher damage intake is a small price to pay for the incredible amount of smoothing that stamina brings to the table.  We make a far less efficient trade of damage intake for smoothness by choosing C/Ha over one of the avoidance gear sets.  And the loss of SotR uptime is only relevant in the context of smoothing, so it’s not actually a loss we’re concerned about.  We’re trading the smoothing of that SotR uptime for much more smoothing through a different avenue.

Now, if you’re a long-time reader of this blog, even this data shouldn’t be surprising to you.  It’s pretty easy to see that a 10% increase in health makes every spike 10% smaller in a relative sense, and that makes those spikes significantly less dangerous.  This is the intuitive basis I’ve been using to argue that stamina was our best survivability stat all along.  All I’ve done here is quantify it within the Monte-Carlo simulation to show that my intuition was correct.

It’s also worth noting that all of the damage in this simulation is physical.  If we add any source of magical damage, stamina gets even better, because it doesn’t care what damage type you’re taking.  So if stamina wins in this best-case scenario for secondary stats, it will trounce them even more in a real encounter with a variety of damage sources.  And remember, we’re already undervaluing it by excluding the benefits to healer reaction time and mana.

Now that we’ve seen how stamina performs in 10-man normal raids, let’s up the ante a bit and look at slightly larger boss swings.

Data – 250k Swings

The 250k-swing category is a rough model of 25-man normal modes and 10-man heroic modes.  With harder hits, one might expect that more stamina is necessary to survive.  On the other hand, SotR mitigation automatically scales with boss hit size, so larger hits naturally make haste and mastery stronger too.  Stamina doesn’t scale with boss hit size, so one could even make an argument that stamina becomes less effective as a survivability stat as boss hit size increases.

In fact, both of these are true.  The relative strength of stamina vs. haste should decrease as boss hit size increases.  Each SotR mitigates more damage, making each point of haste stronger, while every point of stamina is still providing the same amount of hit points.  And that amount of stamina is now a smaller percentage of boss hit size.  In this case, for 250k attacks we’ve dropped to a little over 3 attacks worth of health for the baseline sets, but only 3.5 attacks for the C/StH set. Of course, when a boss hits harder, you need more stamina to survive a handful of boss attacks too.  So stamina is becoming more valuable indirectly at the same time that it’s becoming less efficient.

The question we want to answer is whether stamina drops off enough to make it less useful than haste once we can survive “enough” boss hits.  While still vague, we can roughly interpret that to mean “long enough for our healers to react and counter the spike.”  At any rate, what we’re looking for in the data is a case where the C/StH set trails the standard C/Ha set.

So let’s see if it’s there or not:

Finisher = SH1, Boss Attack = 250k, data set smooth-10000-42

| Set: |   C/Ha |  C/StH |   C/Ma |   C/Av |  C/Bal |   C/HM |  Avoid | Av/Mas | Mas/Av |
| mean |  0.336 |  0.349 |  0.330 |  0.307 |  0.349 |  0.323 |  0.282 |  0.304 |  0.309 |
|  std |  0.123 |  0.123 |  0.121 |  0.135 |  0.134 |  0.117 |  0.139 |  0.137 |  0.129 |
|   S% |  0.523 |  0.482 |  0.411 |  0.419 |  0.452 |  0.472 |  0.367 |  0.362 |  0.357 |
|   HP |   755k |   876k |   755k |   755k |   755k |   755k |   755k |   755k |   755k |
|  nHP |  3.021 |  3.506 |  3.021 |  3.021 |  3.021 |  3.021 |  3.021 |  3.021 |  3.021 |
| ---- | ------ |  --- 2 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  20% | 46.595 | 46.810 | 54.570 | 41.292 | 51.317 | 48.799 | 36.159 | 45.405 | 50.331 |
|  30% | 35.926 | 14.938 | 35.570 | 32.936 | 41.260 | 34.056 | 29.073 | 34.938 | 32.673 |
|  40% |  6.860 |  8.010 |  7.179 |  8.109 | 12.581 |  8.060 |  7.851 | 10.003 |  7.135 |
|  50% |  0.020 |  0.000 |  0.789 |  0.074 |  0.645 |  0.080 |  0.054 |  0.381 |  0.580 |
|  60% |  0.000 |  0.000 |  0.053 |  0.006 |  0.129 |  0.000 |  0.008 |  0.088 |  0.002 |
| ---- | ------ |  --- 3 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  30% | 63.104 | 49.406 | 58.880 | 55.756 | 66.220 | 57.338 | 49.341 | 56.215 | 53.846 |
|  40% | 34.331 | 31.648 | 23.055 | 28.416 | 37.490 | 32.754 | 24.270 | 28.690 | 22.703 |
|  50% | 19.006 |  5.030 | 10.638 | 13.249 |  8.533 |  8.266 | 10.753 |  7.580 | 10.333 |
|  60% |  4.156 |  0.588 |  5.542 |  3.510 |  4.563 |  3.245 |  3.169 |  4.345 |  5.443 |
|  70% |  0.278 |  0.035 |  2.592 |  1.006 |  2.252 |  1.019 |  1.104 |  2.180 |  2.458 |
|  80% |  0.005 |  0.000 |  0.401 |  0.225 |  0.619 |  0.112 |  0.341 |  0.577 |  0.428 |
| ---- | ------ |  --- 4 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  40% | 61.965 | 57.398 | 54.526 | 51.666 | 59.961 | 58.657 | 44.476 | 49.014 | 49.824 |
|  50% | 45.051 | 29.046 | 35.889 | 36.134 | 37.860 | 32.099 | 29.877 | 28.250 | 31.758 |
|  60% | 19.806 |  2.373 | 20.050 | 17.852 | 27.129 | 14.528 | 14.422 | 17.228 | 16.721 |
|  70% |  1.338 |  0.450 |  8.129 |  4.063 | 12.113 |  3.891 |  3.871 |  8.218 |  7.622 |
|  80% |  0.198 |  0.024 |  1.685 |  1.602 |  4.868 |  0.804 |  1.742 |  2.523 |  1.904 |
|  90% |  0.005 |  0.000 |  0.144 |  0.138 |  0.477 |  0.082 |  0.251 |  0.474 |  0.229 |
| 100% |  0.000 |  0.000 |  0.020 |  0.001 |  0.050 |  0.000 |  0.002 |  0.037 |  0.010 |
| 110% |  0.000 |  0.000 |  0.003 |  0.000 |  0.018 |  0.000 |  0.001 |  0.009 |  0.000 |
| ---- | ------ |  --- 5 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  50% | 64.146 | 51.156 | 59.567 | 54.779 | 60.858 | 56.683 | 46.843 | 47.754 | 52.800 |
|  60% | 43.273 | 27.848 | 42.980 | 35.392 | 49.374 | 37.181 | 28.778 | 34.183 | 36.046 |
|  70% | 23.415 | 13.826 | 22.950 | 17.813 | 30.001 | 19.425 | 13.991 | 21.325 | 20.049 |
|  80% | 11.898 |  3.263 |  7.558 |  9.860 | 17.352 |  8.310 |  7.859 | 10.840 |  7.380 |
|  90% |  4.309 |  0.160 |  1.947 |  3.546 |  5.669 |  2.519 |  2.817 |  3.769 |  2.270 |
| 100% |  1.457 |  0.013 |  0.865 |  1.180 |  0.958 |  0.248 |  0.977 |  0.871 |  1.119 |
| 110% |  0.004 |  0.000 |  0.394 |  0.120 |  0.385 |  0.072 |  0.202 |  0.441 |  0.538 |
| 120% |  0.000 |  0.000 |  0.111 |  0.030 |  0.093 |  0.016 |  0.073 |  0.132 |  0.163 |
| 130% |  0.000 |  0.000 |  0.009 |  0.005 |  0.010 |  0.001 |  0.020 |  0.023 |  0.022 |
| ---- | ------ |  --- 6 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  60% | 63.811 | 52.319 | 62.497 | 52.253 | 67.569 | 58.613 | 43.626 | 51.026 | 53.647 |
|  70% | 46.505 | 32.327 | 42.700 | 35.896 | 50.816 | 39.697 | 28.347 | 36.676 | 36.427 |
|  80% | 29.339 | 15.025 | 24.101 | 23.699 | 34.918 | 23.105 | 18.530 | 22.820 | 20.898 |
|  90% | 13.879 |  3.923 | 12.694 | 12.101 | 18.525 | 11.309 |  9.379 | 11.710 | 10.804 |
| 100% |  6.391 |  1.083 |  6.103 |  5.949 |  8.187 |  3.932 |  4.787 |  5.364 |  5.383 |
| 110% |  1.299 |  0.011 |  2.167 |  1.636 |  4.122 |  0.974 |  1.558 |  2.576 |  2.176 |
| 120% |  0.004 |  0.000 |  0.468 |  0.189 |  1.554 |  0.094 |  0.306 |  0.802 |  0.552 |
| 130% |  0.000 |  0.000 |  0.038 |  0.027 |  0.377 |  0.012 |  0.096 |  0.166 |  0.109 |
| 140% |  0.000 |  0.000 |  0.000 |  0.003 |  0.011 |  0.001 |  0.013 |  0.029 |  0.009 |
| 150% |  0.000 |  0.000 |  0.000 |  0.000 |  0.001 |  0.000 |  0.000 |  0.003 |  0.001 |
| ---- | ------ |  --- 7 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  70% | 64.218 | 51.512 | 61.659 | 52.033 | 66.623 | 58.797 | 42.529 | 51.330 | 53.747 |
|  80% | 48.342 | 33.314 | 45.131 | 39.160 | 52.671 | 42.564 | 31.209 | 37.377 | 38.036 |
|  90% | 31.252 | 16.770 | 29.761 | 25.488 | 36.930 | 26.821 | 19.665 | 24.054 | 24.415 |
| 100% | 19.183 |  6.731 | 17.233 | 15.273 | 24.039 | 13.899 | 11.816 | 14.130 | 14.360 |
| 110% |  8.843 |  1.348 |  7.812 |  6.777 | 14.794 |  5.296 |  5.282 |  7.881 |  7.043 |
| 120% |  3.057 |  0.204 |  2.515 |  2.432 |  6.646 |  1.718 |  2.029 |  3.386 |  2.588 |
| 130% |  0.823 |  0.013 |  0.477 |  0.944 |  2.526 |  0.439 |  0.890 |  1.359 |  0.713 |
| 140% |  0.076 |  0.000 |  0.091 |  0.271 |  0.516 |  0.056 |  0.285 |  0.410 |  0.224 |
| 150% |  0.002 |  0.000 |  0.037 |  0.048 |  0.083 |  0.001 |  0.074 |  0.074 |  0.100 |
| 160% |  0.000 |  0.000 |  0.012 |  0.002 |  0.028 |  0.000 |  0.013 |  0.026 |  0.039 |
| 170% |  0.000 |  0.000 |  0.002 |  0.000 |  0.001 |  0.000 |  0.004 |  0.005 |  0.008 |
| 180% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.001 |  0.000 |  0.001 |

It doesn’t look like stamina is struggling at all in this data set.  It’s still the dominant anti-spike stat at 250k boss swing sizes, again decreasing spike representation by factors of 10 or more for the largest spikes.  And in this data set, we’re seeing some truly deadly spikes (i.e. over 100% health).  Stamina always provides a very significant drop in those categories, which are ones we care quite a lot about.

It’s worth noting that the avoidance sets are starting to make a much better showing in this regime.  They still suffer from the “long tail” – i.e. they still have non-zero representations in the highest spike categories and see the largest absolute spikes.  However they quite frequently beat C/Ha if we consider “what percentage of attacks exceed my total health?”  This is an important distinction that we couldn’t effectively make with the old boss-normalized data table structure in previous posts.

An avoidance set might give you a nonzero chance to let through a sequence exceeding 150% of your health, which seems bad.  However, if the avoidance set gives you a lower chance of taking a spike exceeding 100% of your health overall, the distribution of those attacks isn’t that important.  In the rough sense, you’re dead either way, so why does it matter?  That glosses over some obvious nuances – for example, once you consider healers you might survive a 120% spike more easily than a 150% spike, so there’s still value in shifting the distribution to lower levels.  But it’s something to consider if we’re going to critically analyze what each gear set is really accomplishing.

That said, even though the avoidance sets perform pretty well, there’s one set that always beats them in every category.  Yep, you guessed it: stamina.  Good ol’ stamina. Nothin’ beats stamina.

Let’s crank the boss attacks up once more and see what happens.

Data – 350k Swings

This is our 25-man heroic boss model.  350k is a pretty large chunk, enough that even 3-attack sequences become very dangerous.  This sort of boss necessitates smart use of active mitigation, and in theory that’s what Control/Haste excels at.  We could make the same argument about stamina becoming less efficient because each point is a smaller portion of a boss attack.  Let’s see if it’s enough to allow C/Ha to regain the lead:

Finisher = SH1, Boss Attack = 350k, data set smooth-10000-43

| Set: |   C/Ha |  C/StH |   C/Ma |   C/Av |  C/Bal |   C/HM |  Avoid | Av/Mas | Mas/Av |
| mean |  0.346 |  0.360 |  0.340 |  0.317 |  0.331 |  0.332 |  0.291 |  0.311 |  0.317 |
|  std |  0.124 |  0.124 |  0.121 |  0.136 |  0.128 |  0.118 |  0.141 |  0.139 |  0.130 |
|   S% |  0.523 |  0.482 |  0.410 |  0.419 |  0.452 |  0.472 |  0.366 |  0.363 |  0.357 |
|   HP |   755k |   876k |   755k |   755k |   755k |   755k |   755k |   755k |   755k |
|  nHP |  2.158 |  2.504 |  2.158 |  2.158 |  2.158 |  2.158 |  2.158 |  2.158 |  2.158 |
| ---- | ------ |  --- 2 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  30% | 46.449 | 46.837 | 54.767 | 41.383 | 47.114 | 49.855 | 36.321 | 45.444 | 50.230 |
|  40% | 40.377 | 32.098 | 41.131 | 37.230 | 41.885 | 38.653 | 32.574 | 37.420 | 37.343 |
|  50% | 12.406 |  8.091 | 22.042 | 14.356 | 15.733 | 16.736 | 13.682 | 18.980 | 19.010 |
|  60% |  6.761 |  7.795 |  6.542 |  7.880 |  7.963 |  7.232 |  7.696 |  8.511 |  6.607 |
|  70% |  6.484 |  0.000 |  5.900 |  6.925 |  6.582 |  6.299 |  7.038 |  6.416 |  5.956 |
|  80% |  0.001 |  0.000 |  0.396 |  0.006 |  0.006 |  0.000 |  0.013 |  0.121 |  0.302 |
|  90% |  0.001 |  0.000 |  0.001 |  0.000 |  0.001 |  0.000 |  0.000 |  0.076 |  0.001 |
| ---- | ------ |  --- 3 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  50% | 46.395 | 37.558 | 48.541 | 38.766 | 39.831 | 44.063 | 33.432 | 40.787 | 37.438 |
|  60% | 30.619 | 27.007 | 22.089 | 26.063 | 29.254 | 26.503 | 22.502 | 23.973 | 20.894 |
|  70% | 23.180 |  7.297 | 17.133 | 20.279 | 21.650 | 17.964 | 18.485 | 16.027 | 16.953 |
|  80% |  7.098 |  3.306 |  7.984 |  5.695 |  5.468 |  5.758 |  5.031 |  6.279 |  8.072 |
|  90% |  3.284 |  0.037 |  3.567 |  2.743 |  2.863 |  2.496 |  2.614 |  2.986 |  3.587 |
| 100% |  0.292 |  0.036 |  2.570 |  1.016 |  1.121 |  1.022 |  1.127 |  2.230 |  2.482 |
| 110% |  0.003 |  0.000 |  0.507 |  0.280 |  0.229 |  0.112 |  0.393 |  0.606 |  0.443 |
| ---- | ------ |  --- 4 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  60% | 56.754 | 55.440 | 53.365 | 47.329 | 53.298 | 54.568 | 40.695 | 46.216 | 45.382 |
|  70% | 48.492 | 31.055 | 40.975 | 41.379 | 46.096 | 45.224 | 35.998 | 36.290 | 37.011 |
|  80% | 28.212 | 15.474 | 26.515 | 24.304 | 28.395 | 23.862 | 19.953 | 23.568 | 24.066 |
|  90% | 19.434 |  1.977 | 15.791 | 16.555 | 14.740 | 13.293 | 13.364 | 13.572 | 14.036 |
| 100% |  1.448 |  0.436 |  8.149 |  3.891 |  4.698 |  4.167 |  3.800 |  8.338 |  6.983 |
| 110% |  0.347 |  0.029 |  3.556 |  2.075 |  1.714 |  1.851 |  2.280 |  4.340 |  3.597 |
| 120% |  0.167 |  0.026 |  1.111 |  0.613 |  0.535 |  0.587 |  0.812 |  1.504 |  1.280 |
| 130% |  0.003 |  0.000 |  0.114 |  0.125 |  0.105 |  0.084 |  0.245 |  0.396 |  0.224 |
| 140% |  0.003 |  0.000 |  0.080 |  0.081 |  0.056 |  0.048 |  0.204 |  0.225 |  0.173 |
| 150% |  0.000 |  0.000 |  0.007 |  0.000 |  0.000 |  0.000 |  0.001 |  0.015 |  0.008 |
| 160% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.011 |  0.000 |
| ---- | ------ |  --- 5 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  80% | 50.558 | 40.979 | 49.978 | 43.146 | 50.703 | 49.095 | 36.166 | 42.514 | 43.889 |
|  90% | 40.570 | 21.871 | 39.236 | 34.371 | 34.183 | 34.659 | 27.939 | 29.174 | 33.165 |
| 100% | 24.584 | 13.959 | 23.434 | 18.242 | 20.572 | 21.305 | 14.372 | 21.539 | 19.833 |
| 110% | 13.469 |  5.539 | 13.016 | 11.449 | 14.122 | 11.795 |  9.490 | 13.317 |  9.707 |
| 120% |  8.269 |  2.054 |  6.181 |  6.446 |  5.516 |  5.438 |  5.171 |  7.400 |  5.010 |
| 130% |  4.094 |  0.145 |  1.742 |  3.241 |  2.821 |  2.553 |  2.561 |  2.814 |  2.091 |
| 140% |  1.621 |  0.013 |  0.968 |  1.426 |  1.495 |  0.418 |  1.371 |  1.259 |  1.348 |
| 150% |  0.068 |  0.000 |  0.488 |  0.245 |  0.150 |  0.110 |  0.354 |  0.609 |  0.704 |
| 160% |  0.002 |  0.000 |  0.145 |  0.068 |  0.057 |  0.037 |  0.154 |  0.245 |  0.246 |
| 170% |  0.001 |  0.000 |  0.107 |  0.026 |  0.029 |  0.019 |  0.080 |  0.189 |  0.166 |
| 180% |  0.001 |  0.000 |  0.014 |  0.005 |  0.004 |  0.001 |  0.026 |  0.040 |  0.030 |
| ---- | ------ |  --- 6 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  90% | 60.244 | 45.574 | 58.716 | 51.118 | 54.595 | 56.448 | 42.744 | 46.347 | 50.065 |
| 100% | 47.642 | 32.876 | 43.999 | 37.268 | 40.903 | 42.223 | 29.307 | 36.870 | 36.846 |
| 110% | 34.189 | 17.807 | 30.691 | 26.780 | 32.397 | 29.817 | 21.137 | 26.363 | 24.299 |
| 120% | 22.629 | 11.938 | 20.383 | 18.446 | 18.497 | 18.729 | 14.231 | 17.686 | 15.958 |
| 130% | 13.016 |  3.907 | 11.913 | 10.922 | 11.498 | 11.429 |  8.231 | 10.460 |  9.792 |
| 140% |  9.130 |  1.108 |  6.652 |  7.685 |  7.466 |  6.293 |  5.926 |  6.281 |  6.142 |
| 150% |  2.797 |  0.014 |  3.915 |  3.266 |  3.477 |  1.961 |  2.772 |  3.750 |  3.645 |
| 160% |  1.283 |  0.003 |  1.247 |  1.494 |  1.111 |  0.912 |  1.421 |  2.000 |  1.487 |
| 170% |  0.007 |  0.000 |  0.489 |  0.180 |  0.194 |  0.100 |  0.325 |  0.946 |  0.662 |
| 180% |  0.002 |  0.000 |  0.148 |  0.086 |  0.106 |  0.049 |  0.185 |  0.424 |  0.301 |
| 190% |  0.001 |  0.000 |  0.022 |  0.012 |  0.015 |  0.011 |  0.054 |  0.117 |  0.074 |
| 200% |  0.000 |  0.000 |  0.001 |  0.002 |  0.002 |  0.001 |  0.014 |  0.026 |  0.013 |
| ---- | ------ |  --- 7 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
| 100% | 64.870 | 52.838 | 63.598 | 53.849 | 58.715 | 61.342 | 43.943 | 51.614 | 54.406 |
| 110% | 53.934 | 38.221 | 51.906 | 43.436 | 50.520 | 49.201 | 34.627 | 41.911 | 42.450 |
| 120% | 42.200 | 28.308 | 39.911 | 33.993 | 37.324 | 37.621 | 26.469 | 31.884 | 31.229 |
| 130% | 30.305 | 15.648 | 29.074 | 23.774 | 26.315 | 27.016 | 17.815 | 22.849 | 22.592 |
| 140% | 23.316 |  8.907 | 18.838 | 18.630 | 19.281 | 18.177 | 13.964 | 15.654 | 15.438 |
| 150% | 14.243 |  2.723 | 12.724 | 10.602 | 12.109 |  9.844 |  8.126 | 10.609 | 10.133 |
| 160% |  7.416 |  1.308 |  6.446 |  6.207 |  5.722 |  4.886 |  4.994 |  6.330 |  6.054 |
| 170% |  3.724 |  0.201 |  2.651 |  2.830 |  2.438 |  2.056 |  2.287 |  3.956 |  2.771 |
| 180% |  1.335 |  0.016 |  1.130 |  1.268 |  1.332 |  0.737 |  1.213 |  1.940 |  1.394 |
| 190% |  0.416 |  0.001 |  0.400 |  0.609 |  0.559 |  0.279 |  0.605 |  0.960 |  0.504 |
| 200% |  0.078 |  0.000 |  0.109 |  0.272 |  0.108 |  0.066 |  0.283 |  0.320 |  0.231 |

Well, that’s a resounding “nope.”  Stamina still dominates even in this regime.  In many cases, your chance of taking a spike exceeding your total health is reduced by 10% or more (and that’s in absolute terms – in relative terms it can be as large as 40% or more).  There’s just no doubt about it – stamina is the king smoothness stat for large boss hits too.

Conclusions

I don’t think there’s any question about these results.  They provide a fairly convincing argument that stamina is your best survivability stat, hands-down, no matter what level of content you’re raiding.  And, more to the point, prove that the “common sense approach” of stacking stamina until you can survive a few boss hits and then turning to other smoothness stats is misguided, at least for survivability.

Now, I want to make one thing abundantly clear.  This data does not mean that it’s wrong to stop stacking stamina and start stacking haste at some point.  In fact, many of the best tankadins in the world do exactly that.  And they aren’t misguided about anything, they know exactly what they’re doing.

Those tanks aren’t increasing their survivability by stacking haste.  They’re increasing their DPS by sacrificing some of their survivability (i.e. stamina).  Because unlike DPS, survivability isn’t a stat that you should stack blindly without end.  Stamina will always give you more survivability, but that added survivability isn’t always the best practical benefit for your raid.

Remember, the goal of WoW is not to max out the “Survivability” stat and e-peen around in Ironforge.  It’s to kill bosses, and survivability is a means to that end.  But if you have enough survivability to regularly make it through the boss encounter without faceplanting, then more survivability doesn’t necessarily help that much.  And given our affinity for haste and tank DPS mattering a lot more than it did in previous expansions, it’s often a good call to trade some survivability for haste to help meet enrage timers.

The difference here is that these tanks know that they’re making a survivability-for-DPS trade-off when doing this.  They don’t claim that they’re doing it for improved smoothness or better survivability.  They’re very up-front about the fact that it’s for increased DPS and better overall raid performance.  And they’re also skilled enough to make that decision in an intelligent fashion.

I think in part, that’s what’s led to the zombie-like recurrence of the “get enough stamina and then stack haste for survivability” mantra.  People look up the armory of a “good” tank they know and see them gearing for haste instead of stamina, and then assume that it’s being done for the purposes of survivability.  Then they log on to forums and repeat that opinion, or even berate others for having an affinity for stamina.

But in fact, stamina really is a higher priority for survivability than anything else you could gem or enchant for.  That’s why I suggest such a high stat weight value for it in AskMrRobot and recommended that Icy Veins add a comment about its worth beyond what’s found innately on gear.

Because a beginner tankadin does not play perfectly.  Hell, I don’t play remotely perfectly and I consider myself a pretty good tankadin.  A beginner does not have that experience, and can’t be expected to intuitively know what “enough” stamina is after a handful of boss pulls.  At best they’ll be able to clearly decide they don’t have “enough” if they faceplant on every pull.   And for both of these reasons, the beginner shouldn’t be trying to dance around the razor’s edge of having barely enough stamina under perfect conditions.  They are far better served by having a little bit of a buffer – some more wiggle room for when they or their healers make a mistake.

It’s the advanced tanks that should be shedding stamina for haste, because they’re the ones that have the experience and know-how to be able to intelligently assess their situation and determine whether they have “enough” stamina for an encounter.  They can then weigh the options and decide whether sacrificing some survivability for more DPS is a net benefit to their raid.  But I think it’s hopelessly optimistic to assume that the average AskMrRobot user has the experience to accurately make those judgment calls.  And if so, that’s when they can transition from a “novice tank” to an “intermediate tank” and learn how to adjust the custom weights to suit their needs.

While the simulation and data in this post are specific to tankadins, I think that the conclusions generalize across all of the tanking classes at least somewhat.  Other classes may have different damage smoothing mechanisms and mechanics, but the effect of stamina on damage smoothing is very much the same for a Paladin as it is for a Warrior or Death Knight.  It may be a little stronger or weaker depending on their exact stamina multiplier (paladins get +25% from Guarded by the Light, but not all classes do).

But the benefits we’re seeing here are an order of magnitude stronger than those of the secondary stats, so it’s not likely to change the results significantly enough to dethrone stamina.  While I can’t speak conclusively for any of the other classes, I highly encourage other theorycrafters to consider these results in the context of their own classes and see if they don’t come to the same conclusions I have.

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

Sacréd bleu!

Posted on March 26, 2013 by Theck

The comments section of last Friday’s post hosted some interesting discussions. Wrathblood pointed out that some of the avoidance gear sets were performing about as well as the Control/Haste set, and Kihra cautioned against counting out Control/Mastery entirely. There was a lengthy discussion about whether Holy Avenger or Divine Purpose was a better choice for DPS (Holy Avenger holds a steady-state lead until somewhere around 22%-25% haste rating, but in practice the threshold is much higher on an average boss thanks to tank swaps). And I posted a short derivation explaining how Sacred Shield scales with Vengeance.

Perhaps most importantly, though, Weeby noticed I was using the wrong formula for Sacred Shield! I can’t figure out exactly how that happened – most of my formulas are rigorously tested in-game, after which I use curve-fitting in MATLAB to accurately determine the formula. In some cases, this ends up being slightly different from the tooltip, and occasionally drastically different. During beta, in fact, there was a long period of time when WoG’s tooltip was off by a noticeable amount (and when the tooltip was fixed, people reading the MMO-Champion spell diff cried loudly about a “nerf” that never happened!).

I can’t find a current data set for Sacred Shield, which means the last time we empirically tested it was in beta. My best guess at this point is that the tooltip was incorrect in beta (like WoG), so I used my empirically-determined formula. And then somewhere along the way (likely before beta ended, even), the spell formula was updated to match the tooltip, thus not triggering an entry in the MMO-Champion spell diff. That would explain why we never thought to re-check it.

There’s also the distinct possibility I just goofed up, either via a copy/paste error or something else entirely. It happens. Oops?

In any event, I did some in-game testing earlier this week to confirm the new formula. Believe it or not, the old formula was actually weaker than the new formula. Yes, we were undervaluing Sacred Shield. Rather than absorbing ~40% of a boss attack per tick like it did in the earlier model, it’s actually absorbing over 50% of a boss attack. It’s even more overpowered than the last blog post suggested.

That value will get larger for weaker bosses and smaller for harder-hitting bosses thanks to Vengeance. Note that the total amount absorbed will always be larger at higher Vengeance, but it will be a smaller percentage of a boss attack due to the base absorption value from the AP on your gear. The plot below shows how this scales with Vengeance to give you a clearer idea of how that works:

Sacred Shield absorption as a function of Vengeance. As Vengeance increases, each Sacred Shield tick absorbs a smaller percentage of a boss attack, saturating somewhere above 45% at high Vengeance.

For the mathematically-inclined, the formula for the size of a Sacred Shield absorb is

${\rm SS~Absorb} = 342.5 + 0.585\times AP$

and when normalized to the size of a boss attack, it looks like this:

$\LARGE {\rm \%~Absorb} = \frac{342.5+0.585 \times (1.1 \times (AP_0+V))}{4.1667 M V} $

where $V$ is your Vengeance AP, $AP_0$ is your character sheet AP (with Kings, but without the AP raid buff), the factor of 1.1 is for the 10% AP raid buff, and $M=0.362$ is your total mitigation factor from armor, spec, and Weakened Blows (in the gear set used for the simulations).

In today’s post, I’d like to briefly address some of the points raised in the comments and present updated data using the correct formula for Sacred Shield (SS). Since we’re only concerned with SS, I’ll be skipping the data sets that don’t use it.

Gear and Simulation Details

As before, here are the gear sets. the only notable change is that I’ve added a “C/HM” gear set, which stands for Control/HasteMastery. The idea here is to see if the synergy between haste and mastery makes a gear set that splits its attention between haste and mastery preferable to one that focuses on either in isolation. I have a more detailed simulation that does this in smaller steps along the continuum, but that will have to wait for a later date.

The stats of the gear sets we’re using are listed in the table below. Each set has 65k armor, 15k strength, and 24150 rating to distribute amongst the secondary stats. This is roughly equivalent to an average equipped ilvl of 522. For more details on the choices I’ve made, you can consult the original 5.2 Smoothness Simulations post.

|    Set: |  C/Ha |  C/Ma |  C/Av | C/Bal |  C/HM |    Ha | Avoid | Av/Mas | Mas/Av |
|     Str | 15000 | 15000 | 15000 | 15000 | 15000 | 15000 | 15000 |  15000 |  15000 |
|   Parry |  1500 |  1500 |  7500 |  4125 |  1500 |  1500 | 10825 |   7717 |   4000 |
|   Dodge |  1500 |  1500 |  7500 |  4125 |  1500 |  1500 | 10825 |   7717 |   4000 |
| Mastery |  1500 | 13500 |  1500 |  4125 |  6750 |  1500 |  1500 |   7716 |  15150 |
|     Hit |  2550 |  2550 |  2550 |  2550 |  2550 |   500 |   500 |    500 |    500 |
|     Exp |  5100 |  5100 |  5100 |  5100 |  5100 |   500 |   500 |    500 |    500 |
|   Haste | 12000 |     0 |     0 |  4125 |  6750 | 18650 |     0 |      0 |      0 |

I’m using the standard Monte-Carlo code, updated with the 5.2 mechanics. Just as last time, here’s the copy/paste summary of how the simulation works:

To better understand the data below, here’s a rough overview of how it’s generated: I run a Monte-Carlo sim that simulates 10k minutes of combat (think Simcraft, but paladin-specific and more limited in scope), making all combat rolls and logging all damage events. I take the resulting string of attacks (something like “1, 0, 0.7, 1, 0, 0, …” where 0 is an avoid (no damage), 1 is a full hit, 0.7 is a block, and so on) and do some calculations on it. I calculate the average damage intake normalized to 100% possible throughput (i.e. “1, 1, 1, 1, 1, …”), and report that in the “mean” row, representing mean damage intake (lower is better, represents better TDR). “std” is just the standard deviation of that mean as averaged over 5 attacks. “S%” is SotR uptime.

The rest of the rows are smoothing data for strings of N attacks. For now, let’s just consider the first gear column (C/Ha). I take the damage event sequence and perform a moving average on it (i.e. an N-attack moving average). I then calculate how many of those N-attack averages exceed a certain threshold of maximum throughput. So for example, if we look at a 3-attack moving average, the “70%” row tells me how many of those 3-attack averages exceed 70% of the maximum throughput. Max throughput for 3 attacks is “1, 1, 1″ or 3 normalized damage, so the 70% row tells me how many exceed 2.1 damage. And so on for 80% and 90%. Note that they’re cumulative, so if 5% of attacks exceed 90% max throughput those attacks are also being counted in the 80% and 70% rows (thus, if 17% of attacks exceed 80% max throughput, the percentage between 80% and 90% is 17%-5%=12%). I should add that the repeatability on these simulations is quite good thanks to the long integration time – results usually fluctuate by less than +/- 0.1% (absolute, i.e. 5% +/- 0.1%).

I do this for a bunch of different gear sets, i.e. “C/Ha” for Control/Haste, etc. The first table lists all of the gear configurations so you get a rough idea of what they look like. They’re roughly equivalent to stats in ilvl 496 gear.

The code can be found in the matlabadin repository, as usual. The two files in particular are pally_mc.m and pally_mc_smooth.m.

SotR Spam Queue (“S”)

First, the data for the simple “S” queue. I’m going to limit the commentary on this one, since it’s the least relevant.

| Set: |   C/Ha |   C/Ma |   C/Av |  C/Bal |   C/HM |     Ha |  Avoid | Av/Mas | Mas/Av |
|   S% |  0.522 |  0.411 |  0.419 |  0.452 |  0.472 |  0.499 |  0.366 |  0.362 |  0.357 |
| mean |  0.346 |  0.335 |  0.312 |  0.328 |  0.327 |  0.349 |  0.284 |  0.307 |  0.311 |
|  std |  0.132 |  0.129 |  0.146 |  0.138 |  0.126 |  0.139 |  0.152 |  0.151 |  0.141 |
| ---- | ------ |  --- 2 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  40% | 41.366 | 43.036 | 36.658 | 41.269 | 41.141 | 41.757 | 32.354 | 36.151 | 39.462 |
|  50% | 32.233 | 25.217 | 28.012 | 31.354 | 18.081 | 32.616 | 24.155 | 21.041 | 23.516 |
|  60% |  9.434 | 13.609 | 11.528 | 11.858 | 10.959 | 10.666 | 11.094 | 13.228 | 11.384 |
|  70% |  8.817 | 11.264 | 11.136 | 10.664 |  9.843 | 10.118 | 10.809 | 12.056 | 10.585 |
|  80% |  0.089 |  1.872 |  0.319 |  0.500 |  0.494 |  0.026 |  0.219 |  1.847 |  1.229 |
|  90% |  0.089 |  1.159 |  0.319 |  0.500 |  0.318 |  0.026 |  0.219 |  0.835 |  0.745 |
| ---- | ------ |  --- 3 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  40% | 35.922 | 34.023 | 30.145 | 32.932 | 32.815 | 36.499 | 26.374 | 30.640 | 28.455 |
|  50% | 22.878 | 18.430 | 17.260 | 16.832 | 12.846 | 23.620 | 13.907 | 14.291 | 16.981 |
|  60% |  7.218 |  9.698 |  7.788 |  8.899 |  7.289 |  8.808 |  7.042 |  8.915 |  9.394 |
|  70% |  0.907 |  3.706 |  2.283 |  2.348 |  2.160 |  2.193 |  2.360 |  3.900 |  3.829 |
|  80% |  0.470 |  0.944 |  1.183 |  1.065 |  0.882 |  1.171 |  1.261 |  1.669 |  1.077 |
|  90% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |
| ---- | ------ |  --- 4 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  40% | 38.944 | 32.548 | 29.802 | 33.318 | 35.580 | 39.165 | 24.885 | 29.567 | 29.604 |
|  50% | 17.340 | 14.978 | 15.669 | 17.961 |  7.437 | 18.319 | 12.282 | 12.482 | 12.271 |
|  60% |  1.775 |  4.072 |  4.417 |  3.777 |  2.959 |  4.018 |  4.490 |  6.354 |  4.208 |
|  70% |  0.026 |  0.656 |  0.565 |  0.493 |  0.256 |  0.668 |  1.000 |  1.439 |  1.046 |
|  80% |  0.000 |  0.085 |  0.029 |  0.025 |  0.013 |  0.003 |  0.025 |  0.145 |  0.085 |
|  90% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |
| ---- | ------ |  --- 5 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  40% | 36.257 | 34.763 | 29.263 | 34.727 | 27.357 | 36.922 | 23.094 | 26.475 | 26.437 |
|  50% | 15.495 |  8.955 | 13.362 |  9.598 |  7.199 | 17.292 | 10.827 | 10.570 |  9.221 |
|  60% |  2.303 |  1.153 |  2.010 |  2.219 |  0.243 |  3.208 |  1.883 |  2.046 |  1.828 |
|  70% |  0.000 |  0.000 |  0.168 |  0.001 |  0.000 |  0.373 |  0.371 |  0.380 |  0.330 |
|  80% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |
|  90% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |
| ---- | ------ |  --- 6 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  40% | 33.896 | 33.016 | 26.627 | 31.643 | 28.598 | 35.080 | 21.098 | 27.303 | 24.229 |
|  50% |  9.094 |  9.050 |  8.245 | 10.490 |  5.793 | 10.828 |  6.420 |  8.540 |  7.058 |
|  60% |  0.039 |  0.380 |  0.382 |  0.367 |  0.121 |  0.413 |  0.870 |  1.448 |  1.165 |
|  70% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.019 |  0.068 |  0.132 |  0.081 |
|  80% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.010 |  0.000 |
|  90% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |
| ---- | ------ |  --- 7 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  40% | 32.519 | 29.918 | 24.762 | 29.278 | 25.296 | 33.933 | 19.208 | 24.663 | 24.000 |
|  50% |  8.412 |  7.123 |  7.436 |  6.395 |  4.647 | 10.383 |  5.726 |  7.341 |  5.930 |
|  60% |  0.379 |  0.267 |  0.692 |  0.500 |  0.224 |  1.018 |  0.673 |  1.053 |  0.380 |
|  70% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.012 |  0.028 |  0.024 |  0.020 |
|  80% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |
|  90% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |

This data looks more or less the same as last time. Control/Haste commands a decent lead for larger spikes, but it lags a little at the lowest spike levels. There are a few subcategories where Control/Mastery ekes out a decent lead (especially at the 50% threshold), but overall it’s just not a compelling alternative. Control/Avoidance and Control/Balance both tend to lag a little bit, though sometimes show an advantage in the 40%-50% categories. That said, the 40% category is dangling dangerously close to “throughput damage” levels, so it’s not clear that it (or for that matter the 50% category) has a lot of relevance. Mel hesitates to even call these events “spikes.” It’s really the upper end of the distribution we care most about, and that is almost always dominated by haste.

The avoidance sets are actually fairly competitive with the “lazy” queue, because SotR isn’t being timed intelligently, making it a more stochastic process. And avoidance wrote the book on stochastic processes, so it gets a bit of a leg up here. We’ll see that lead erode in the shifting queues. But for the tank that’s got SotR macro-ed to CS, they’re not bad options.

The new Control/HasteMastery set is sort of lackluster for short strings of attacks, but competes rather well in the 4-attack and higher categories. We’ll talk more about that after we see the shifting queue data. For now, we’ll just say that for the novice tank, a mix of haste and mastery seems to give you a reasonable middle ground between the skill-dependent C/Ha set and the less skill-dependent C/Ma set, and in some cases improvements over both.

1-Attack Shifting Queue (“SH1″)

Next, let’s look at the SH1 data:

| Set: |   C/Ha |   C/Ma |   C/Av |  C/Bal |   C/HM |     Ha |  Avoid | Av/Mas | Mas/Av |
|   S% |  0.523 |  0.410 |  0.419 |  0.452 |  0.471 |  0.499 |  0.366 |  0.363 |  0.357 |
| mean |  0.345 |  0.337 |  0.312 |  0.328 |  0.330 |  0.349 |  0.284 |  0.307 |  0.312 |
|  std |  0.126 |  0.121 |  0.136 |  0.128 |  0.118 |  0.129 |  0.140 |  0.139 |  0.129 |
| ---- | ------ |  --- 2 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  40% | 41.738 | 49.026 | 37.940 | 43.039 | 42.781 | 42.377 | 33.252 | 38.972 | 43.496 |
|  50% | 31.526 | 24.384 | 27.829 | 31.248 | 17.568 | 31.818 | 23.667 | 19.525 | 21.765 |
|  60% |  7.751 | 10.142 |  8.998 |  9.376 |  9.169 |  8.591 |  8.746 | 11.277 |  7.569 |
|  70% |  7.688 |  7.042 |  8.701 |  7.659 |  8.365 |  8.570 |  8.502 |  9.418 |  7.150 |
|  80% |  0.001 |  0.404 |  0.004 |  0.006 |  0.044 |  0.000 |  0.007 |  0.500 |  0.305 |
|  90% |  0.000 |  0.060 |  0.004 |  0.006 |  0.000 |  0.000 |  0.007 |  0.075 |  0.062 |
| ---- | ------ |  --- 3 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  40% | 35.780 | 31.965 | 29.641 | 33.155 | 34.977 | 37.087 | 25.532 | 31.383 | 23.136 |
|  50% | 21.975 | 11.001 | 15.303 | 13.320 |  8.694 | 23.214 | 12.105 |  8.026 | 10.698 |
|  60% |  4.793 |  5.884 |  3.787 |  4.630 |  3.644 |  5.727 |  3.479 |  4.535 |  5.831 |
|  70% |  0.264 |  2.927 |  1.021 |  1.199 |  1.092 |  0.761 |  1.174 |  2.392 |  2.771 |
|  80% |  0.003 |  0.525 |  0.283 |  0.251 |  0.142 |  0.185 |  0.439 |  0.667 |  0.553 |
|  90% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |
| ---- | ------ |  --- 4 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  40% | 38.255 | 31.666 | 29.111 | 31.769 | 33.885 | 39.435 | 23.317 | 27.038 | 28.159 |
|  50% | 14.918 | 14.325 | 13.556 | 15.606 |  5.082 | 15.617 | 10.277 | 10.315 | 11.446 |
|  60% |  0.187 |  2.530 |  1.719 |  1.176 |  1.392 |  0.900 |  2.011 |  3.825 |  2.329 |
|  70% |  0.002 |  0.117 |  0.152 |  0.135 |  0.092 |  0.158 |  0.320 |  0.432 |  0.265 |
|  80% |  0.000 |  0.005 |  0.000 |  0.000 |  0.000 |  0.000 |  0.001 |  0.012 |  0.007 |
|  90% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |
| ---- | ------ |  --- 5 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  40% | 34.840 | 34.111 | 27.890 | 32.981 | 25.228 | 36.018 | 21.321 | 24.834 | 26.277 |
|  50% | 12.891 |  7.044 | 10.236 |  7.902 |  6.078 | 14.324 |  8.095 |  8.245 |  6.842 |
|  60% |  2.020 |  0.962 |  1.463 |  1.738 |  0.288 |  2.421 |  1.161 |  0.921 |  1.204 |
|  70% |  0.002 |  0.137 |  0.076 |  0.033 |  0.023 |  0.089 |  0.150 |  0.201 |  0.213 |
|  80% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |
|  90% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |
| ---- | ------ |  --- 6 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  40% | 32.965 | 29.506 | 25.014 | 29.625 | 26.553 | 34.328 | 19.117 | 25.345 | 21.657 |
|  50% |  7.612 |  7.178 |  6.456 |  7.908 |  4.876 |  8.790 |  4.860 |  6.035 |  5.817 |
|  60% |  0.004 |  0.619 |  0.271 |  0.212 |  0.104 |  0.112 |  0.429 |  0.915 |  0.783 |
|  70% |  0.000 |  0.002 |  0.002 |  0.001 |  0.001 |  0.006 |  0.023 |  0.038 |  0.013 |
|  80% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.001 |  0.000 |
|  90% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |
| ---- | ------ |  --- 7 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  40% | 31.488 | 28.400 | 23.381 | 27.868 | 25.298 | 33.273 | 17.354 | 22.894 | 21.964 |
|  50% |  7.497 |  4.988 |  5.507 |  3.997 |  3.131 |  8.766 |  4.176 |  5.414 |  4.364 |
|  60% |  0.084 |  0.094 |  0.338 |  0.159 |  0.084 |  0.395 |  0.365 |  0.464 |  0.192 |
|  70% |  0.000 |  0.003 |  0.000 |  0.001 |  0.000 |  0.004 |  0.012 |  0.015 |  0.013 |
|  80% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |
|  90% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |

C/Ha still does very well at suppressing the highest spikes, but trails C/Ma for long sequences of attacks and for smaller (40%-50%) spikes. C/Av and C/Bal both give pretty good showings as well, occasionally beating out both of the frontrunners. Even the avoidance sets are pretty good, to be honest. Sacred Shield seems to be the great equalizer in that regard – the synergy between avoidance and absorbs gives enough of a boost to the avoidance gear sets to make them competitive.

Avoidance sets tend to excel for long strings of attacks (again, owing to their stochastic nature) but trail in the short-attack categories. For many heroic bosses, this is a liability (example: Jin’rokh hits for around 330k on 25H without SotR active, making 3- to 4- attack strings worth considering).

It’s interesting to note that the newcomer, C/HM, often beats both the C/Ha and C/Ma sets. C/HM seems to amplify many of the benefits of the C/Ma gear set. It suppresses 40%-50% spikes more effectively and significantly improves spike suppression in the higher-threshold categories. While it generally doesn’t beat C/Ha in those higher categories, it doesn’t lose by that much either, and we’re comparing numbers that are already pretty small. If you have less than a 0.1% chance for an event to occur, it may not matter very much whether it’s 0.05% or 0.02%.

It’s also worth noting that it handily beats out all of the avoidance sets. While the Avoidance sets may show situational benefits over C/Ha or C/Ma alone, they never beat C/HM by a statistically significant margin.

With that in mind, it’s arguable that the C/HM gear set is the most balanced set to choose for overall survivability.

2-Attack Shifting Queue (“SH2″)

And finally, here’s the data for the SH2 queue:

| Set: |   C/Ha |   C/Ma |   C/Av |  C/Bal |   C/HM |     Ha |  Avoid | Av/Mas | Mas/Av |
|   S% |  0.523 |  0.410 |  0.420 |  0.452 |  0.471 |  0.498 |  0.367 |  0.363 |  0.357 |
| mean |  0.345 |  0.336 |  0.312 |  0.328 |  0.328 |  0.349 |  0.285 |  0.305 |  0.311 |
|  std |  0.132 |  0.128 |  0.146 |  0.138 |  0.126 |  0.139 |  0.152 |  0.150 |  0.139 |
| ---- | ------ |  --- 2 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  40% | 41.276 | 44.008 | 36.736 | 41.243 | 41.284 | 41.878 | 32.485 | 36.302 | 40.097 |
|  50% | 32.197 | 25.305 | 28.077 | 31.352 | 18.239 | 32.639 | 24.245 | 20.839 | 23.389 |
|  60% |  9.422 | 13.195 | 11.552 | 11.818 | 11.106 | 10.779 | 11.176 | 13.012 | 10.946 |
|  70% |  8.795 | 10.712 | 11.168 | 10.620 | 10.030 | 10.223 | 10.874 | 11.740 | 10.163 |
|  80% |  0.093 |  1.708 |  0.324 |  0.483 |  0.487 |  0.031 |  0.229 |  1.665 |  1.144 |
|  90% |  0.093 |  1.081 |  0.324 |  0.483 |  0.309 |  0.031 |  0.229 |  0.749 |  0.694 |
| ---- | ------ |  --- 3 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  40% | 35.992 | 34.321 | 30.324 | 32.950 | 33.285 | 36.708 | 26.564 | 30.852 | 28.321 |
|  50% | 22.890 | 18.336 | 17.386 | 16.981 | 13.163 | 23.848 | 14.039 | 14.034 | 16.854 |
|  60% |  7.212 |  9.297 |  7.907 |  8.964 |  7.378 |  8.839 |  7.128 |  8.207 |  8.951 |
|  70% |  0.883 |  3.096 |  2.184 |  2.186 |  1.970 |  2.100 |  2.283 |  2.997 |  3.307 |
|  80% |  0.453 |  0.940 |  1.200 |  1.083 |  0.831 |  1.122 |  1.272 |  1.294 |  1.001 |
|  90% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |
| ---- | ------ |  --- 4 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  40% | 38.882 | 33.666 | 30.039 | 33.515 | 36.163 | 39.326 | 25.134 | 30.070 | 30.471 |
|  50% | 17.167 | 14.259 | 15.634 | 17.740 |  7.362 | 18.552 | 12.218 | 11.486 | 11.708 |
|  60% |  1.726 |  3.666 |  4.570 |  3.766 |  2.851 |  3.873 |  4.574 |  5.472 |  3.838 |
|  70% |  0.013 |  0.409 |  0.527 |  0.408 |  0.228 |  0.616 |  0.979 |  1.043 |  0.762 |
|  80% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.003 |  0.001 |
|  90% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |
| ---- | ------ |  --- 5 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  40% | 36.049 | 34.672 | 29.295 | 34.609 | 27.601 | 37.116 | 23.108 | 25.838 | 26.217 |
|  50% | 15.356 |  8.622 | 13.507 |  9.452 |  7.314 | 17.272 | 10.928 |  9.812 |  8.924 |
|  60% |  2.227 |  1.034 |  2.024 |  2.229 |  0.236 |  3.210 |  1.843 |  1.809 |  1.590 |
|  70% |  0.001 |  0.056 |  0.196 |  0.004 |  0.001 |  0.340 |  0.373 |  0.328 |  0.306 |
|  80% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |
|  90% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |
| ---- | ------ |  --- 6 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  40% | 33.788 | 32.789 | 26.668 | 31.640 | 28.974 | 35.172 | 21.238 | 26.753 | 23.933 |
|  50% |  8.891 |  8.671 |  8.309 | 10.287 |  6.049 | 10.899 |  6.364 |  7.845 |  6.687 |
|  60% |  0.033 |  0.490 |  0.388 |  0.358 |  0.118 |  0.394 |  0.834 |  1.344 |  1.054 |
|  70% |  0.000 |  0.003 |  0.001 |  0.002 |  0.000 |  0.022 |  0.066 |  0.101 |  0.040 |
|  80% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |
|  90% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |
| ---- | ------ |  --- 7 | Attack | Moving | Avg.-- | ------ | ------ | ------ | ------ |
|  40% | 32.257 | 30.012 | 24.923 | 29.168 | 25.671 | 33.953 | 19.320 | 24.067 | 23.649 |
|  50% |  8.274 |  6.811 |  7.591 |  6.405 |  4.959 | 10.420 |  5.678 |  6.757 |  5.581 |
|  60% |  0.393 |  0.260 |  0.722 |  0.496 |  0.256 |  0.978 |  0.657 |  0.940 |  0.341 |
|  70% |  0.000 |  0.000 |  0.001 |  0.000 |  0.000 |  0.013 |  0.027 |  0.029 |  0.019 |
|  80% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |
|  90% |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |  0.000 |

The data here isn’t much different than the SH1 queue. We still see many of the same patterns, including the strength of C/HM overall. C/Ha performs a little less effectively with SH2 than with SH1, while C/Ma performs a little better, just as before. I’m not sure which is the more accurate model for a player, to be honest – do you react after one big hit, or does it take two of them before you notice the dip in your health bar?

Avoidance

First, let’s talk about avoidance. I think Wrathblood was right, in that I wasn’t giving it a fair shake. It does generally compete fairly effectively with haste, and shows a commanding lead in the long-attack and low-threshold categories. That said, I also don’t think it’s fair to toss out the high-spike categories as irrelevant. Certainly the difference between values that are less than 0.1% are of questionable relevance, but avoidance loses much more ground than that in many cases. We’re often comparing values like 0.001% to 0.3%, or 0.01% to 1%, which is well above the level of statistical relevance. One essentially eliminates that category, while the other still gives you a fair probability of seeing that sort of string in a given raid night.

Overall, I don’t think any of the Avoidance sets are that attractive when compared to the control sets. They tend to lead in categories that fall into the realm of “throughput damage” – TDR, long strings of attacks, and weaker spikes. If throughput is a problem for a given raid group, that may be a situation where switching to an avoidance set is warranted, but I don’t think that’s an accurate representation of most heroic raid groups. And given that throughput is much lower in normal-modes, I’m not sure it’s that relevant there either.

It may also be worth mentioning that one of the traditional draws of the avoidance paradigm was its passiveness. The thought was that a beginner raider might have an easier time with an avoidance set because it’s less dependent on timing their Active Mitigation. But much of the power that the avoidance gear sets gained since 5.2 is caused by Grand Crusader. So while a sloppy player may still do better with an avoidance set than with a haste or mastery gear set, the lead may not be as large as it was previously.

Don’t Count Mastery Out Yet!

Khira’s comment about the Control/Mastery gear set is worth considering as well. For a large and predictable boss attack C/Ma gives you the most on-demand mitigation to throw at that effect. And there are a lot of bosses that have this sort of effect in Tier 15. One could reasonably assume that by blunting that large special attack, you get the smoothest damage profile. Right?

Well, not necessarily. Certainly it gives you the lowest chance of dying from that special attack. But it isn’t necessarily the best overall. This is a case of local and global minimization problems – blunting the big attack may be a local minimum, but not the global minimum. The boss attacks that bookend the special attack matter, and those can change the outcome. It’s easy to imagine that getting 60% mitigation on the boss special and one melee attack (immediately before or after) from a buffed C/Ma SotR may not be as effective as covering the special and 2-3 attacks before and/or after with a 45% SotR from a haste-stacked set. It’s harder to do that amount of HP pooling without haste (or a cooldown like Holy Avenger).

Also note that there are ways to artificially improve mastery on-demand, mainly trinkets. Both of my trinkets have an on-use mastery effect right now, and both are on a one-minute cooldown. That means that I have a lot of on-demand mastery at my disposal already, so I can have large coverage uptime via haste and large mitigation from SotR at the same time, in the same gear set. There aren’t any tanking trinkets with on-use haste that I’m aware of – most of them seem to be on-equip proc effects (this is also another point in Holy Avenger’s favor, by the way – SotR isn’t recalculated on cast, so if you use a mastery trinket, you get to keep the bonus mitigation for as long as you can keep SotR refreshed, often up to 30 seconds).

There’s also the concept of “minimally sufficient cooldowns” to consider. Mel talked about this briefly a long long time ago, and I would love nothing more than to convince him to come out of the woodwork and talk about it again sometime. But the short version is that extra mitigation above what you need to survive the attack, while helpful, isn’t always necessary. This is the same logic that goes into his rationalization for haste over mastery: once SotR is large enough to make a dangerous attack less dangerous, making that SotR larger is worth less than simply getting more of them to spread around. SotR’s base mitigation is pretty high already, so it’s not clear that buffing it from 45% to 60% is always going to be a net gain. Sometimes it will be, heroic Sha of Fear being one particular example that stands out. But I think it will always come down to the details of a specific fight, namely whether a 45% SotR is a “sufficient” cooldown to survive the burst or not.

Conclusions

The real surprise in this data was the performance of the C/HM set. We’d expect that such a set would lie on a rough linear interpolation between the C/Ha and C/Ma data. But the strong synergy between haste and mastery throws a wrench into the works, creating a set that can out-perform both of those sets in many cases. It isn’t always as good as C/Ha in suppressing the largest spikes, but it’s rarely far behind, and to be fair, it wins in that category almost as much as it loses. The real benefit comes from its strong suppression of mid-range spikes, doing a better job at suppressing spikes that fall just below the peak of the distribution. And for longer strings of attacks, it has a very strong effect on the low-end spikes in the 40%-50% range.

The appealing part of this is that you’re getting broad-spectrum suppression without giving up very much at the high end. Avoidance performs much the same way, but does it less efficiently, permitting a higher number of large spikes. C/HM gives you the same effect at a fraction of the cost. And to boot, it should give you more DPS thanks to the haste stacking going on.

What does this mean for our gearing choices? Tanks at the bleeding edge may continue to go haste. Both for the DPS boost on certain fights and because it still does the best job of suppressing the highest spikes. They’re making a careful and calculated survivability-for-DPS trade-off by doing that. They’re mentally categorizing 40% and 50% “spikes” as throughput that their healers can keep up with, and for a guild clearing heroics that’s a pretty safe bet. So they focus their attention on eliminating the spikes that will cause their healers to panic, and get a nice DPS boost to help beat those enrage timers.

For players that are not on the bleeding edge – for example, players still progressing towards a normal-mode Lei Shen kill – the situation is more varied. You’re presented with a lot of gearing options, and to be honest, none of them are terrible. You can make it work with an avoidance gear set, even if it isn’t really optimal. I’d argue that the only real mistake you can make is to not take Sacred Shield. Or gem spirit, that would be bad too.

But there does seem to be a noticeable advantage to focusing on haste and mastery. The C/Av, C/Bal, and C/HM data sets show that while having some avoidance isn’t going to kill you, it’s also less effective than channeling that itemization into haste and mastery. So unfortunately, I think we’re back to the paradigm of marginalizing avoidance and trying to grab as much hit/exp/haste/mastery gear as possible.

Of course, if an item is a big upgrade, that’s a different story – the raw survivability gained by jumping 20 ilvls is going to trump stat allocation most of the time. A 522 dodge/mastery item will almost always be preferable to a 496 haste/mastery item, and potentially even a 509 haste/mastery item. But I’d argue that, for example, a thunderforged item with worse itemization may not always beat a non-thunderforged item with better itemization. This is particularly relevant to our choices of chest armor, since the T15 Retribution chest is perfectly-itemized and none of the off-set tanking options are. And dodge/parry items are probably still at the bottom of the pile, but that’s not news.

Coincidentally, the stat weights I provided AskMrRobot are already well-suited for a haste/mastery paradigm. For example, the Control/Haste preset gives haste a value of 1.0 and mastery a value of 0.9, while dodge and parry drop to 0.5 each. It looks like they’ve tweaked the mastery value down to 0.8 (and similarly for haste in the Control/Mastery preset), but that still should promote a decent balance of haste and mastery. Based on the data in this blog post, I think you could argue that mastery could be bumped back up to 0.9.

You could ask yourself whether there’s an ideal balance of haste and mastery to be had. In the C/HM set, we split the itemization equally between the two stats. In a future blog post, I’ll show data for a larger continuum of states between full haste and full mastery so we can see how the results change as we go from one extreme to the other.

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

Is Nothing Sacred?

Posted on March 22, 2013 by Theck

I’ve been hinting all week that there was some big news coming up regarding our gearing choices.  If you’ve followed the last two rounds of smoothness simulations, it looks an awful lot like Control/Mastery is the solid winner.  To put some numbers to that thought, let’s look at a side-by-side comparison of the queues:

         |       Control/Mastery       |        Control/Haste
| Queue: |       S |     SH1 |     SH2 |       S |     SH1 |     SH2 |
|     S% |  0.4108 |  0.4102 |  0.4105 |  0.5225 |  0.5222 |  0.5225 |
|   mean |  0.5412 |  0.5416 |  0.5422 |  0.6003 |  0.6013 |  0.6005 |
|    std |  0.1451 |  0.1328 |  0.1252 |  0.1481 |  0.1344 |  0.1425 |
| ------ |   --- 2 |  Attack |  Moving | Average |  ------ |  ------ |
|    60% | 42.2155 | 46.5763 | 42.8827 | 46.3508 | 47.4428 | 45.8948 |
|    70% | 21.9353 | 17.4630 | 19.5302 | 40.6535 | 43.3518 | 40.3810 |
|    80% | 21.9353 | 17.4630 | 19.5302 | 14.5957 | 10.0767 | 14.1655 |
|    90% | 10.2748 |  5.5675 |  8.4910 |  9.7813 |  4.4400 |  9.4358 |
| ------ |   --- 3 |  Attack |  Moving | Average |  ------ |  ------ |
|    60% | 32.6512 | 27.6415 | 33.6860 | 53.6503 | 53.9720 | 54.0338 |
|    70% | 18.2035 | 13.2302 | 13.8877 | 36.9320 | 36.7185 | 36.8463 |
|    80% |  7.4228 |  4.3803 |  1.7488 | 15.0675 |  7.4773 | 14.6283 |
|    90% |  2.7748 |  1.2550 |  0.6620 |  1.2695 |  0.4752 |  0.0010 |
| ------ |   --- 4 |  Attack |  Moving | Average |  ------ |  ------ |
|    60% | 33.8680 | 31.6200 | 31.6953 | 53.7005 | 52.9335 | 55.2110 |
|    70% | 12.4778 |  8.6483 |  4.0650 | 32.1685 | 26.9200 | 32.0120 |
|    80% |  5.2785 |  3.4120 |  1.3058 |  3.3473 |  2.0720 |  0.0050 |
|    90% |  1.2040 |  0.7582 |  0.2240 |  0.0000 |  0.0697 |  0.0000 | 
| ------ |   --- 5 |  Attack |  Moving | Average |  ------ |  ------ |
|    60% | 39.2205 | 36.6190 | 35.4823 | 55.3028 | 55.8280 | 56.5597 |
|    70% | 10.5500 |  8.6173 |  6.9608 | 28.5143 | 25.6930 | 26.8380 |
|    80% |  1.4735 |  1.3350 |  0.3348 |  8.8370 |  5.0570 |  6.9102 |
|    90% |  0.0000 |  0.0425 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |
| ------ |   --- 6 |  Attack |  Moving | Average |  ------ |  ------ |
|    60% | 35.7910 | 32.5177 | 32.3367 | 54.0813 | 56.5700 | 54.7773 |
|    70% | 11.0220 |  8.3745 |  7.3345 | 24.1095 | 23.5930 | 22.9925 |
|    80% |  0.0000 |  0.1320 |  0.0105 |  4.2360 |  2.4580 |  3.3653 |
|    90% |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |
| ------ |   --- 7 |  Attack |  Moving | Average |  ------ |  ------ |
|    60% | 32.2383 | 28.7430 | 29.3895 | 52.9763 | 54.9205 | 53.4872 |
|    70% |  9.6973 |  7.1182 |  4.8477 | 22.5190 | 20.2357 | 21.5467 |
|    80% |  0.8415 |  0.5030 |  0.2890 |  3.7915 |  2.0220 |  2.8915 |
|    90% |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |

Control/Haste wins the race to eliminating 90% spikes, and generally dominates that category.  But that’s mostly relevant for 2- to 4-attack spikes; beyond that point Control/Mastery catches up and both gear sets eliminate the category.  And C/Ha is miserably behind C/Ma in 70% and 80% spikes, and takes 10% more damage.  It’s such a significant difference that you can even see it in the damage distribution plots.  The first one below is for C/Ma with an SH2 rotation and a 5-attack moving average, the second is for C/Ha with SH1:

C/Ma SH2

Control/Mastery gear set, SH2 rotation.

C/Ha SH1

Control/Haste gear set, SH1 rotation.

Side by side like this, you can definitely see the difference.  C/Ha permits far more events above the 80% threshold, and has a larger skew towards the higher damage ranges.  C/Ma has much less skew, a lower mean, and chops off the high events much more effectively. Based just on the performance of the shifting queues, it’s not just the winner – C/Ma has taken C/Ha out back, beat it up a little, and kicked it while it’s down.

Talent Show

However, haste has one more trick up it’s sleeve.  When I wrote these simulations initially, I intentionally avoided adding any talent-based features.  The concept of talents was that they are supposed to be modular, and thus I couldn’t count on any given paladin taking any given talent.  This is also good for me, because it limits the number of configurations I needed to worry about – having to simulate different numbers for Execution Sentence healing vs. Light’s Hammer healing vs. Holy Prism healing, for example, would be a pain in the ass.

The L75 talents are a bit more relevant, as you could imagine Divine Purpose giving very different results than Holy Avenger.  I hope to get around to adding those talents some day so we can perform a realistic comparison of them, but I don’t think they will affect a player’s choice of gear very much.  Both should emphasize hit and expertise, both should favor haste and mastery, and your choice of haste vs. mastery is likely based more around play style than the small variations in smoothness each L75 talent will cause.

But there’s one tier of talents that hasn’t really panned out for protection.  Our L45 talent choices are heavily skewed – Selfless Healer and Eternal Flame simply cannot keep up with the sheer mitigative power of Sacred Shield.  I do know paladins that take the first two talents, but it’s a small minority.  And frankly, the rationalizations they give for making those choices don’t line up with my understanding of how tanks die or what prevents those deaths.

Since the vast majority of paladins are taking Sacred Shield, it seems reasonable to assume that it will be present, which we haven’t done in any of the simulations up to this point.  And that’s a big deal, because Sacred Shield scales. Oh does it scale.  It scales a lot, and not uniformly either.  Stacking mastery to the sky has almost no effect on Sacred Shield, and strictly zero effect if we’re only considering the spells characteristics.  But it scales very well (linearly, in fact) with haste, because we get more absorption bubbles and we get them faster.  It also scales with avoidance, because avoided attacks extend the average lifetime of the absorption bubbles, making each more effective.  We saw a similar effect with warriors and Shield Barrier usage, because it’s the same principle at work.

And this matters, because the haste variations between gears sets are huge.  The Control/Mastery set has 0% melee haste and the baseline 15.5% spell haste we get from Seal of Insight and the raid-wide spell haste buff.  The Control/Haste set has 28.24% melee haste and a whopping 48.11% spell haste.  In the C/Ma gear set we’re getting a Sacred Shield absorb bubble every 5.19 seconds.  The C/Ha gear set knocks that down to 4.05 seconds.

And these Sacred Shield absorbs aren’t anything to sneeze at.  To give you some idea of the magnitudes we’re talking about, the raw boss DPS I’m using is 310k, or 465k swings every 1.5 seconds.  Armor and other passive mitigation effects knock that down to a hair over 168k damage per swing as registered in the combat log.  In the steady state, that gives us 111.6k Vengeance attack power, or a total of about 156k AP.  With that much AP, each Sacred Shield bubble ends up absorbing about 67k, or ~40% of a boss swing.  That’s better than a block, and almost like getting a free SotR applied to one boss swing.  And the haste gear set lets you do that 20% more often.

So if we’re going to make a truly fair comparison between C/Ha and C/Ma, or any of the other gear sets for that matter, we should really be including Sacred Shield in the analysis.  At the same time that I added the shifting queues to the code, I finally implemented Sacred Shield as well.  And the results were fairly surprising.  Let’s take a look.

Gear and Simulation Details

First, the obligatory background information.  If you’ve been keeping up with these smoothness simulations, you can probably skip this section.  I forgot to include it earlier this week and got some questions about it, so I figured I should just keep including it.

The stats of the gear sets we’re using are listed in the table below.  Each set has 65k armor, 15k strength, and 24150 rating to distribute amongst the secondary stats.  This is roughly equivalent to an average equipped ilvl of 522.  For more details on the choices I’ve made, you can consult the original 5.2 Smoothness Simulations post.

|    Set: |  C/Ha |  C/Ma |  C/Av | C/Bal |    Ha | Avoid | Av/Mas | Mas/Av |
|     Str | 15000 | 15000 | 15000 | 15000 | 15000 | 15000 |  15000 |  15000 |
|   Parry |  1500 |  1500 |  7500 |  4125 |  1500 | 10825 |   7717 |   4000 |
|   Dodge |  1500 |  1500 |  7500 |  4125 |  1500 | 10825 |   7717 |   4000 |
| Mastery |  1500 | 13500 |  1500 |  4125 |  1500 |  1500 |   7716 |  15150 |
|     Hit |  2550 |  2550 |  2550 |  2550 |   500 |   500 |    500 |    500 |
|     Exp |  5100 |  5100 |  5100 |  5100 |   500 |   500 |    500 |    500 |
|   Haste | 12000 |     0 |     0 |  4125 | 18650 |     0 |      0 |      0 |

I’m using the standard Monte-Carlo code, updated with the 5.2 mechanics.  Just as last time, here’s the copy/paste summary of how the simulation works:

To better understand the data below, here’s a rough overview of how it’s generated: I run a Monte-Carlo sim that simulates 10k minutes of combat (think Simcraft, but paladin-specific and more limited in scope), making all combat rolls and logging all damage events.  I take the resulting string of attacks (something like “1, 0, 0.7, 1, 0, 0, …” where 0 is an avoid (no damage), 1 is a full hit, 0.7 is a block, and so on) and do some calculations on it.  I calculate the average damage intake normalized to 100% possible throughput (i.e. “1, 1, 1, 1, 1, …”), and report that in the “mean” row, representing mean damage intake (lower is better, represents better TDR).  “std” is just the standard deviation of that mean as averaged over 5 attacks.  “S%” is SotR uptime.

The rest of the rows are smoothing data for strings of N attacks.  For now, let’s just consider the first gear column (C/Ha).  I take the damage event sequence and perform a moving average on it (i.e. an N-attack moving average).  I then calculate how many of those N-attack averages exceed a certain threshold of maximum throughput.  So for example, if we look at a 3-attack moving average, the “70%” row tells me how many of those 3-attack averages exceed 70% of the maximum throughput.  Max throughput for 3 attacks is “1, 1, 1″ or 3 normalized damage, so the 70% row tells me how many exceed 2.1 damage.  And so on for 80% and 90%.  Note that they’re cumulative, so if 5% of attacks exceed 90% max throughput those attacks are also being counted in the 80% and 70% rows (thus, if 17% of attacks exceed 80% max throughput, the percentage between 80% and 90% is 17%-5%=12%).  I should add that the repeatability on these simulations is quite good thanks to the long integration time – results usually fluctuate by less than +/- 0.1% (absolute, i.e. 5% +/- 0.1%).

I do this for a bunch of different gear sets, i.e. “C/Ha” for Control/Haste, etc.  The first table lists all of the gear configurations so you get a rough idea of what they look like.  They’re roughly equivalent to stats in ilvl 496 gear.

The code can be found in the matlabadin repository, as usual.  The two files in particular are pally_mc.m and pally_mc_smooth.m.

Results – Simple Shield of the Righteous Spam

First, let’s look at the data for the simple “S” queue and with Sacred Shield disabled.   This won’t include any fancy shifting tricks, so it’s a better estimate for a novice raider who’s still getting comfortable tanking and hasn’t mastered their active mitigation yet.  This isn’t new data – you’ve seen this before, but we need it to establish the baseline so that we can tell what sort of difference Sacred Shield makes.

| Set: |    C/Ha |    C/Ma |    C/Av |   C/Bal |      Ha |   Avoid |  Av/Mas |  Mas/Av |
|   S% |  0.5224 |  0.4106 |  0.4191 |  0.4528 |  0.4990 |  0.3664 |  0.3632 |  0.3577 |
| mean |  0.6013 |  0.5410 |  0.5333 |  0.5559 |  0.6082 |  0.4946 |  0.5036 |  0.5158 |
|  std |  0.1478 |  0.1453 |  0.1759 |  0.1611 |  0.1523 |  0.1879 |  0.1771 |  0.1650 |
| ---- |  ------ |   --- 2 |  Attack |  Moving | Average |  ------ |  ------ |  ------ |
|  60% | 46.4365 | 42.2245 | 36.0532 | 42.0223 | 46.8495 | 30.6360 | 32.6615 | 38.9607 |
|  70% | 40.7703 | 21.9045 | 32.3510 | 32.0562 | 41.5132 | 27.8290 | 27.5790 | 22.6745 |
|  80% | 14.6537 | 21.9045 | 16.8478 | 17.5670 | 17.2325 | 16.7553 | 19.2880 | 22.6745 |
|  90% |  9.8918 | 10.2063 | 11.3503 | 10.7805 | 11.6783 | 11.2970 | 10.6098 | 10.0570 |
| ---- |  ------ |   --- 3 |  Attack |  Moving | Average |  ------ |  ------ |  ------ |
|  60% | 53.8772 | 32.5935 | 39.5635 | 45.3188 | 54.4480 | 34.0340 | 35.6205 | 31.5645 |
|  70% | 37.0875 | 18.1815 | 24.6943 | 28.7108 | 37.0938 | 18.9820 | 17.2312 | 17.7622 |
|  80% | 15.1958 |  7.4453 | 13.2320 | 12.3843 | 16.6545 | 11.3433 | 11.0848 |  8.8108 |
|  90% |  1.2962 |  2.7432 |  3.2145 |  2.6515 |  3.1935 |  3.6222 |  3.2912 |  3.0520 |
| ---- |  ------ |   --- 4 |  Attack |  Moving | Average |  ------ |  ------ |  ------ |
|  60% | 53.9435 | 33.9070 | 39.4125 | 42.8023 | 54.8250 | 32.6215 | 33.1535 | 30.3133 |
|  70% | 32.4230 | 12.4927 | 21.3595 | 25.8540 | 32.6262 | 17.0912 | 17.2385 | 13.6712 |
|  80% |  3.3830 |  5.2843 |  6.2967 |  6.5102 |  6.9973 |  5.6180 |  5.2748 |  6.7035 |
|  90% |  0.0000 |  1.2263 |  0.9175 |  0.6537 |  1.4930 |  1.9408 |  2.3090 |  2.7103 |
| ---- |  ------ |   --- 5 |  Attack |  Moving | Average |  ------ |  ------ |  ------ |
|  60% | 55.5823 | 39.0590 | 40.1595 | 42.7240 | 56.8680 | 33.0050 | 30.1425 | 34.5108 |
|  70% | 28.7618 | 10.5665 | 19.3762 | 22.4620 | 30.4220 | 15.4128 | 13.3293 | 11.5990 |
|  80% |  8.9097 |  1.4918 |  7.0112 |  5.3835 | 10.8432 |  4.9352 |  2.7422 |  3.4403 |
|  90% |  0.0000 |  0.0000 |  0.5200 |  0.3295 |  1.0175 |  1.0540 |  0.6695 |  0.7688 |
| ---- |  ------ |   --- 6 |  Attack |  Moving | Average |  ------ |  ------ |  ------ |
|  60% | 54.3558 | 35.7295 | 34.1108 | 41.2287 | 55.5080 | 25.9360 | 28.3017 | 31.3457 |
|  70% | 24.3050 | 11.0603 | 13.4900 | 16.6937 | 26.1385 | 10.4652 | 10.5652 | 11.1263 |
|  80% |  4.2673 |  0.0000 |  4.3717 |  4.8828 |  6.8168 |  3.4403 |  2.7655 |  1.4698 |
|  90% |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.2012 |  0.3240 |  0.2855 |  0.2027 |
| ---- |  ------ |   --- 7 |  Attack |  Moving | Average |  ------ |  ------ |  ------ |
|  60% | 53.2705 | 32.1395 | 32.5230 | 38.7373 | 54.7385 | 24.7587 | 25.7575 | 28.3533 |
|  70% | 22.7233 |  9.7105 | 12.6490 | 15.3603 | 24.6157 |  9.4672 |  9.3260 |  9.6970 |
|  80% |  3.8538 |  0.7848 |  3.0023 |  2.9965 |  5.5295 |  2.0965 |  1.9265 |  1.4485 |
|  90% |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0445 |  0.1020 |  0.1087 |  0.1403 |

As we saw before, Control/Mastery has a pretty strong advantage.  Control/Haste makes a good showing in certain categories, but lags significantly in most of them.

However, if we turn Sacred Shield on, we find get very different results:

| Set: |    C/Ha |    C/Ma |    C/Av |   C/Bal |      Ha |   Avoid |  Av/Mas |  Mas/Av |
|   S% |  0.5229 |  0.4106 |  0.4195 |  0.4520 |  0.4980 |  0.3667 |  0.3621 |  0.3575 |
| mean |  0.4111 |  0.3898 |  0.3663 |  0.3893 |  0.4175 |  0.3378 |  0.3448 |  0.3644 |
|  std |  0.1362 |  0.1357 |  0.1521 |  0.1440 |  0.1424 |  0.1597 |  0.1553 |  0.1495 |
| ---- |  ------ |   --- 2 |  Attack |  Moving | Average |  ------ |  ------ |  ------ |
|  40% | 47.8083 | 48.5945 | 39.4050 | 45.5303 | 48.5420 | 34.5910 | 36.9545 | 45.0358 |
|  50% | 38.6730 | 29.1845 | 31.8520 | 32.9937 | 39.4498 | 27.3310 | 28.9110 | 28.6592 |
|  60% | 14.2155 | 25.0162 | 16.4483 | 18.5405 | 16.8133 | 16.3825 | 19.6868 | 24.3062 |
|  70% |  9.0985 | 12.2625 | 10.7745 | 11.6047 | 10.6237 | 10.6597 | 10.8950 | 11.3018 |
|  80% |  9.0983 | 11.1268 | 10.7743 | 10.6713 | 10.6235 | 10.6595 | 10.2533 |  9.9063 |
|  90% |  0.0005 |  1.8365 |  0.0005 |  0.5215 |  0.0003 |  0.0003 |  0.3465 |  1.2070 |
| ---- |  ------ |   --- 3 |  Attack |  Moving | Average |  ------ |  ------ |  ------ |
|  40% | 53.2233 | 47.9372 | 41.6563 | 46.2660 | 54.7275 | 37.3810 | 38.3425 | 44.8230 |
|  50% | 33.1910 | 29.1695 | 28.1168 | 31.0420 | 34.3940 | 25.1808 | 25.1827 | 27.6882 |
|  60% | 15.8120 | 15.3685 | 13.5373 | 12.3215 | 17.3197 | 11.6468 | 10.7345 | 14.6328 |
|  70% |  6.0195 |  6.2542 |  6.4393 |  7.1407 |  7.7778 |  6.0847 |  5.1463 |  6.4992 |
|  80% |  0.5590 |  2.0340 |  1.2630 |  1.3333 |  1.3225 |  1.3603 |  1.4642 |  1.8325 |
|  90% |  0.0003 |  0.0003 |  0.0003 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |
| ---- |  ------ |   --- 4 |  Attack |  Moving | Average |  ------ |  ------ |  ------ |
|  40% | 55.6395 | 50.5580 | 45.6000 | 50.7708 | 56.6330 | 39.9558 | 41.5223 | 44.1125 |
|  50% | 32.0505 | 22.0170 | 23.8438 | 29.0312 | 32.5883 | 19.4885 | 20.2703 | 19.7258 |
|  60% |  3.3115 |  7.8463 |  6.6013 |  7.8057 |  7.0792 |  6.3295 |  6.5520 |  8.6195 |
|  70% |  1.5733 |  2.3697 |  3.3905 |  1.0685 |  3.8997 |  3.5480 |  2.4675 |  3.3725 |
|  80% |  0.0000 |  0.5643 |  0.4318 |  0.3043 |  0.6975 |  0.9630 |  0.8832 |  0.8835 |
|  90% |  0.0000 |  0.0860 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0003 |  0.0000 |
| ---- |  ------ |   --- 5 |  Attack |  Moving | Average |  ------ |  ------ |  ------ |
|  40% | 56.0972 | 47.6848 | 43.1835 | 49.6810 | 57.1600 | 35.3995 | 37.6767 | 39.3170 |
|  50% | 28.0432 | 23.6345 | 20.8675 | 23.0615 | 30.4812 | 17.0093 | 16.7255 | 20.8955 |
|  60% |  9.0510 |  2.8620 |  7.2145 |  6.7045 | 11.3188 |  5.9373 |  5.1080 |  4.2838 |
|  70% |  0.0000 |  0.3158 |  0.4495 |  0.2433 |  1.0105 |  1.0470 |  1.1665 |  1.4310 |
|  80% |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0562 |  0.1053 |  0.1070 |  0.1305 |
|  90% |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |
| ---- |  ------ |   --- 6 |  Attack |  Moving | Average |  ------ |  ------ |  ------ |
|  40% | 57.0305 | 47.5482 | 42.5625 | 47.8055 | 58.5522 | 34.9025 | 34.1675 | 40.9050 |
|  50% | 28.6013 | 19.9410 | 20.1412 | 21.2048 | 30.8865 | 15.7623 | 15.3158 | 15.7263 |
|  60% |  3.9783 |  3.8653 |  4.6835 |  5.9700 |  6.6668 |  3.9325 |  3.5230 |  3.5655 |
|  70% |  0.0000 |  0.0000 |  0.0000 |  0.0747 |  0.2290 |  0.4517 |  0.5048 |  0.6350 |
|  80% |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0210 |  0.0635 |  0.0578 |  0.0615 |
|  90% |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |
| ---- |  ------ |   --- 7 |  Attack |  Moving | Average |  ------ |  ------ |  ------ |
|  40% | 55.1845 | 47.9093 | 42.2420 | 47.8852 | 56.8610 | 34.7955 | 33.5052 | 41.3620 |
|  50% | 23.3448 | 18.5660 | 16.4868 | 18.9205 | 26.0792 | 12.7240 | 11.9865 | 16.0440 |
|  60% |  3.0648 |  3.1160 |  3.1250 |  3.7430 |  5.1485 |  2.6605 |  2.4692 |  2.8385 |
|  70% |  0.1460 |  0.0473 |  0.2498 |  0.2550 |  0.4335 |  0.2563 |  0.1417 |  0.1662 |
|  80% |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0017 |  0.0055 |  0.0043 |  0.0067 |
|  90% |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |

I’ve had to include a lot more data here, because Sacred Shield absorbs a LOT of damage.  We’re getting about a ~30% reduction in damage taken across the board by turning on Sacred Shield.  As we get into sequences of many attacks we can zero out almost all of the 60%-90% categories.  When that happens, we need to consider the lower sizes to get a clear idea of what each gear set is doing.  It makes the tables a bit more unwieldly, which is annoying, but most people just read my summary of the table anyway.  Either way, I’d rather have all of the data on the table so that inquiring minds can look for things I may have missed.

The first thing you note on this table is that Control/Haste fares significantly better than it did without Sacred Shield.  It is competing with or beating Control/Mastery in pretty much every category.  It isn’t until we get to 7 attacks that it starts to trail C/Mastery by any measurable amount, and even that’s not very much.  The small advantage C/Ma has in the  7-attack category doesn’t make up for the significant advantage C/Ha gives you in the 2- to 4- attack categories.  And while C/Ma maintains it’s lead in damage taken, that lead has dropped from 10% to 5%.

The other surprising thing about this data set is that the avoidance gear sets don’t perform all that badly.  They’re rarely winning in a category, but they often rival C/Ma.  Their usual weakness in the 80% and 90% thresholds is still there, but it’s not as pronounced as before.  And it still takes about 18% less damage than C/Ha.

This is likely due to the inherent synergy between avoidance and absorption effects.  Avoiding an attack during SotR means that there’s one fewer attack to which SotR’s mitigation is applied, effectively undermining the use of SotR – that’s the negative scaling we’ve consistently seen between avoidance and control stats in the past.

But avoiding an attack doesn’t waste an absorption bubble, allowing that bubble to apply to the next unavoided attack.  In that way, absorption bubbles automatically time-shift to make themselves useful. The only time they’re wasted is if they expire before you take an attack, which means you didn’t take damage during the duration – an automatically safe situation to begin with.

The other gear sets all perform pretty well too, though nothing stands out as particularly interesting.  None of them trail by much, so the “use whatever gear you can find” strategy isn’t going to be at that much of a disadvantage.

In any event, it seems Control/Haste has won this round.  Control/Mastery isn’t that far behind, but it also doesn’t provide the raw DPS increase that the haste build does.  When one build is better for DPS and for survivability with the “macro SotR to Crusader Strike” queue, it’s a bit of a no-brainer.

However, we also know that shifting seemed to give mastery a bigger benefit than haste.  So maybe enabling the shifting algorithm will allow mastery to regain some of that ground.  Let’s see if that changes anything.

Results – SH1 Finisher Queue

If you remember from last time, the SH1 queue tries to cast SotR if:

  1. We have 5 holy power and a generator is available within the next second
  2. We have 3+ holy power and the mean of the last boss attack exceeded 80% throughput.

This means that we’ll use SotR early if the last boss attack wasn’t blocked, avoided, or mitigated with SotR.  Otherwise we’ll just bank holy power to 5 and bleed it as safely as possible.

First, let’s look at the data with Sacred Shield disabled.  This is the same data we saw earlier this week for C/Ha and C/Ma, but this table includes all of the other gear sets.

| Set: |    C/Ha |    C/Ma |    C/Av |   C/Bal |      Ha |   Avoid |  Av/Mas |  Mas/Av |
|   S% |  0.5224 |  0.4103 |  0.4197 |  0.4523 |  0.4980 |  0.3672 |  0.3625 |  0.3577 |
| mean |  0.6004 |  0.5416 |  0.5328 |  0.5562 |  0.6082 |  0.4936 |  0.5043 |  0.5164 |
|  std |  0.1348 |  0.1332 |  0.1643 |  0.1480 |  0.1397 |  0.1766 |  0.1638 |  0.1503 |
| ---- |  ------ |   --- 2 |  Attack |  Moving | Average |  ------ |  ------ |  ------ |
|  40% | 79.9800 | 65.3280 | 69.9758 | 74.0790 | 80.4850 | 65.0438 | 67.4257 | 63.1565 |
|  50% | 64.7512 | 50.0140 | 46.1452 | 51.0942 | 64.8940 | 37.6743 | 37.4632 | 45.0725 |
|  60% | 47.3285 | 46.5570 | 36.3417 | 42.8345 | 48.1180 | 30.6615 | 34.7815 | 42.3635 |
|  70% | 43.2215 | 17.4820 | 33.6598 | 32.6245 | 44.1107 | 28.5703 | 27.5072 | 18.3808 |
|  80% | 10.0245 | 17.4820 | 12.2670 | 12.9318 | 12.6908 | 12.3615 | 15.1310 | 18.3808 |
|  90% |  4.4145 |  5.6712 |  6.5693 |  5.8338 |  6.3378 |  7.0395 |  6.7092 |  6.1442 |
| ---- |  ------ |   --- 3 |  Attack |  Moving | Average |  ------ |  ------ |  ------ |
|  40% | 85.6148 | 83.1100 | 71.9463 | 79.9485 | 85.7280 | 63.5208 | 68.6168 | 77.3255 |
|  50% | 77.8120 | 58.6900 | 63.8260 | 70.0968 | 78.2438 | 56.0808 | 45.6707 | 53.3563 |
|  60% | 53.8410 | 27.6640 | 37.3355 | 43.9935 | 54.8933 | 31.0248 | 34.3588 | 26.9438 |
|  70% | 36.5553 | 13.3447 | 23.9787 | 27.9680 | 37.4950 | 18.2287 | 13.7600 | 13.5083 |
|  80% |  7.4112 |  4.4365 |  8.3697 |  7.3390 |  9.7087 |  7.5145 |  7.5018 |  5.6735 |
|  90% |  0.4773 |  1.3013 |  1.5867 |  1.2285 |  1.6435 |  2.1285 |  1.9637 |  1.7528 |
| ---- |  ------ |   --- 4 |  Attack |  Moving | Average |  ------ |  ------ |  ------ |
|  40% | 86.0850 | 83.9205 | 70.7567 | 79.5945 | 86.5430 | 62.6885 | 71.0963 | 78.4237 |
|  50% | 79.6950 | 61.9600 | 59.6745 | 64.4532 | 79.7443 | 48.4910 | 46.9840 | 54.0313 |
|  60% | 52.7840 | 31.5972 | 37.1283 | 41.4445 | 54.3593 | 30.1280 | 30.9165 | 27.8300 |
|  70% | 26.7898 |  8.7100 | 18.4998 | 22.4168 | 28.8195 | 14.6303 | 14.7073 |  9.9785 |
|  80% |  2.0325 |  3.5068 |  3.7713 |  3.8595 |  4.5088 |  3.6730 |  3.6110 |  4.6870 |
|  90% |  0.0653 |  0.7993 |  0.5550 |  0.4383 |  0.8952 |  1.2337 |  1.5215 |  1.7453 |
| ---- |  ------ |   --- 5 |  Attack |  Moving | Average |  ------ |  ------ |  ------ |
|  40% | 93.0055 | 84.9635 | 79.4570 | 84.4562 | 93.0613 | 69.4290 | 71.0673 | 77.7092 |
|  50% | 79.3107 | 60.1430 | 60.8635 | 67.3745 | 79.8648 | 51.1845 | 49.2092 | 53.2810 |
|  60% | 55.6362 | 36.5780 | 38.8565 | 41.5920 | 57.4337 | 31.2155 | 27.9410 | 31.6680 |
|  70% | 25.5045 |  8.8130 | 16.8290 | 18.7098 | 28.0448 | 13.0993 | 11.0980 |  9.4880 |
|  80% |  5.0088 |  1.3685 |  5.0305 |  3.7135 |  7.2525 |  3.8527 |  1.9560 |  2.6338 |
|  90% |  0.0000 |  0.0487 |  0.2490 |  0.1515 |  0.5242 |  0.6455 |  0.4367 |  0.4740 |
| ---- |  ------ |   --- 6 |  Attack |  Moving | Average |  ------ |  ------ |  ------ |
|  40% | 93.6545 | 85.7085 | 80.9963 | 86.8032 | 93.8197 | 72.0932 | 75.3320 | 78.7903 |
|  50% | 81.1658 | 65.3350 | 61.0710 | 67.5583 | 81.6785 | 49.4887 | 49.8540 | 55.8625 |
|  60% | 56.3747 | 32.6410 | 34.1103 | 40.5217 | 57.6178 | 25.0623 | 26.3197 | 28.7055 |
|  70% | 23.3570 |  8.5092 | 12.1910 | 14.3090 | 25.4800 |  9.0840 |  8.7905 |  9.1058 |
|  80% |  2.4442 |  0.1440 |  2.9768 |  3.2437 |  4.6220 |  2.6045 |  2.0735 |  1.0507 |
|  90% |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.1085 |  0.2122 |  0.1905 |  0.1110 |
| ---- |  ------ |   --- 7 |  Attack |  Moving | Average |  ------ |  ------ |  ------ |
|  40% | 94.5883 | 87.7143 | 82.3010 | 89.3173 | 94.7705 | 72.6070 | 77.9573 | 81.1767 |
|  50% | 81.7600 | 62.9725 | 61.0677 | 68.3070 | 82.3575 | 49.7385 | 50.8487 | 54.5155 |
|  60% | 54.7430 | 28.8410 | 31.6180 | 37.7540 | 56.2775 | 23.1782 | 23.9253 | 25.5347 |
|  70% | 20.0370 |  7.2920 | 10.7345 | 12.8502 | 22.5915 |  8.0165 |  7.6148 |  7.8110 |
|  80% |  1.9885 |  0.5120 |  2.0800 |  1.9633 |  3.6658 |  1.6352 |  1.4348 |  1.0933 |
|  90% |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0225 |  0.0697 |  0.0850 |  0.0852 |

We see a reprisal of the Control/Mastery superiority here, but we talked about that last time.  It’s clear that the shifting queue benefits Control/Avoidance less than the mastery and haste variants, and Control/Balance tends to fall somewhere in the middle.  The avoidance builds generally perform a little worse than the Control builds again, much like they did with the simple S queue.

Now let’s turn Sacred Shield back on and see what happens:

| Set: |    C/Ha |    C/Ma |    C/Av |   C/Bal |      Ha |   Avoid |  Av/Mas |  Mas/Av |
|   S% |  0.5227 |  0.4103 |  0.4192 |  0.4522 |  0.4988 |  0.3669 |  0.3620 |  0.3572 |
| mean |  0.4112 |  0.3923 |  0.3670 |  0.3897 |  0.4178 |  0.3370 |  0.3453 |  0.3671 |
|  std |  0.1297 |  0.1272 |  0.1420 |  0.1334 |  0.1321 |  0.1479 |  0.1412 |  0.1372 |
| ---- |  ------ |   --- 2 |  Attack |  Moving | Average |  ------ |  ------ |  ------ |
|  40% | 47.6090 | 53.3802 | 39.9920 | 46.3927 | 48.5255 | 34.8960 | 38.7608 | 48.7848 |
|  50% | 39.0460 | 30.6213 | 32.9847 | 33.9475 | 40.0908 | 28.0093 | 29.3300 | 28.8960 |
|  60% | 13.0910 | 24.1870 | 14.1325 | 16.8777 | 15.2587 | 14.0968 | 17.5545 | 23.0013 |
|  70% |  7.4175 |  7.3740 |  8.1310 |  8.9853 |  8.4995 |  8.1120 |  8.5627 |  7.6457 |
|  80% |  7.4175 |  6.9742 |  8.1295 |  7.7037 |  8.4987 |  8.1117 |  7.6287 |  6.9807 |
|  90% |  0.0003 |  0.1588 |  0.0000 |  0.0037 |  0.0000 |  0.0003 |  0.0135 |  0.1363 |
| ---- |  ------ |   --- 3 |  Attack |  Moving | Average |  ------ |  ------ |  ------ |
|  40% | 54.6732 | 53.5018 | 43.6617 | 49.0445 | 56.5392 | 38.5643 | 40.1080 | 48.6035 |
|  50% | 33.3215 | 22.9238 | 27.4898 | 31.5487 | 35.2305 | 24.1510 | 23.0220 | 22.8960 |
|  60% | 13.8798 |  9.2035 | 10.5063 |  7.7275 | 15.5575 |  8.9612 |  6.3230 |  9.3345 |
|  70% |  3.9423 |  3.9482 |  3.2218 |  3.6018 |  4.8708 |  2.9163 |  2.5517 |  4.0790 |
|  80% |  0.0017 |  0.8727 |  0.2373 |  0.2875 |  0.2022 |  0.3850 |  0.5318 |  0.8918 |
|  90% |  0.0000 |  0.0003 |  0.0000 |  0.0003 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |
| ---- |  ------ |   --- 4 |  Attack |  Moving | Average |  ------ |  ------ |  ------ |
|  40% | 57.7482 | 50.3973 | 47.5403 | 53.0330 | 59.5875 | 41.2575 | 42.6945 | 45.2568 |
|  50% | 29.6090 | 21.8163 | 21.9488 | 27.0672 | 31.3215 | 17.1445 | 17.8478 | 18.7295 |
|  60% |  1.1785 |  5.7568 |  2.4093 |  4.0728 |  2.7228 |  2.7700 |  3.6998 |  6.0033 |
|  70% |  0.1500 |  1.4965 |  0.7970 |  0.7388 |  0.8792 |  1.1280 |  1.2070 |  1.9040 |
|  80% |  0.0013 |  0.1310 |  0.1045 |  0.0710 |  0.1643 |  0.2465 |  0.2515 |  0.2935 |
|  90% |  0.0000 |  0.0105 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0005 |
| ---- |  ------ |   --- 5 |  Attack |  Moving | Average |  ------ |  ------ |  ------ |
|  40% | 57.0225 | 47.6938 | 43.5565 | 50.3275 | 59.0108 | 35.0115 | 37.2285 | 39.8558 |
|  50% | 26.1370 | 21.6223 | 17.4095 | 19.3090 | 28.3583 | 13.7083 | 13.7485 | 19.2475 |
|  60% |  7.0750 |  2.4827 |  5.0105 |  5.1677 |  8.5480 |  3.8860 |  3.2785 |  2.7635 |
|  70% |  0.0843 |  0.6472 |  0.2590 |  0.1657 |  0.4012 |  0.3640 |  0.4855 |  0.9257 |
|  80% |  0.0000 |  0.0233 |  0.0037 |  0.0020 |  0.0060 |  0.0248 |  0.0333 |  0.0643 |
|  90% |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0003 |
| ---- |  ------ |   --- 6 |  Attack |  Moving | Average |  ------ |  ------ |  ------ |
|  40% | 58.3780 | 47.0712 | 42.9440 | 48.4048 | 60.3563 | 34.2907 | 32.9735 | 40.4083 |
|  50% | 27.7150 | 16.1460 | 17.9885 | 18.7237 | 30.0160 | 13.3348 | 12.4510 | 13.1953 |
|  60% |  3.1587 |  3.8188 |  2.8743 |  3.9238 |  4.5448 |  2.4330 |  2.2203 |  3.2333 |
|  70% |  0.0003 |  0.2053 |  0.0308 |  0.0473 |  0.0583 |  0.1335 |  0.2328 |  0.4163 |
|  80% |  0.0000 |  0.0017 |  0.0000 |  0.0000 |  0.0040 |  0.0145 |  0.0130 |  0.0165 |
|  90% |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |
| ---- |  ------ |   --- 7 |  Attack |  Moving | Average |  ------ |  ------ |  ------ |
|  40% | 56.0545 | 48.6200 | 43.1815 | 49.0210 | 58.3612 | 34.3670 | 32.6210 | 41.2830 |
|  50% | 22.4383 | 16.2710 | 14.7237 | 16.5923 | 24.9438 | 10.7795 |  9.4425 | 14.2403 |
|  60% |  2.0663 |  1.8787 |  1.5637 |  1.8995 |  3.1532 |  1.3958 |  1.4743 |  2.0515 |
|  70% |  0.0005 |  0.0730 |  0.0762 |  0.0818 |  0.1150 |  0.1095 |  0.0670 |  0.1415 |
|  80% |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0003 |  0.0010 |  0.0013 |  0.0035 |
|  90% |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |

Whoa. The shifting algorithm was giving C/Ma a significant edge before, but turning on Sacred Shield completely reverses that result.  Control/Haste completely blows everything else out of the water here for shorter strings, and not by any small margin.  In the 3- to 4-attack categories, it’s almost a full threshold level ahead.  It’s showing fewer spikes in the 70% category than C/Ma is showing in the 80% category!  It isn’t until we get up to 5- attacks that mastery manages to catch up by virtue of its stronger probabilistic footing.  The more attacks to which you can apply block chance, the better C/Ma perform.

I think that what’s happening here is the following: C/Ha is getting Sacred Shield bubbles every ~4 seconds, which means it’s covering roughly every third boss attack.  Those attacks are guaranteed to not trigger the shifting algorithm, and C/Haste generates holy power fast enough that it can basically always cover the other two with SotR if it needs to, even if the bleed valve engaged recently.  That makes it incredibly strong for short-attack strings.

It falls behind a little in the longer strings because it can only keep this up for so long before running out of gas and needing another ~5 seconds to recharge.  So for the long strings, it loses a little ground to the more stochasting C/Ma set.

C/Ma can’t muster up that same level of HPG, and it’s only covering one in four boss swings with the guaranteed absorb, so it’ll end up struggling for short strings.  But through sheer probability it’s going to be able to brute-force long strings and claw its way back into contention.

This is rather eye-opening, because it suggests that there’s very little point in running Control/Mastery if you’re an advanced tank (using Sacred Shield, of course).  There doesn’t seem to be a category in which C/Ma gives a distinct advantage, and you’d be giving up a lot of DPS as well.  In one fell swoop, it’s upended the paradigm and put us right back where we were in 5.0.

But we have one final simulation to run, this time with the SH2 queue.  We know that favors C/Ma a little, so let’s see if it can pull out a last-minute hail mary.

Results – SH2 Finisher Queue

Again, first we’ll look at the data with Sacred Shield disabled to set our baseline.

| Set: |    C/Ha |    C/Ma |    C/Av |   C/Bal |      Ha |   Avoid |  Av/Mas |  Mas/Av |
|   S% |  0.5223 |  0.4100 |  0.4194 |  0.4523 |  0.4993 |  0.3666 |  0.3620 |  0.3577 |
| mean |  0.6000 |  0.5428 |  0.5319 |  0.5565 |  0.6084 |  0.4942 |  0.5050 |  0.5171 |
|  std |  0.1424 |  0.1250 |  0.1652 |  0.1486 |  0.1410 |  0.1747 |  0.1594 |  0.1415 |
| ---- |  ------ |   --- 2 |  Attack |  Moving | Average |  ------ |  ------ |  ------ |
|  40% | 77.8200 | 65.0427 | 68.2365 | 72.6840 | 79.0070 | 63.8262 | 66.6148 | 62.8997 |
|  50% | 64.6552 | 48.8390 | 45.9310 | 51.0615 | 64.8900 | 37.7113 | 37.6560 | 43.9873 |
|  60% | 45.7122 | 43.0228 | 35.8450 | 42.0607 | 46.6923 | 30.4370 | 32.7540 | 39.3973 |
|  70% | 40.2465 | 19.5655 | 32.0827 | 31.5863 | 41.3385 | 27.4450 | 27.0597 | 20.1478 |
|  80% | 14.1430 | 19.5655 | 14.5213 | 15.6145 | 15.8750 | 14.4053 | 17.0558 | 20.1478 |
|  90% |  9.3812 |  8.5258 |  9.7062 |  9.4170 | 10.5368 |  9.5890 |  9.0388 |  8.4430 |
| ---- |  ------ |   --- 3 |  Attack |  Moving | Average |  ------ |  ------ |  ------ |
|  40% | 81.8700 | 80.9910 | 70.0565 | 77.7767 | 82.9153 | 62.2112 | 66.2630 | 75.3718 |
|  50% | 74.4885 | 59.3250 | 62.3030 | 68.4200 | 75.9533 | 55.2432 | 49.8645 | 54.8380 |
|  60% | 53.8223 | 33.8610 | 41.0710 | 47.0465 | 55.7272 | 35.3563 | 37.0870 | 32.0658 |
|  70% | 36.7032 | 13.9912 | 24.1533 | 28.1390 | 37.4335 | 18.3825 | 15.5112 | 13.3758 |
|  80% | 14.5350 |  1.7413 | 10.9438 |  9.5242 | 15.4828 |  8.9765 |  7.6713 |  3.4228 |
|  90% |  0.0010 |  0.6500 |  0.3152 |  0.1653 |  0.4120 |  0.8832 |  1.0208 |  1.1808 |
| ---- |  ------ |   --- 4 |  Attack |  Moving | Average |  ------ |  ------ |  ------ |
|  40% | 85.7677 | 85.2933 | 72.4490 | 80.5705 | 87.1720 | 66.1072 | 73.5293 | 80.4767 |
|  50% | 76.3633 | 66.6900 | 58.2595 | 65.1142 | 77.4215 | 47.6770 | 51.2200 | 58.7230 |
|  60% | 54.9747 | 31.7698 | 40.8983 | 44.3940 | 57.2597 | 33.2178 | 33.4380 | 27.1323 |
|  70% | 31.8188 |  4.1273 | 19.5360 | 24.5765 | 33.1850 | 14.8280 | 13.6393 |  6.6363 |
|  80% |  0.0035 |  1.2910 |  0.6425 |  0.4238 |  0.9350 |  1.4013 |  1.6883 |  2.7095 |
|  90% |  0.0000 |  0.2180 |  0.0508 |  0.0217 |  0.1497 |  0.4260 |  0.6865 |  1.0378 |
| ---- |  ------ |   --- 5 |  Attack |  Moving | Average |  ------ |  ------ |  ------ |
|  40% | 91.1868 | 87.1790 | 78.0393 | 84.1690 | 91.9443 | 68.5353 | 73.5373 | 80.9253 |
|  50% | 77.6485 | 62.6120 | 62.1093 | 69.7057 | 79.4778 | 53.1682 | 51.7235 | 55.2273 |
|  60% | 56.3043 | 35.5973 | 40.1310 | 42.6025 | 58.6827 | 32.3425 | 28.2125 | 31.0635 |
|  70% | 26.7188 |  6.9745 | 16.5240 | 18.3535 | 28.6548 | 12.6120 |  9.4627 |  7.5395 |
|  80% |  6.8837 |  0.3365 |  4.5732 |  3.4560 |  8.0095 |  3.3715 |  0.8610 |  1.4175 |
|  90% |  0.0000 |  0.0000 |  0.0305 |  0.0113 |  0.1123 |  0.2295 |  0.1958 |  0.2898 |
| ---- |  ------ |   --- 6 |  Attack |  Moving | Average |  ------ |  ------ |  ------ |
|  40% | 92.4952 | 86.9205 | 80.7193 | 86.2888 | 93.3290 | 72.9005 | 76.6795 | 80.3848 |
|  50% | 79.2488 | 66.7635 | 60.8193 | 67.7832 | 80.9382 | 49.7330 | 51.7130 | 57.6740 |
|  60% | 54.5883 | 32.6580 | 33.2920 | 40.7420 | 56.3898 | 24.5072 | 26.2225 | 28.1565 |
|  70% | 22.8665 |  7.3368 | 11.1203 | 13.7167 | 24.2715 |  7.9290 |  7.6668 |  7.7412 |
|  80% |  3.3348 |  0.0128 |  2.4295 |  2.9755 |  4.4640 |  2.0282 |  1.5145 |  0.5995 |
|  90% |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0245 |  0.0643 |  0.0847 |  0.0762 |
| ---- |  ------ |   --- 7 |  Attack |  Moving | Average |  ------ |  ------ |  ------ |
|  40% | 93.3610 | 88.5393 | 81.7302 | 88.7318 | 94.1352 | 73.3020 | 78.4955 | 82.5045 |
|  50% | 79.4857 | 65.5380 | 61.3417 | 69.2993 | 81.4112 | 50.9712 | 52.6560 | 56.6260 |
|  60% | 53.2993 | 29.5740 | 31.6163 | 38.8610 | 55.4382 | 23.1475 | 24.0225 | 25.2393 |
|  70% | 21.3562 |  4.7965 | 10.4565 | 12.9678 | 23.2783 |  7.3540 |  6.5375 |  5.8625 |
|  80% |  2.8672 |  0.2820 |  1.6265 |  1.1868 |  3.7050 |  1.1700 |  0.8225 |  0.6787 |
|  90% |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0047 |  0.0178 |  0.0320 |  0.0480 |

There isn’t a lot new here – this is much the same as the SH1 data.  Control/Mastery dominates, the other Control sets lag by varying degrees, and avoidance tends to lag even further until we look at very long strings of attacks.  Business as usual.

However, turning on Sacred Shield one last time…

| Set: |    C/Ha |    C/Ma |    C/Av |   C/Bal |      Ha |   Avoid |  Av/Mas |  Mas/Av |
|   S% |  0.5229 |  0.4109 |  0.4191 |  0.4524 |  0.4981 |  0.3660 |  0.3617 |  0.3566 |
| mean |  0.4120 |  0.3902 |  0.3673 |  0.3890 |  0.4176 |  0.3380 |  0.3455 |  0.3661 |
|  std |  0.1324 |  0.1276 |  0.1449 |  0.1374 |  0.1337 |  0.1492 |  0.1434 |  0.1368 |
| ---- |  ------ |   --- 2 |  Attack |  Moving | Average |  ------ |  ------ |  ------ |
|  40% | 47.6120 | 50.2428 | 39.8375 | 45.7452 | 48.3047 | 34.8185 | 38.0930 | 46.7488 |
|  50% | 38.9460 | 28.5045 | 32.7732 | 33.3143 | 39.7985 | 27.9272 | 29.1158 | 28.0058 |
|  60% | 14.2005 | 23.6138 | 15.2243 | 17.4722 | 16.0515 | 14.8583 | 18.1448 | 23.1213 |
|  70% |  8.6380 | 10.5908 |  9.2225 | 10.2643 |  9.4262 |  8.9523 |  9.4345 |  9.8748 |
|  80% |  8.6378 |  9.4778 |  9.2225 |  9.2380 |  9.4262 |  8.9520 |  8.6443 |  8.3620 |
|  90% |  0.0005 |  1.7873 |  0.0003 |  0.4998 |  0.0005 |  0.0003 |  0.3010 |  1.0542 |
| ---- |  ------ |   --- 3 |  Attack |  Moving | Average |  ------ |  ------ |  ------ |
|  40% | 54.1732 | 49.7465 | 43.3820 | 47.6243 | 55.8525 | 38.5485 | 39.8533 | 46.8705 |
|  50% | 33.9008 | 29.2475 | 29.0235 | 32.0695 | 35.4320 | 25.4790 | 25.5342 | 27.7323 |
|  60% | 16.0977 | 14.1055 | 12.8713 | 10.5247 | 17.4093 | 10.6113 |  8.2012 | 12.5555 |
|  70% |  5.2683 |  2.6925 |  4.0322 |  5.1090 |  5.8770 |  3.3680 |  2.0065 |  3.3333 |
|  80% |  0.0005 |  0.2215 |  0.0328 |  0.1455 |  0.0620 |  0.1715 |  0.3105 |  0.5557 |
|  90% |  0.0003 |  0.0000 |  0.0000 |  0.0003 |  0.0003 |  0.0000 |  0.0003 |  0.0000 |
| ---- |  ------ |   --- 4 |  Attack |  Moving | Average |  ------ |  ------ |  ------ |
|  40% | 56.8932 | 54.5630 | 48.4860 | 52.9208 | 58.8742 | 42.7167 | 44.7313 | 48.1942 |
|  50% | 32.3667 | 19.4830 | 23.6827 | 29.0388 | 33.4400 | 18.0577 | 19.5975 | 17.5515 |
|  60% |  1.4580 |  3.5452 |  2.5282 |  4.3430 |  2.9897 |  2.8442 |  3.2468 |  4.9950 |
|  70% |  0.0535 |  0.6055 |  0.3357 |  0.3340 |  0.4828 |  0.7567 |  0.7258 |  1.0982 |
|  80% |  0.0003 |  0.0170 |  0.0053 |  0.0010 |  0.0298 |  0.1063 |  0.0865 |  0.0828 |
|  90% |  0.0000 |  0.0013 |  0.0000 |  0.0000 |  0.0003 |  0.0000 |  0.0000 |  0.0000 |
| ---- |  ------ |   --- 5 |  Attack |  Moving | Average |  ------ |  ------ |  ------ |
|  40% | 57.3653 | 47.7255 | 44.5812 | 50.7285 | 59.1245 | 35.9823 | 38.9498 | 40.3257 |
|  50% | 27.4577 | 20.2110 | 19.1030 | 20.9293 | 29.4162 | 14.7647 | 14.4468 | 18.8630 |
|  60% |  7.4005 |  2.2590 |  5.0818 |  5.0638 |  8.5432 |  3.7573 |  3.0122 |  2.1902 |
|  70% |  0.0325 |  0.1300 |  0.1363 |  0.0567 |  0.2250 |  0.2560 |  0.2508 |  0.4215 |
|  80% |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0028 |  0.0095 |  0.0055 |  0.0100 |
|  90% |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |
| ---- |  ------ |   --- 6 |  Attack |  Moving | Average |  ------ |  ------ |  ------ |
|  40% | 58.3780 | 47.0772 | 43.6273 | 48.4960 | 60.4503 | 35.2037 | 34.0155 | 41.4363 |
|  50% | 28.5205 | 17.8475 | 19.2605 | 19.8965 | 30.5623 | 14.0432 | 13.2497 | 13.7620 |
|  60% |  3.3697 |  2.8927 |  2.9888 |  4.3565 |  4.4585 |  2.3605 |  2.0293 |  2.2940 |
|  70% |  0.0005 |  0.0253 |  0.0043 |  0.0600 |  0.0212 |  0.0692 |  0.0895 |  0.1422 |
|  80% |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0015 |  0.0053 |  0.0030 |  0.0045 |
|  90% |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |
| ---- |  ------ |   --- 7 |  Attack |  Moving | Average |  ------ |  ------ |  ------ |
|  40% | 56.1492 | 49.2988 | 43.4217 | 48.6828 | 58.2107 | 34.9405 | 33.4910 | 42.2753 |
|  50% | 23.0362 | 16.5573 | 15.8103 | 17.8190 | 25.2770 | 11.2423 | 10.0868 | 14.1870 |
|  60% |  2.5048 |  1.5065 |  1.6330 |  2.2555 |  3.3623 |  1.3305 |  1.1208 |  1.4793 |
|  70% |  0.0005 |  0.0107 |  0.0135 |  0.0200 |  0.0460 |  0.0570 |  0.0275 |  0.0548 |
|  80% |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0003 |  0.0005 |  0.0000 |  0.0005 |
|  90% |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |

Again, we see Control/Haste dart out to an early lead in the short-string categories. But this time starts falling slightly behind Control/Mastery in the 5-attack category, and never quite regains the lead. This is still not a banner showing for Control/Mastery, mind you, but at least it didn’t lose in every category this time. I guess we can give it a medal for participation?

It’s worth commenting on the other sets here as well. The other Control sets still lag a little, but again aren’t that bad. The avoidance gear sets actually compete pretty well at lower threshold levels in most of the categories, often winning by a pretty wide margin. But like usual they can’t suppress the largest spikes the way a Control set can. And the mantra we’ve been repeating is “Spikes kill tanks,” so we have to consider those high-damage categories as a little more important. All in all, we’re still not very impressed with the other offerings.

Conclusions

It looks like Control/Haste has a pretty commanding lead when Sacred Shield is turned on, even though it lags significantly when Sacred Shield is absent.  Unless we’re really concerned with 6- and 7-attack strings, there’s a decent bit of survivability to be gained by sticking with haste.  And of course, there’s the DPS angle to consider, which is nontrivial for raiders in a variety of categories; from 10-mans raiders where tank DPS is a large percentage of raid DPS to heroic raiders looking for that last little bit of juice to meet the enrage.

What surprised me most about these results was just how powerful Sacred Shield is.  I’ve been touting it as the obvious choice in that talent tier since release, but these results really hammer that point home.  Sacred Shield is essentially a floating “smart SotR” every six seconds that automatically adapts to your damage intake pattern.  It’s steady, can’t overheal, won’t be wasted when you get a lucky avoid, and best of all free because it only costs a GCD.  It’s the damage smoother’s dream talent, and there’s literally nothing else in the tier that can compare.

Once you recognize the power of Sacred Shield, the dominance of haste in these simulations becomes more understandable.  Getting more of these “smart SotRs” is a huge benefit for a tank that adapts their actual SotR usage to intake patterns, because they can often guarantee coverage of every melee attack.

That said, we see that even with the simple S queue, Control/Haste pulls ahead.  Not only does it provide better active mitigation when you’re shifting, it provides better passive mitigation through Sacred Shield and “lazy” SotR usage.  Sacred Shield single-handedly turns Control/Haste from an expert’s gearing strategy to one that a novice will be able to use effectively.

And that’s… well, to be honest, it’s a little overpowered.  Broken, even.  As much as I like the haste gearing strategy, it does seem like it’s too good to be true.  Maximum DPS in conjunction with maximum survivability through a stat that is not traditionally desired by tanks is a bit lopsided, and part of the reason we saw changes to Grand Crusader in 5.2.  Were the developers blinded the same way we have been by not including Sacred Shield in our models? I don’t know, obviously, but it seems strong enough that I could believe it wasn’t intended.

And of course, there’s an even more important question from our perspective:  is this interaction is something that, now that the cat is out of the bag, will end up drawing their attention and call down the nerf bat?

And the corollary: can we stack enough haste to outrun it?

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

Control Shift En-tier

Posted on March 19, 2013 by Theck

About a week ago, Wrathblood asked me to take a more thorough look at the Tier 15 2-piece bonus. The earlier simulations I ran were based on a lower-ilvl gear set (496) which was more constrained in its itemization, and only considered the Control/haste gearing strategy. He suggested that the extra itemization afforded by higher-ilvl gear may have effects that we didn’t anticipate, as might the more extreme values of haste and mastery we’re pushing in the ilvl 522 gear sets because of the relaxed parry/dodge constraints. And of course, it’s not hard to imagine that a Control/Mastery build might interact more strongly with a block-based set bonus.

Even if the results don’t end up making the 2-piece an amazing bonus, it’s good to cover more of the parameter space. Better to have data and know what you’re dealing with than to guess and make blind assumptions, especially when the data isn’t hard to generate.

In addition, Mel and I have been discussing a few of the more significant limitations of our earlier simulations. One of them was our SotR model. It’s not clear how exceptional you need to be to effectively pull off the time-shifting hijinks that we suggested in the 5.2 Smoothness post. But it’s also probably not realistic to model it as if it were macro’ed to Crusader Strike. It would be tough to come up with a happy middle ground, but it’s not that hard to make some basic tweaks to improve the SotR usage model. So that’s exactly what I did.

I’ve introduced a new “Shift” finisher queue that tries to intelligently shift the usage of SotR around to react to spikes. The queue, which we’ll call “SH” will cast SotR when either of the following conditionals is satisfied:

  1. We have 5 holy power and a generator is available within the next second
  2. We have 3+ holy power and the mean of the last N boss attacks is greater than 80% throughput.

The first condition is the bleed valve, and taken in isolation gives identical results to the simple “spam SotR whenever you have 3 holy power” model we’ve been using in previous sims, also known as the “S” rotation. It’s only purpose is to make sure we don’t end up wasting holy power, and bleed it in the safest way possible.

The second condition is the one that acts as a spike filter. Maximum throughput in the simulation is a string of full hits, which looks like (1, 1, 1, 1, 1, 1, …). This filter just looks at the last N attacks, takes the average, and compares it to 0.8.

So for example, if I set N=1 (an “SH1″ queue) it filters based on only the last attack, and will use SotR (if possible) any time we take a full hit. It wouldn’t use SotR if we blocked the previous attack, because that only registers as 0.7 damage, nor if we mitigated it with an existing SotR or avoided it. It doesn’t look at any attacks beyond the previous one, however. You can probably already guess that this means it’ll be a short-spike filter.

If instead we used N=2 (“SH2″), then it would look at the mean of the last two attacks. So for example, it will try to cast SotR if we take two full hits (because $\frac{1+1}{2}=1$, which is >0.8), or one hit and one block ($\frac{1+0.7}{2}=0.85$, which is >0.8), but not two blocks (mean of 0.7) or any other combination.

We could, of course, set N higher than 2 if we wanted to defend only against extremely high spikes. However, by N=3 we’re already looking at 4.5 seconds, and it only takes 5.5-7.5 seconds to generate 3 holy power depending on your haste level. By N=3 or N=4 we’re already almost guaranteed to trigger the bleed valve condition during our filter period, which means we’re not very likely to see events that exceed 0.8 in the first place. As N increases, the filter gets engaged less frequently and the results should tend towards the “S” rotation.

We could also change the threshold level from 0.8 to something else, if we wanted to. The lower we set it, the more frequently it will engage, and if we set it too low it will just fire any time we don’t avoid N attacks. If we set it higher than 0.8, we limit the filter’s trigger condition to strings of full hits. I’ve chosen 0.8 specifically so that hit+block combinations trigger the conditional for N=2, but a single block won’t trigger it for N=1. We can explore the effects of changing this threshold condition in a later blog post.

Later this week, we’ll see how this shift queue performs with all of the gear sets we’ve compiled. Today, we’re just going to see how it performs with the Control/Haste and Control/Mastery gear sets, alongside the queues we tested in the last round of T15 2-piece simulations. Thus, a quick review of the T15 2-piece finisher queues is in order:

  • “T” (for “tier bonus”) will use WoG any time the tier bonus buff drops off, as well as if we hit 5 holy power so that we don’t waste anything.
  • “TS” tries t0 keep the tier bonus up at all times and uses SotR as a bleed mechanism. The logic is to cast WoG every time the tier buff drops off and only cast SotR when we’re at 5 holy power.
  • “ST” is a “first come, first serve” style rotation that tries to keep something up at all times, whether it’s SotR or the tier 15 set bonus. It will prioritize SotR over the tier bonus. The logic is roughly “if neither buff is up and HP>=3, cast SotR; if neither buff is up and HP<3, try to cast WoG.”

As a reminder, here are the stats for the Control/Haste and Control/Mastery gear sets:

|    Set: |  C/Ha |  C/Ma |
|     Str | 15000 | 15000 |
|   Parry |  1500 |  1500 |
|   Dodge |  1500 |  1500 |
| Mastery |  1500 | 13500 |
|     Hit |  2550 |  2550 |
|     Exp |  5100 |  5100 |
|   Haste | 12000 |     0 |
|   Armor | 65000 | 65000 |

Control/Mastery Gear Set

The mastery set runs a whopping 30.5% mastery, pushing SotR’s mitigation up to 60.5%; that’s as potent as a warrior’s critical block. Speaking of blocking, it also packs an impressive 41% block, though that gets knocked down to 36.5% against a boss. The downside is that we have 0% haste in this gear set, so our holy power generation is capped at around 0.41 HP/sec. There’s an inherent trade-off here – timing SotR will give you a strong effect, but the lower uptime of SotR means that we can’t cover as many attacks.

As before, we need to specify how much overheal we expect WoG to generate to properly evaluate the queues that include WoG. We’ll start with 100% overheal (meaning WoG itself does essentially nothing for you), and then look at the 50% and 0% overheal cases.

WoG overheal factor: 100%

| Queue: |       S |     SH1 |     SH2 |       T |      TS |      ST |
|     S% |  0.4101 |  0.4101 |  0.4105 |  0.0000 |  0.2126 |  0.2360 |
|   mean |  0.5417 |  0.5429 |  0.5423 |  0.6231 |  0.5433 |  0.5375 |
|    std |  0.1449 |  0.1325 |  0.1253 |  0.1455 |  0.1513 |  0.1475 |
| ------ |   --- 2 |  Attack |  Moving | Average |  ------ |  ------ |
|    60% | 42.3010 | 46.7672 | 42.9268 | 65.4025 | 48.0190 | 46.1590 |
|    70% | 21.9970 | 17.6668 | 19.5328 | 27.2403 | 18.5732 | 17.6793 |
|    80% | 21.9970 | 17.6668 | 19.5328 | 27.2403 | 18.5732 | 17.6793 |
|    90% | 10.2610 |  5.6763 |  8.4748 |  3.6463 |  2.4868 |  2.3977 |
| ------ |   --- 3 |  Attack |  Moving | Average |  ------ |  ------ |
|    60% | 32.7568 | 27.8945 | 33.7280 | 54.9875 | 36.7665 | 34.8075 |
|    70% | 18.2605 | 13.4463 | 13.9110 | 29.3353 | 17.6935 | 16.4103 |
|    80% |  7.4737 |  4.4705 |  1.7305 |  7.4543 |  4.3247 |  3.9830 |
|    90% |  2.7365 |  1.2675 |  0.6405 |  0.6740 |  0.4245 |  0.3802 |
| ------ |   --- 4 |  Attack |  Moving | Average |  ------ |  ------ |
|    60% | 33.9690 | 31.9660 | 31.7003 | 48.5408 | 30.4235 | 29.5403 |
|    70% | 12.5495 |  8.7740 |  4.0938 | 28.7690 | 15.3175 | 13.7128 |
|    80% |  5.2840 |  3.4635 |  1.2557 | 10.2150 |  5.0597 |  4.4720 |
|    90% |  1.2183 |  0.7810 |  0.2188 |  1.8105 |  0.9160 |  0.7803 |
| ------ |   --- 5 |  Attack |  Moving | Average |  ------ |  ------ |
|    60% | 39.1620 | 36.9288 | 35.6007 | 61.8642 | 36.6945 | 35.0003 |
|    70% | 10.6135 |  8.7673 |  6.9117 | 27.4010 | 12.7738 | 10.9168 |
|    80% |  1.4990 |  1.3630 |  0.3220 | 11.7240 |  4.7525 |  3.8885 |
|    90% |  0.0000 |  0.0375 |  0.0000 |  0.4228 |  0.1762 |  0.1425 |
| ------ |   --- 6 |  Attack |  Moving | Average |  ------ |  ------ |
|    60% | 35.8623 | 32.9168 | 32.5135 | 58.4110 | 35.6808 | 33.3798 |
|    70% | 11.1083 |  8.5260 |  7.2780 | 26.0475 | 10.6435 |  8.5690 |
|    80% |  0.0000 |  0.1315 |  0.0095 |  4.1433 |  1.3693 |  1.0128 |
|    90% |  0.0000 |  0.0000 |  0.0000 |  0.0948 |  0.0305 |  0.0248 |
| ------ |   --- 7 |  Attack |  Moving | Average |  ------ |  ------ |
|    60% | 32.3012 | 29.1515 | 29.4353 | 55.0732 | 31.1550 | 28.9513 |
|    70% |  9.7462 |  7.2493 |  4.8043 | 24.8360 |  8.8652 |  6.8185 |
|    80% |  0.8013 |  0.5012 |  0.2617 |  5.0090 |  1.2965 |  0.8367 |
|    90% |  0.0000 |  0.0000 |  0.0000 |  0.2248 |  0.0468 |  0.0355 |

First, let’s consider the shifting queues. Both show a distinct improvement over the S queue, suggesting that timing SotR casts really does make a difference in spike representation. SH1 does the best job at eliminating 2-attack spikes, which makes sense since it’s a short-spike filter. While it outperforms S across the board, it falls behind SH2 for 3+ attacks, suggesting that SH2 is probably the stronger of the two queues overall for a mastery gear set. It’s also worth noting the magnitude of the improvement: compared to S, we’re getting a 40%-80% reduction in some of the spike categories, especially in the important 4- to 5-attack regime. That’s not a trivial gain for a reasonably simple time-shifting algorithm.

As in the last round, the T queue is pretty much garbage. The set bonus isn’t strong enough to stand on its own, so it’s not worth spamming WoG in an attempt to keep the buff up 100% of the time.

The TS queue doesn’t perform all that poorly compared to S, even showing a pretty significant improvement for 2-3 attacks. But it only manages to match the performance of S for 4 attacks, and lags a bit in the 5+ attack categories. When compared to SH2, it falls significantly behind in nearly every metric.

A similar story could be told about ST, which performed reasonably competitively in the last round of testing. It can hold its own against S, but falls behind SH2 by a significant margin. At 100% overheal on WoG, there’s just no situation where the set bonus seems to give a clear survivability advantage.

Let’s see what happens when WoG’s overheal is cut to 50%.

WoG overheal factor: 50%

| Queue: |       S |     SH1 |     SH2 |       T |      TS |      ST |
|     S% |  0.4104 |  0.4105 |  0.4104 |  0.0000 |  0.2122 |  0.2356 |
|   mean |  0.5420 |  0.5408 |  0.5413 |  0.5551 |  0.4898 |  0.4989 |
|    std |  0.1449 |  0.1333 |  0.1256 |  0.1373 |  0.1484 |  0.1373 |
| ------ |   --- 2 |  Attack |  Moving | Average |  ------ |  ------ |
|    60% | 42.3070 | 46.4395 | 42.8245 | 49.6615 | 36.9973 | 39.7920 |
|    70% | 22.0145 | 17.4175 | 19.5012 | 17.5070 | 14.1575 | 16.2463 |
|    80% | 22.0145 | 17.4175 | 19.5012 | 16.0098 | 13.2680 |  8.5230 |
|    90% | 10.2410 |  5.6247 |  8.3945 |  2.1725 |  1.7857 |  1.7715 |
| ------ |   --- 3 |  Attack |  Moving | Average |  ------ |  ------ |
|    60% | 32.7285 | 27.4853 | 33.6465 | 39.5823 | 29.2448 | 31.4512 |
|    70% | 18.2455 | 13.2448 | 13.8183 | 15.8858 | 12.2385 | 14.6877 |
|    80% |  7.5020 |  4.3853 |  1.7138 |  3.3298 |  2.6967 |  3.4908 |
|    90% |  2.7553 |  1.2767 |  0.6318 |  0.2680 |  0.2367 |  0.3100 |
| ------ |   --- 4 |  Attack |  Moving | Average |  ------ |  ------ |
|    60% | 34.1212 | 31.4797 | 31.5030 | 33.3507 | 23.0412 | 26.3468 |
|    70% | 12.5640 |  8.6035 |  4.0767 | 13.8833 |  9.7470 | 10.6955 |
|    80% |  5.2990 |  3.4830 |  1.2605 |  3.5175 |  2.4328 |  2.1993 |
|    90% |  1.2255 |  0.7878 |  0.2120 |  0.3693 |  0.3953 |  0.0762 |
| ------ |   --- 5 |  Attack |  Moving | Average |  ------ |  ------ |
|    60% | 39.3628 | 36.3190 | 35.3318 | 40.4225 | 23.0955 | 23.1992 |
|    70% | 10.6638 |  8.7133 |  6.8473 | 12.2817 |  7.4853 |  7.0390 |
|    80% |  1.5003 |  1.3500 |  0.3285 |  1.0110 |  1.5378 |  0.7823 |
|    90% |  0.0000 |  0.0498 |  0.0000 |  0.0462 |  0.0590 |  0.0290 |
| ------ |   --- 6 |  Attack |  Moving | Average |  ------ |  ------ |
|    60% | 35.9303 | 32.3367 | 32.2488 | 40.4633 | 21.5243 | 21.2708 |
|    70% | 11.0507 |  8.3502 |  7.1970 | 11.1772 |  5.5295 |  4.5475 |
|    80% |  0.0000 |  0.1467 |  0.0110 |  0.6997 |  0.4557 |  0.3740 |
|    90% |  0.0000 |  0.0000 |  0.0000 |  0.0037 |  0.0077 |  0.0067 |
| ------ |   --- 7 |  Attack |  Moving | Average |  ------ |  ------ |
|    60% | 32.3418 | 28.5257 | 29.1668 | 35.7612 | 18.7482 | 18.8182 |
|    70% |  9.7500 |  7.1750 |  4.7520 | 10.0488 |  3.8830 |  2.9875 |
|    80% |  0.8268 |  0.4840 |  0.2512 |  0.7990 |  0.2135 |  0.1840 |
|    90% |  0.0000 |  0.0000 |  0.0000 |  0.0005 |  0.0028 |  0.0008 |

The S, SH1, and SH2 data doesn’t change here outside statistical fluctuations. The T queue is still a lot less garbage-y now, arguably matching the performance of S for shorter strings. It still loses ground for 6- to 7-attacks, however.

TS and ST show a fairly significant improvement over S across the board. But neither is clearly superior to our new gold standard, the SH2 queue. They generally outperform the shift queues for 2 attacks, but it’s questionable how much we really worry about 2-attack strings, since most bosses don’t melee you for 400k or more. SH2 tends to beat them in the 3- to 5-attack categories, but falls behind again at 7 attacks. All in all I think it’s pretty much a three-way tie between SH2, TS, and ST at this point.

So if WoG’s giving you 50% overheal, gaming the new set bonus buy syou a small improvement over just spamming SotR (“S”), but it’s not a clear improvement over just sticking with SotR and being careful with your timing (“SH”).

Let’s crank WoG up to maximum effectiveness and look at the 0% overheal data:

WoG overheal factor: 0%

| Queue: |       S |     SH1 |     SH2 |       T |      TS |      ST |
|     S% |  0.4108 |  0.4102 |  0.4105 |  0.0000 |  0.2121 |  0.2360 |
|   mean |  0.5412 |  0.5416 |  0.5422 |  0.5022 |  0.4465 |  0.4597 |
|    std |  0.1451 |  0.1328 |  0.1252 |  0.1373 |  0.1490 |  0.1337 |
| ------ |   --- 2 |  Attack |  Moving | Average |  ------ |  ------ |
|    60% | 42.2155 | 46.5763 | 42.8827 | 38.5640 | 33.1002 | 27.4115 |
|    70% | 21.9353 | 17.4630 | 19.5302 | 15.8348 | 12.1708 |  9.5460 |
|    80% | 21.9353 | 17.4630 | 19.5302 | 15.8348 | 11.4650 |  7.9205 |
|    90% | 10.2748 |  5.5675 |  8.4910 |  2.1077 |  1.6105 |  0.9662 |
| ------ |   --- 3 |  Attack |  Moving | Average |  ------ |  ------ |
|    60% | 32.6512 | 27.6415 | 33.6860 | 26.2135 | 21.5578 | 20.9620 |
|    70% | 18.2035 | 13.2302 | 13.8877 | 11.5970 |  9.2747 |  6.9993 |
|    80% |  7.4228 |  4.3803 |  1.7488 |  2.8165 |  2.1900 |  1.2845 |
|    90% |  2.7748 |  1.2550 |  0.6620 |  0.2760 |  0.2053 |  0.1045 |
| ------ |   --- 4 |  Attack |  Moving | Average |  ------ |  ------ |
|    60% | 33.8680 | 31.6200 | 31.6953 | 18.7090 | 14.8930 | 17.8592 |
|    70% | 12.4778 |  8.6483 |  4.0650 |  7.2133 |  6.1665 |  4.8243 |
|    80% |  5.2785 |  3.4120 |  1.3058 |  2.0125 |  1.8793 |  0.4870 |
|    90% |  1.2040 |  0.7582 |  0.2240 |  0.3785 |  0.2710 |  0.0468 |
| ------ |   --- 5 |  Attack |  Moving | Average |  ------ |  ------ |
|    60% | 39.2205 | 36.6190 | 35.4823 | 28.2785 | 14.6325 | 14.4177 |
|    70% | 10.5500 |  8.6173 |  6.9608 |  4.3925 |  3.8047 |  2.8465 |
|    80% |  1.4735 |  1.3350 |  0.3348 |  0.6145 |  0.8670 |  0.2318 |
|    90% |  0.0000 |  0.0425 |  0.0000 |  0.0210 |  0.0413 |  0.0017 |
| ------ |   --- 6 |  Attack |  Moving | Average |  ------ |  ------ |
|    60% | 35.7910 | 32.5177 | 32.3367 | 23.0938 | 13.8513 | 11.4323 |
|    70% | 11.0220 |  8.3745 |  7.3345 |  3.6457 |  2.1958 |  1.4570 |
|    80% |  0.0000 |  0.1320 |  0.0105 |  0.0703 |  0.1385 |  0.0610 |
|    90% |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0025 |  0.0003 |
| ------ |   --- 7 |  Attack |  Moving | Average |  ------ |  ------ |
|    60% | 32.2383 | 28.7430 | 29.3895 | 19.1578 |  9.9872 | 10.3063 |
|    70% |  9.6973 |  7.1182 |  4.8477 |  3.2942 |  1.3065 |  0.7248 |
|    80% |  0.8415 |  0.5030 |  0.2890 |  0.0478 |  0.0342 |  0.0128 |
|    90% |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |

Here we finally start to have a real competition. The raw healing power of WoG is enough to tip the scales a bit, such that even the T rotation is competitive. It flat-out beats the simple S queue, and does a reasonable job of competing with SH2. It edges out SH2 for longer (5+ attacks) and shorter (2 attacks) strings, though it trails ever so slightly in the 4–attack category.

TS and ST fare about the same, outperforming SH2 in a number of categories but trailing in isolated spots, especially in the 4-attack range. ST seems to have pulled ahead of TS enough to be strictly superior in all categories. Overall one could make the argument that either TS or ST is competitive enough to be pereferable to even SH2 at this point. the fact that they beat out S by a pretty handy margin is notable for tanks that aren’t trying to micromanage SotR – mixing some WoGs in to maintain the buff may be a net gain for those players.

It’s also worth noting that at 50% and 0% overheal, the WoG queues beat out the S and SH queues in total damage reduction (TDR) by a large amount. TS and ST offer a whopping 17% reduction in total damage taken. Remember though, most of that effectiveness is coming from WoG, not the set bonus.

So, much as we saw last time, queues that leverage the power of the T15 2-piece set bonus don’t become truly competitive until WoG is operating near maximum efficiency. We’ll talk more about what this means shortly, but first let’s look at how things change for a Control/Haste gear set.

Control/Haste Gear Set

The haste gear set shifts to the opposite extreme. We only have a meager 10.5% mastery, giving 19.5% block chance against a boss and 40.5% SotR mitigation. However, we’ve piled on the haste – 28.24% of it, to be exact, and we’ll reap the benefit of that by having significantly higher holy power generation. In this gear set, HPG caps out around 0.52 per second. If you recall the last smoothing post, we posited that this extra 28% uptime on SotR would make a bigger impact on the shifting queues than the extra 20% mastery would. Let’s see if we were right.

Again, we start with the 100% overheal data:

WoG overheal factor: 100%

| Queue: |       S |     SH1 |     SH2 |       T |      TS |      ST |
|     S% |  0.5228 |  0.5225 |  0.5226 |  0.0000 |  0.3242 |  0.3530 |
|   mean |  0.6010 |  0.6015 |  0.6016 |  0.6652 |  0.5773 |  0.5749 |
|    std |  0.1479 |  0.1342 |  0.1418 |  0.1562 |  0.1496 |  0.1470 |
| ------ |   --- 2 |  Attack |  Moving | Average |  ------ |  ------ |
|    60% | 46.3575 | 47.4338 | 46.0037 | 65.5367 | 47.2860 | 46.8760 |
|    70% | 40.7343 | 43.3862 | 40.4728 | 42.3603 | 30.2638 | 29.2868 |
|    80% | 14.6405 | 10.0218 | 14.2113 | 42.3603 | 22.0120 | 20.4937 |
|    90% |  9.9078 |  4.4075 |  9.4393 | 10.8740 |  5.6080 |  5.2313 |
| ------ |   --- 3 |  Attack |  Moving | Average |  ------ |  ------ |
|    60% | 53.7650 | 54.0125 | 54.2755 | 59.2830 | 46.6840 | 46.6097 |
|    70% | 37.0855 | 36.8943 | 37.0173 | 41.9015 | 26.6883 | 26.2925 |
|    80% | 15.1855 |  7.4750 | 14.6333 | 19.1935 |  9.7335 |  9.0783 |
|    90% |  1.2980 |  0.4585 |  0.0008 |  3.6005 |  1.3678 |  1.2080 |
| ------ |   --- 4 |  Attack |  Moving | Average |  ------ |  ------ |
|    60% | 53.8647 | 52.9630 | 55.3687 | 57.4893 | 46.3350 | 46.0938 |
|    70% | 32.2542 | 26.9342 | 32.2070 | 40.2890 | 23.4513 | 23.4288 |
|    80% |  3.3598 |  2.0602 |  0.0017 | 23.0570 |  8.0365 |  7.2527 |
|    90% |  0.0000 |  0.0730 |  0.0000 |  8.0308 |  2.1803 |  1.6980 |
| ------ |   --- 5 |  Attack |  Moving | Average |  ------ |  ------ |
|    60% | 55.5468 | 55.8940 | 56.7255 | 71.8725 | 46.1725 | 45.1663 |
|    70% | 28.6008 | 25.7090 | 26.9973 | 39.7900 | 21.4207 | 21.0795 |
|    80% |  8.9258 |  5.0655 |  7.0110 | 23.4135 |  6.1088 |  4.8078 |
|    90% |  0.0000 |  0.0000 |  0.0000 |  3.2043 |  0.6520 |  0.4323 |
| ------ |   --- 6 |  Attack |  Moving | Average |  ------ |  ------ |
|    60% | 54.1748 | 56.6675 | 55.0505 | 69.3145 | 44.5780 | 44.0457 |
|    70% | 24.2147 | 23.5965 | 23.1848 | 39.8963 | 19.3180 | 18.5075 |
|    80% |  4.2663 |  2.4810 |  3.3905 | 13.6180 |  3.6472 |  3.0048 |
|    90% |  0.0000 |  0.0000 |  0.0000 |  1.2370 |  0.1580 |  0.0800 |
| ------ |   --- 7 |  Attack |  Moving | Average |  ------ |  ------ |
|    60% | 53.0793 | 55.0057 | 53.8088 | 67.3342 | 45.6855 | 44.9018 |
|    70% | 22.6185 | 20.2733 | 21.7108 | 40.0643 | 16.8960 | 15.8635 |
|    80% |  3.8282 |  2.0460 |  2.8815 | 15.1383 |  2.0480 |  1.4508 |
|    90% |  0.0000 |  0.0000 |  0.0000 |  2.3283 |  0.0700 |  0.0250 |

The behavior of SH1 and SH2 is a little different here. With the mastery gear set, we saw SH2 dominate in all categories except for the 2-attack range. However, with the haste gear set SH1 seems to be doing the dominating. This is mostly due to having faster holy power generation – 0.52 HP/sec compared to 0.41 HP/sec for the mastery set. That drops your mean SotR time from 7.3 seconds to 5.8 seconds, and as I mentioned in the introduction, faster holy power generation makes higher-N queues less efficient. We now have enough HPG to be a little riskier with our reaction filter, because we’re generating holy power fast enough that the downtime is only going to be about 2 boss swings.

This is also the cause of the curious data in the 4-attack category, which is the one place that SH1 clearly falls behind SH2 (at least, for 80 and 90% spikes). Because the downtime of SotR is 2 boss swings, the SH1 becomes a little more vulnerable to 4-attack strings thanks to the “2 on, 2 off” pattern of SotR. SH2 is a little more conservative with its SotR usage, and thus covers that particular case a little more effectively.

How does the improvement from S to SH compare to what we saw in the mastery set? Well, it’s… about the same, actually. We see a lot of the same 30%-50% drops going from S to SH, with larger reductions in a few categories. But it’s not a strong victory for haste over mastery like we predicted.

Part of the problem is that haste’s strength comes from shaving off the top category – it’s good at combating 80% and 90% spikes, but it doesn’t do as much for 60% or 70% spikes. But the default S queue already eliminates most of the 90% categories for the haste gear set, so there’s no more room for improvement there. The 80% categories still show large gains, but not larger than the mastery data showed. And in the 60% and 70% categories, the time-shifted queues tend to show less improvement with the haste gear than the mastery gear. So it’s not clear that there’s a large untapped well of survivability that one can draw from with this simple shifting model.

Moving on to the WoG queues, you could probably have guessed this but… yes, the T queue is still garbage at 100% overheal.

TS and ST both perform fairly similarly, doing a better job of suppressing 60%-70% spikes than the S or SH queues, but lagging in the 80%-90% categories. Just as in the last round of simulations, this has to do with the damage profile of each distribution. TS and ST have a broader profile with a longer tail, while S (and SH) suppress the long tail at the expense of shifting the mean of the distribution to higher spike levels. I won’t reprise the plots here, because they look pretty much the same as last time, so you can take a look at the last post to see example graphs.

Short version: at 100% overheal, the set bonus still doesn’t seem to be worth prioritizing for a haste gear set.

Onwards and upwards (for WoG anyway); the 50% overheal data beckons:

WoG overheal factor: 50%

| Queue: |       S |     SH1 |     SH2 |       T |      TS |      ST |
|     S% |  0.5226 |  0.5224 |  0.5232 |  0.0000 |  0.3242 |  0.3532 |
|   mean |  0.6008 |  0.6006 |  0.6005 |  0.5745 |  0.5339 |  0.5391 |
|    std |  0.1481 |  0.1348 |  0.1423 |  0.1489 |  0.1422 |  0.1393 |
| ------ |   --- 2 |  Attack |  Moving | Average |  ------ |  ------ |
|    60% | 46.3222 | 47.3290 | 45.7760 | 53.1528 | 39.7963 | 41.6880 |
|    70% | 40.7070 | 43.2488 | 40.2820 | 25.5638 | 23.9830 | 23.3118 |
|    80% | 14.6335 | 10.0162 | 14.0865 | 19.8077 | 15.3640 | 11.3565 |
|    90% |  9.8972 |  4.3823 |  9.3970 |  5.0638 |  3.8420 |  2.9267 |
| ------ |   --- 3 |  Attack |  Moving | Average |  ------ |  ------ |
|    60% | 53.7365 | 53.8780 | 54.0440 | 46.7885 | 39.3038 | 40.0625 |
|    70% | 37.0468 | 36.7013 | 36.7800 | 24.0000 | 19.6335 | 18.7733 |
|    80% | 15.1913 |  7.3915 | 14.5518 |  7.0505 |  6.0220 |  5.0628 |
|    90% |  1.3120 |  0.4600 |  0.0023 |  0.7963 |  0.6673 |  0.5020 |
| ------ |   --- 4 |  Attack |  Moving | Average |  ------ |  ------ |
|    60% | 53.8390 | 52.8623 | 55.0905 | 41.6155 | 36.7965 | 38.4763 |
|    70% | 32.2512 | 26.8493 | 31.8983 | 22.9363 | 15.6793 | 14.8535 |
|    80% |  3.4008 |  2.0172 |  0.0030 |  8.0065 |  3.7687 |  2.8995 |
|    90% |  0.0000 |  0.0720 |  0.0000 |  0.3538 |  0.6822 |  0.2405 |
| ------ |   --- 5 |  Attack |  Moving | Average |  ------ |  ------ |
|    60% | 55.5238 | 55.7700 | 56.4808 | 40.8570 | 34.2160 | 35.9790 |
|    70% | 28.6000 | 25.5805 | 26.7625 | 21.4312 | 12.6945 | 12.0057 |
|    80% |  8.8878 |  4.9570 |  6.9828 |  2.4095 |  1.9552 |  1.7050 |
|    90% |  0.0000 |  0.0000 |  0.0000 |  0.2692 |  0.1355 |  0.0532 |
| ------ |   --- 6 |  Attack |  Moving | Average |  ------ |  ------ |
|    60% | 54.2253 | 56.4615 | 54.6968 | 45.6250 | 32.6095 | 34.4695 |
|    70% | 24.2168 | 23.4888 | 23.0660 | 19.7000 |  9.8537 |  9.8712 |
|    80% |  4.2467 |  2.4075 |  3.3208 |  3.1580 |  1.0467 |  0.6258 |
|    90% |  0.0000 |  0.0000 |  0.0000 |  0.0540 |  0.0168 |  0.0067 |
| ------ |   --- 7 |  Attack |  Moving | Average |  ------ |  ------ |
|    60% | 53.1063 | 54.8103 | 53.4983 | 45.6503 | 31.3818 | 32.3642 |
|    70% | 22.6195 | 20.1075 | 21.6425 | 17.4415 |  7.6185 |  8.1792 |
|    80% |  3.8020 |  1.9550 |  2.9023 |  1.9150 |  0.4410 |  0.2603 |
|    90% |  0.0000 |  0.0000 |  0.0000 |  0.0075 |  0.0013 |  0.0008 |

In this data set, we’re starting to see a clear advantage towards the TS and ST rotations. They’re solidly competing with SH1, and even though they permit more 90% spikes, they more than make up for it with suppression in the 60%-80% categories. T is also in the running now, though there’s no situation where it’s clearly preferable to either of the mixed queues.

It seems that the extra holy power fueling WoG in this gear set is having a significant effect. With this much HPG, we’re able to get a respectable SotR uptime while also taking advantage of the set bonus, which makes it more valuable than it was in the mastery gear set. I think it’s fair to say that ST has a slight lead over all of the competitors this round. Let’s see what’s in store when we crank WoG up to full power:

WoG overheal factor: 0%

| Queue: |       S |     SH1 |     SH2 |       T |      TS |      ST |
|     S% |  0.5225 |  0.5222 |  0.5225 |  0.0000 |  0.3247 |  0.3534 |
|   mean |  0.6003 |  0.6013 |  0.6005 |  0.4974 |  0.5072 |  0.5027 |
|    std |  0.1481 |  0.1344 |  0.1425 |  0.1503 |  0.1445 |  0.1370 |
| ------ |   --- 2 |  Attack |  Moving | Average |  ------ |  ------ |
|    60% | 46.3508 | 47.4428 | 45.8948 | 30.6310 | 34.8588 | 32.9618 |
|    70% | 40.6535 | 43.3518 | 40.3810 | 19.8600 | 22.1415 | 17.7995 |
|    80% | 14.5957 | 10.0767 | 14.1655 | 18.9675 | 14.8998 |  8.9260 |
|    90% |  9.7813 |  4.4400 |  9.4358 |  5.0583 |  3.7705 |  2.0580 |
| ------ |   --- 3 |  Attack |  Moving | Average |  ------ |  ------ |
|    60% | 53.6503 | 53.9720 | 54.0338 | 29.0413 | 31.9298 | 30.9422 |
|    70% | 36.9320 | 36.7185 | 36.8463 | 12.1288 | 15.7963 | 11.7378 |
|    80% | 15.0675 |  7.4773 | 14.6283 |  4.3130 |  5.3172 |  2.4430 |
|    90% |  1.2695 |  0.4752 |  0.0010 |  0.7910 |  0.6440 |  0.1398 |
| ------ |   --- 4 |  Attack |  Moving | Average |  ------ |  ------ |
|    60% | 53.7005 | 52.9335 | 55.2110 | 24.9007 | 30.3105 | 30.3485 |
|    70% | 32.1685 | 26.9200 | 32.0120 |  9.0545 | 11.2550 |  8.7277 |
|    80% |  3.3473 |  2.0720 |  0.0050 |  1.0317 |  2.6930 |  0.8783 |
|    90% |  0.0000 |  0.0697 |  0.0000 |  0.3053 |  0.5988 |  0.0318 |
| ------ |   --- 5 |  Attack |  Moving | Average |  ------ |  ------ |
|    60% | 55.3028 | 55.8280 | 56.5597 | 27.1045 | 28.0080 | 26.2122 |
|    70% | 28.5143 | 25.6930 | 26.8380 |  8.6128 |  8.5400 |  6.5027 |
|    80% |  8.8370 |  5.0570 |  6.9102 |  0.2565 |  1.2795 |  0.5853 |
|    90% |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0813 |  0.0020 |
| ------ |   --- 6 |  Attack |  Moving | Average |  ------ |  ------ |
|    60% | 54.0813 | 56.5700 | 54.7773 | 21.6617 | 24.0912 | 22.7147 |
|    70% | 24.1095 | 23.5930 | 22.9925 |  6.6400 |  6.1165 |  4.4040 |
|    80% |  4.2360 |  2.4580 |  3.3653 |  0.5295 |  0.4777 |  0.1800 |
|    90% |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0047 |  0.0000 |
| ------ |   --- 7 |  Attack |  Moving | Average |  ------ |  ------ |
|    60% | 52.9763 | 54.9205 | 53.4872 | 21.2062 | 23.0325 | 20.7325 |
|    70% | 22.5190 | 20.2357 | 21.5467 |  3.8108 |  4.1210 |  2.7390 |
|    80% |  3.7915 |  2.0220 |  2.8915 |  0.2178 |  0.2122 |  0.0222 |
|    90% |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |  0.0000 |

Again, leveraging the full power of WoG pushes the tier set queues to the forefront. ST in particular has a commanding lead in every category, but TS and T aren’t far behind. Even T is eclipsing the S and SH queues by a fair margin in almost all categories. There’s no question that at 0% overheal, these WoG queues take the lead.

Conclusions

So we’ve waded through a lot of data, but we still haven’t addressed what it means in a practical sense. The shifting queues are obviously a success, and we’ll be seeing more of those later this week to try to get a more complete view of how they impact our gearing. The improvement from S to SH is fairly significant, reinforcing the idea that smart use of SotR will always trump “lazy” usage (i.e. macroing it to Crusader Strike).

Though unfortunately, it doesn’t seem that the haste gear set gives a larger benefit than the mastery gear set in this regard. Mel and I had both expected a more significant drop in the haste gear set, but it never materialized. This could just be a product of how high the uptime on SotR is already; having more uptime to shift around could be more valuable when you have less of it to work with in the first place. Maybe by the time you’re at 40%-50% uptime on SotR, there just may not be that much room for shifting that uptime around.

Or maybe we just under-estimated the interaction of the passive benefit of mastery with the shifting algorithm. A higher block chance may just cause the filter to apply that shifting algorithm more efficiently since it isn’t engaging as often. Or maybe it’s something else I haven’t thought of yet. It’s not entirely clear what interaction is the limiting factor here, but something is certainly doing it.

From this data you might conclude that Control/Mastery has cemented its claim as the dominant survivability gearing strategy for this tier of content. However, haste has one final ace up it’s sleeve, and later this week we’ll see exactly how that hand plays out.

Regarding the Tier 15 set bonus, I’ll echo my sentiment from last time – while the 0% overheal data makes the 2-piece look very impressive, we also need to keep in mind that it’s the least realistic of the simulations. If you’re mindlessly spamming WoG on yourself, you’re guaranteed to waste some of that with overhealing.

And it’s not just our overhealing that counts here. If you WoG yourself to full health right before your healer drops a large heal on you, all of that heal just turned into overheal. And we have to count that against us, because all the healing that WoG performed was irrelevant in that case. We’d have been returned to full health whether we used WoG or not, so we would have gotten more mileage out of a Shield of the Righteous (not to mention the loss of Bastion of Glory stacks).

So what is a realistic estimate of our overhealing with WoG? If we’re following the ST or TS rotations, I’d wager that it’s 50% or more. 20%-30% of it from your own overhealing, and another 20%-30% from overhealing you indirectly cause for your healers. You could probably do better than that if you’re running light on healers for an encounter, but I think that creates more risks than it eliminates. That situation leaves you with fewer backup sources of healing for when things go awry, and increases the time it takes before someone else can react and step in to help.

So under most conditions, I don’t think it’s worth weaving WoGs into your rotation for the sake of the set bonus. The situations where it does make sense to slip WoG in are the ones where it’s nearly guaranteed to not cause overheal – in other words, when we’re already fairly low on health. However, that’s generally a case where we would already be using WoG (often with banked Bastion of Glory stacks) even without the set bonus. In a bizarre situation where you are your only healer, such as soloing old raid content, I think the set bonus might become very attractive because you can guarantee you’ll be in the no-overhealing regime. But I don’t think it’s likely we’ll see that situation in regular old “bring-a-healer-along” raiding.

In short, I still don’t find the 2-piece compelling as a maintenance buff. The optimum usage is dictated more by WoG’s effectiveness than the value added by the extra block chance. The most effective way to make use of the set bonus seems to be to use WoG exactly like we do now: not as a proactive tool (like SotR), but as a reactive tool, an emergency heal for when things get dicey.

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

I can go make a blog in 2 minutes

Posted on March 17, 2013 by Theck

Last week, a few people alerted me to a thread on the official WoW forums in which some players were arguing about the usefulness of AskMrRobot, and in particular its default stat weights.  As loyal readers, you probably already know that I developed those default stat weights.  My response in that forum thread was long and contained quite a bit of discussion about the thought processes that went into those stat weights, and it occurred to me that it would make for a good “quickie” blog post.

Much of this will look familiar to regular readers.  We’ve discussed smoothness at great length.  We’ve talked about raw TDR stat weights.  And we’ve talked about the difficulties of valuating Stamina, and how it’s often better at saving healer mana than TDR stats like dodge and parry are.  The only “new” part is the glimpse at how all of that influences the choice of default stat weights.

I wouldn’t normally post on a Sunday, but this is likely to be a busy week at Sacred Duty, so I wanted to get this up quickly.  Stay tuned for some reasonably large and important blog posts later in the week!

——————————————————————————————————–

More seriously: I don’t usually wade into the official forums, because the signal-to-noise ratio is pretty awful around here, and this thread is no exception.  That said, there’s some particularly pervasive and inaccurate noise being repeated here, so let’s stamp that out.

1. You will never need more stam than what comes on gear. You are not doing heroics this week. It is silly to have such a high default weight for stam. It is silly to gem solid cuts.

I completely disagree, for several reasons.  The first is that you don’t have the proper perspective to make that statement.  Looking at your armory, you’ve cleared a few heroic bosses in 5.0/5.1 content, and cleared all of the normal modes numerous times.  That means you are going into Throne of Thunder with above-average gear for the first few normal modes.  In other words, you may have more than enough stamina on your gear because you overgear the fights.

However, the average raider hasn’t cleared all of the 5.1 content.  They are going into ToT significantly undergeared for even the first few bosses.  And when you are undergeared, your absolute, 100% guaranteed, there-really-is-no-argument-to-be-had-here-so-don’t-even-try stat is STAMINA.  Get the health you need to survive long enough to receive heals.  Period. This is exactly the reason that hard-mode progression tanks stack Stamina early on – to meet the EH checks they run into when running content they significantly undergear.

I’ll note that if you had pulled the last few bosses of ToT in week one, you may have gotten a very different impression.  The first 5 or 6 do not significantly challenge EH, but the last few do.  Even in ~507ish ilvl gear, Lei Shen hits like a truck.  From a random Lei Shen 10N log:

[19:20:35.738] Lei Shen hits Yogurto 163283
[19:20:37.252] Lei Shen hits Yogurto 169082

170k every 1.5 seconds is a lot to deal with on a boss with a lot of movement.  This whole myth of “get enough health to survive 3 attacks and you’re fine” doesn’t cut it, because that’s not how most tank deaths work.  If you die in 2-3 hits, its because you failed a cooldown for something predictable.  What you’re more likely to do is die to a string of 5-6 hits, or 3-4 plus incidental damage or a special, during a period where your healing is interrupted.  And nothing guards against that better than stamina.

2. The best way to reduce stress on healers is by lowering incoming damage. Stamina does not lower incoming damage at all. You take more damage if you forgo tanking stats for stam. The term manasponge came about for a reason. It is not a term of endearment.

This is another falsehood that gets tossed about by inexperienced tanks.  The term “mana-sponge” stopped being relevant somewhere around Burning Crusade.  Yes, a tank stacking Stamina does take more damage than a tank stacking, say, mastery.  Does that make them a worse tank? I’d say that the answer is unequivocally “No.”

If your goal is taking the absolute least damage possible, you should be stacking avoidance.  Pound for pound, avoidance gives more “total damage reduction” (TDR) than any other stat.  You know what our absolute worst TDR stats are? Hit, expertise, and haste.

Yet looking at your armory, you seem to have reforged much of your dodge and parry into hit, expertise, and haste.  So we are confronted with a conundrum: either

1) you think that TDR is something tanks should seek, in which case you are reforging and gemming completely wrong and shouldn’t be giving advice.

Or

2) you don’t think that TDR is worth seeking, and instead gem for “smoothness” stats, but you’re telling people on the forums they should be seeking TDR stats anyway.  In which case you also shouldn’t be giving advice.

The only constant in those two statements is that you really, really shouldn’t be giving advice. :)

The fact is that TDR hasn’t been relevant since BC or Wrath, depending on who you ask.  Potentially very briefly at the beginning of Cataclysm, when healers were undergeared, but that quickly ended once they started acquiring even a little bit of normal-mode raid loot.  Healers simply do not run out of mana healing tanks nowadays, even in 25-man.  They run out of mana for all sorts of other reasons – excessive raid damage being the primary culprit – but if you take any half-decent healer and tell them their only job is to heal any half-decent tank, mana will never be an issue.

What kills tanks is not their healer running out of mana, but running out of time.  Spike damage is what kills tanks, and it’s what has been killing tanks since time immemorial.  Taking a few too many large hits in a row while your healer is distracted, stunned, moving, or what have you.  That is how tanks die.

If you look at most logs, it’s not hard to see the truth in either of these assertions.  Most healers overheal by 30% or more when they heal tanks.  That’s not because they have mana to waste, but because it’s hard to avoid doing so with all of the self-healing and cross-healing going on.  And more importantly, because they have to maintain some level of overhealing to combat spikes, because during a spike that extra throughput becomes immensely valuable, so much so that it’s worth overhealing by 30%-40% most of the time.  Because it means that extra 30%-40% throughput is there during a spike, when it matters.

And if we’ve accepted that spike damage is what’s relevant (well, maybe you haven’t, but I’m going to go out on a limb and assert that it is), then the question of stat priorities gets turned on its head.  All of the sudden, “reliable’ stats start to win out.  Having hit, expertise, and haste ensures higher SotR uptime and thus fewer/smaller spikes.  And what’s the most reliable stat of them all?  STAMINA.  it is there, always, all the time, preventing spikes.  Because having 10% more health makes every spike 10% smaller, and easier to heal.

It’s even worth noting that from a healer’s perspective, stamina is a mana-saving stat.  This talk of “mana sponges” suggests a fairly critical oversight in your thinking.   Healers are not robots or calculators, they’re people.  They heal based on a few factors, and one important one is reacting to changes of your health bar.  A larger health pool does a few things for them: it makes each attack a smaller proportion of that bar, which makes those hits feel less dangerous to the healer (because they are).  it also gives them more time to react, because they’re thinking in terms of percentages of your health bar, not hit points.

More importantly, it lets them plan more effectively.  If they know that the next hit is going to be a relatively smaller portion of your health bar, they cay comfortably start casting their slow heal, or allow that slow heal to finish if they’re mid-cast.  Doing that actually saves them mana in the long run, because they need to cast fewer of their quick, mana-inefficient “panic” heals.  This isn’t even conjecture, by the way – it’s pretty well-established healer theory.

Aside: There are actually a lot of parallels between healer theory and network queuing theory.  It’s one topic I rather enjoy discussing with a colleague of mine who is both a computer engineering professor and a priest healer.  Crazy fun stuff if you’re into that sort of thing.

3. Aggro is something you should never need to worry about. Vengeance does that job for you. If you lose threat to a non tank then its not a gear issue.

On this, at least, we agree.

4. While tank DPS mattering vs not mattering is an argument for another thread, “DPS” stats are most certainly important for a prot paladin. Hit, expertise, haste and mastery help with point 2 in reducing incoming damage more than even dodge or parry. Stamina does not ever help reduce incoming damage. (Keep your bloody DK comments to yourselves)

False.  Flat-out false.  Hit, expertise, haste, and mastery are ALL inferior to avoidance in terms of reducing damage taken.  I have tested this extensively, as have others.  If you’re suggesting all of that work is in error, I encourage you to present your thoroughly-detailed, carefully-tested mathematical models to the community for peer review.  After all, I have, it’s only fair that you do the same.

Stop telling people they need “enough” stam to not get two shot. They already have it.

Stop telling people they already have “enough,” because frankly, they don’t.

Seriously, consider this “average” tank you keep referring to.  First of all, let’s clear up some misconceptions.

1) The average tank is relatively undergeared for normal raid content.  Hence, they are already in a position where stamina is probably (if not definitely) their best stat.  Running LFR doesn’t count, you could run LFR in greens gemmed with spirit and still perform decently well if you had half a clue.

2) Unfortunately, the average tank doesn’t have a clue.  They don’t follow a tight rotation.  They stumble through it, push back holy power generators, and have large amounts of “real-life” latency because they aren’t hitting a spell immediately upon the GCD ending.  They don’t time their SotR according to the boss’ swing timer.  They don’t pool holy power so that they can double-up on SotR during a dangerous spike.  In many cases, they macro SotR to Crusader Strike.  I’ve even seen tanks go a full 20+ seconds hitting NOTHING BUT CRUSADER STRIKE (and, of course, their SotR which was macro’d to Crusader Strike).

The average tank plays considerably below their theoretical potential based on gear.

In short, the average tank is actually pretty terrible.

Now consider that this is the tank AskMrRobot is trying to help.  You cannot rely on them running a proper rotation, so trying to tell them to stack haste and mastery is a waste – they’re not timing SotR to cover boss swings, and in some cases, they’re not getting maximum uptime on SotR.  Giving them more haste often just creates more empty space rather than more ability usage, because they’re used to a 1.5-second GCD from playing other characters and just stick with that inner metronome.

In other words, buffing active mitigation stats for a tank that uses Active Mitigation poorly is not efficient.

What is efficient? Passive mitigation.  Avoidance.  STAMINA.  And to a lesser extent Mastery, thanks to the block component.  These are all stats that are always on, helping the weak tank survive through content they are undergeared (and often under-skilled) for.  When you try and optimize for a player that is guaranteed to screw up a lot, you give them the stats they cannot screw up.

———————————————————-

This was a long post, but if nothing else, here’s what you should take away from it.  You may find that the baseline stats on AMR do not suit you very well.  In most cases, that means one of two things:

1) You’re not running 25-man content, which generally stresses EH more than 10-man content.  I’m not making a 10 vs 25 difficulty argument here, this is simple facts based on tuning.  10-man bosses don’t melee as hard as 25-man bosses because of healer throughput considerations, and smaller hits generally make EH less important.

OR

2) You’re already at a skill or gear level that is above-average.  This may come as a shock to you, because everyone tends to think they’re the “average” tank.  I even think so sometimes, until I look at logs or progression rates.  As such, the “average” settings may not work as well for you.  However, you should also be intelligent and experienced enough to realize this fact, and adjust the stat weights to suit your needs.

I actually heavily de-emphasized stamina in the current set of stat weights compared to what I gave AMR in 5.0/5.1 based on feedback from 10-man raiders.  While I still think that stamina is a GREAT stat in all formats (seriously, I think that even in 10N, more stamina is rarely a bad thing, it’s just often not as useful as more haste thanks to the DPS contribution – but STAM is still the better survivability stat), I recognize that a lot of 10-man players really don’t care for stam stacking that much.  So this time around, the stat weights were chosen such that it favored hybrid haste/stam or exp/stam gems in nearly every non-blue slot.

Lowering the stam weight from 1.5 to 1.3 should shift it into an all-out haste (or mastery) mode that would be appropriate for 10N tanks which are overgearing content or feel comfortable with their current stam level.  I don’t develop AMR, so I can’t modify it to have a stam “cap,” but doing so wouldn’t be a bad option either.  Another possibility is to offer a 10/25 toggle or a different set of weights for 10 vs. 25, but again, that’s up to the people who make the tool.  I just do the math.

Also note: I’m not affiliated with AMR, even if I find their tool incredibly useful in my own work.  I complain about it a lot too, because I think there are areas it could be better.  But I generally make suggestions to them about how to improve it rather than taking a giant dump on the tool on forums, because the latter isn’t very productive.  As Wrathblood said, it’s like hating on a slide rule.

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