I have to agree with Theck for most part. Your "sensible bleed queue" looks to be perfect, but i can't imagine many player being able to perform it with much consistency.
In January Theck posted an excellent set of posts about warrior theorycrafting. It is my intent with this post to allow some discussion that can ensure the next time he revisits the topic he can do it even better.
If you do not care to read really long posts there is no point continuing here.
The canon of theorycrafting by Theck from January this year includes four posts.
With the exception of a bug in how rage spends rage this work is fine. Some mechanics updates for 5.2 means that some small changes will be made, but it is fundamentally a sound basis.
The queues considered and investigated are for the most part queues no tanking warrior would use. While valuable points are still made based on general types of queues it will take some translation to be immediately useful to a tanking warrior. The bulk of this post is dedicated to the production of better actions queues.
This post is very solid in how it is planned and executed. However, it is compromised by using action queues that are not realistic.
This post is a limited examination of revenge given a particular set of fight mechanics. It is not of general interest.
The majority of this post will revolve around Theck's post #2. Also the majority of this post is me simply copying my replies to that thread - while fixing the formatting errors that occurred to make it more readable. While Theck has indicated that he is inclined to take on board a substantial part of my comments - who is to say I'm not wrong? That's the purpose of bringing it to this forum - expose it to a bullshit test. So please, take my comments apart and help provide Theck with the best possible basis for warrior theorycrafting next time he is inclined to take that up.
Initially I commented:
To this Theck repliedI think in this post you’ve largely managed to do some wonderful mathematics on a flawed set of assumptions. I’m not at all surprised that bleed, weave or the combination performs poorly. As a tanking warrior I’ve intuitively understood this from before people started recommending it. If you have committed to using shield block and are looking for ways to spend excess rage on shield barrier for additional total damage reduction bleed and weave are both (imo) intuitively the wrong places to look – both carry great inherent danger of delaying shield blocks.
To spend rage on shield barrier while focusing on shield block there is a completely different set of questions you need to be asking yourself. They all derive from the basic: What factors allow me to spend rage on shield barrier with no or with very little risk of delaying my next shield block? For timing the answer is obvious: Immediately following a shield block when you presumably have 9 seconds to build the 60 rage you need for shield block. For other factors they will be things like berserker’s rage and/or battle shout off cooldown, and shield slam less than 3 seconds from coming off cooldown – revenge you can’t use as a measure – without any dodge/parry based procs you can use it once per 9 seconds, and it’s dangerous to assume anything else. But 4 piece set bonus is a factor – shield block costing 55 rage. So, if I fire off my shield block and chase it immediately with a shield barrier to empty my rage bar (both ofc not on global cooldown) because my shield slam has below 3 seconds left on cooldown – I can use shield slam twice and revenge once (no fail) and have 55 rage ready for the next shield block in time. That means, fully half the time I use shield block I can empty my rage bar on shield barrier as well (as long as I do it before I use my next rage builder).
This can extend into the 9 second window between shield block uses if you take rage into account. For instance 3 seconds in you know you will have at least one shield slam, so if you have 100 rage you can use shield barrier. If you have sword and board proc you can lower that rage requirement by 5. If you have revenge on less than 6 second cooldown you can lower that rage requirement by 15. If you have battle shout off or on less than 6 second cooldown you can lower that requirement by 20. If you have berserker’s rage off or on less than 6 seconds cooldown you can lower that rage requirement by 10. For any given time (on or off global cooldown) you can factor in whether you can afford to fire off a shield barrier now. Neither your weave nor your bleed approximate how this decision tree will play out.
The thing is, even if you use shield block and shield barrier at the same time you will still have some benefit. There’s no reason why that should not be at the very beginning, middle or end of a damage spike. We are, for the most part, considering damage spikes beyond 2 swings (3 seconds) dangerous, no? Intuitively, the first and last 2 seconds of a shield block duration are more likely to be part of the dangerous part of a damage spike than the middle two seconds.
I’m sure you note some similarity in what I’m saying here to what shade mentioned in an earlier comment. I’m just being a little more specific in describing the factors that go into the decision tree instead of mentioning the rather arbitrary 80 rage, 110 rage and “soon” factors.
I also use shield barrier to survive spikes – and normally it’s effective, because you have to consider healer inertia. Healers are looking at whoever needs healing so they’ll often be looking at someone else when you need heals the most – if I end up at sub-30% health, put up a 500k shield barrier absorb to keep myself alive my health is very visibly low. Even if the dmg spike is sustained the time which I spend at below 30% will make sure that more and more healers are shooting heals (and their own absorbs) my way. It is one case where in the moment the sub-optimal dmg spike prevention is superior. The absorb makes me safe enough for long enough that healers will take up the slack (just as they would if there were known and anticipated spikes like breath or thrash or focused assault that need a bit of extra healing oomph)
With regards to overwriting shield barriers already up, there are multiple factors. You have touched on some of them, but a dominant one is whether according to the decision tree I have alluded to above this is a good time to use shield barrier. Sometimes I overwrite one with half or better of the capacity unused to avoid capping out on rage, other times I make the decision that I can afford to use shield barrier AND I can afford to wait until the current one is gone. (ShieldHealth is a fantastic addon btw)
Also reminder: Shield barrier does not use just 20, 40 or 60 rage. See my comment on part 1 of this series.
Here I replied twice, splitting the discussion into two directions. I will complete the first thread before starting the second. I will also fix the formatting that went wrong (and hope this forum can handle it)Regarding Shield Barrier timing: there’s a school of thought (which I happen to agree with) that it’s better to stagger your mitigation. Popping, e.g., Shield Barrier 1 second after casting Shield Block will give you more total damage reduction than not using SBarr at all, but it doesn’t significantly increase your spike prevention. You’re stacking more mitigation on a high-mitigation period, which is generally less effective than just having more high-mitigation phases overall. See, for example, paladins and the haste vs. mastery discussion.
In this case, that means one of two things: You either pop SBarr as you describe, shortly after a SBlock cast while having enough of a rage bank that you don’t risk pushing the next SBlock back (i.e. a “bleed” threshold), or you just implement the bleed valve without worrying about SBlock status. Both should be relatively similar in effectiveness for TDR, but the “bleed” version should generally be better at mitigating spikes because some of those Barrier casts will fall into those 3-second gaps.
It’s also worth noting that the problem with any of the bleed/weave queues is simply rage starvation. Even at hit/exp caps, you simply don’t have enough rage generation to pop out a 60 rage Barrier without delaying Shield Block. So it always comes down to a trade-off between “more mitigation now” via SBarr or “smoother mitigation overall” with SBlock.
More complicated decision trees are obviously something we could try, but it quickly becomes cumbersome to try too many of them because the parameter space gets pretty big. Another thing I’d like to try is to base usage off of instantaneous damage intake – for example, we’re using a Markov approximation here by ignoring what’s happening on the intake side. But you could imagine adding a “if damage in the last N swings exceeds X” conditional in your SBarr usage, which would help bias the decision towards mitigating spikes and pooling rage if you’re already “safe.”
That said, I’m already working under the assumption that a smart warrior uses Shield Barrier to respond to a spike rather than blindly spamming Shield Block all the time. The code is determining the optimal steady-state rotation for minimizing the number of those spikes you encounter. When something dangerous happens, it’s expected you’ll go “off-script” and dig into your toolkit to survive better.
Regarding the discretization of SBarr: I wasn’t aware the ability worked that way, but it would be easy to fix in the simulation. That said, it won’t have a large effect on the results. Stochastically, it should all average out. If anything it may make use of Shield Barrer at <60 rage even worse, simply because there's no chance of retaining 10-15 rage by missing a threshold value.
Theck replies“Regarding Shield Barrier timing: there’s a school of thought (which I happen to agree with) that it’s better to stagger your mitigation.”
While I do agree with this school of thought I think the mechanics and rage economy of the warrior class makes this less true for the warrior. Or indeed, perhaps not true at all. Particularly, if we assume a 2 attack spike is not sufficient to be a threat to a tank, the shield block gap goes from being a critically important period of no mitigation to a reasonably important period of low mitigation.
Anyway, above all I must apologize for entering the discussion so late – because I feel the real issue is that you have chosen to model finisher queues that are unsuitable. So you now have an investment in queues that have given you results that you are naturally inclined to value. And I’m sitting here rooting for you to dismiss them and maybe use some other queues instead.
Additionally, if my feedback had been timely I would have strongly suggested you take into account the T14 4 piece set bonus. Now that we have T15 to look forward to that becomes a matter of vanishingly small importance.
I think the most productive thing I can do is run a critique of each proposed queue and argue for use or dismissal – and give a detailed description of any additional queues I think should be used.
Part one queues:
(shield block only queues)
SB – This queue uses less rage than it gains – this queue should be dismissed because noone would ever play this way and sit on overflowing rage and never use it.
In conclusion, I do not think we should have any shield block only queues (unless we’re working with a rage starved tank)
(shield barrier only queues)
SBr – does use all the rage – but it overwrites shield barriers uncritically. Considered overwriting might be appropriate, but uncritical is not. Should be dismissed
SBr* – this a simplistic fix to SBr that makes it immediately usable – because rage capping is not a concern.
SBr60 – should be dismissed. If you mainly use Shield Barrier there is no reason why you would ever sit on your rage and wait to get to 60. You get the same absorb per rage, but the only thing you achieve by waiting for rage is making your dmg more spikey.
SBr60* – should be dismissed for the same reason SBr60 should.
In conclusion, I do think we need a shield barrier only queue – but just one. SBr* is it, as long as rage generation is low enough that rage capping cannot occur even when shield barrier decays due to a string of misses.
Part two queues:
We need queues that aim for optimal total shield block coverage over the course of the fight – one that tries to do this without delaying any shield blocks so every gap between shield blocks is 3 seconds (bleed), and one that allows that gap to increase and investigates if filling it with shield barriers makes for better spike prevention (weave).
Basic idea is shield block uptime optimal with excess rage bled into shield barriers.
B-100, B-105, B-110 – these queues allow allow shield block to be delayed up to 6 seconds if you use shield barrier a fraction of a second before shield block comes off cooldown and after just having used shield slam (if revenge, berserkers rage and battle shout are on a longer cooldown). Because they allow a 9 second gap between shield blocks with only a single shield barrier in the middle thiese.queues should be dismissed.
B-115 – if the warrior does not have 4 piece T14 set bonus the problem is the same as the above bleed queues. If the warrior does have the 4 piece set bonus the threshold is so close to the cap that wasted rage is a guarantee and not acceptable. Should be dismissed
B-120 – wasted rage is guaranteed and not acceptable, should be dismissed.
In conclusion, we do need a bleed queue, but I think the ones used are all unacceptable. The simplest form of bleed queue that would give useful results is:
IF rage > 60 AND shield block cooldown remaining = 0 USE shield block
ELSIF rage > 100 AND shield block cooldown remaining > shield slam cooldown remaining USE shield barrier
Basic idea is never using shield barrier when shield block is already up and vice versa.
W4 – obviously a flawed idea – not sure there was any value including it in the first place. Should be dismissed
W3, W2, W1, W0 – the critical flaw here is in having a rage requirement of >= 20. Not only will rage always be >=20 after 6 seconds of spending no rage (since shield block activation) it is also absolutely maximizing the shield block delay. These should be dismissed.
In conclusion, we do need a weave queue, but none of the proposed are fit for purpose. If we do decide to weave we should mainly use shield barrier the instant shield block expires, if we use it at all. The only other question is if we should weave in a shield barrier if we are below 60 rage or if we want to avoid maximizing the shield block delay (which we would do if we empty our rage bar). This is an area where I think multiple variants on the same principle may be useful – like one where shield barrier is used every time regardless, one only if rage is 60 or above and another couple at 80 and 100 rage.
Since weave queues in principle have the risk of capping rage (especially if it is possible to have a shield block gap without a shield barrier woven in) a rage bleed valve can be a useful addition to a weave queue.
W3-105, W3-110, W3-115, W3-120 – since the weave you implemented has a rage requirement of 20 there is a guaranteed dump of up to 60 rage as every shield block ends – the next shield block may or may not be delayed a little bit, but shield block will always be used with no great excess of rage on hand and hitting any rage bleed valve above 100 will hardly ever happen. These should be dismissed for the same reason the weave queues themselves should be dismissed – it’s the wrong way to implement a weave queue. Additionally the rage expenditure is underestimated – the posited rage levels will never be achieved
In conclusion, weave queues may benefit from a bleed valve, especially if the weave queue does not require dumping rage aggressively as soon as shield block expires.
This one is magic.
F-120 – I am not a fan of queues that require you to cap rage.
F-115, F-110 – I think these are a bit to close to rage capping. Any shield slam or battle shout when rage is above 100 will waste rage. I know it says no rage is wasted on F-110, but it seems unintuitive to me that you will never have been sitting on 101-109 rage while using shield slam or battle shout. I guess the cooldowns on those abilities and the rage expenditures programmed in makes it impossible to land on 101-109 rage without battle shout and shield slam both being on cooldown, but in general I find rage valves above 100 suspicious.
In conclusion, I love what FCFS does and what it shows – very valuable addition to the modelling of tank ability usage. While I am intuitively concerned about any rage valves that do not go down to 100 (or 95 with sword and board tbh) and I always think 120 and 115 rage valves are automatically unusable due to rage capping I can accept that the highest rage valve that has an xsR(k) of 0.0000 must be viable.
SB is an idiot check – if we put together a queue that performs worse than SB then we’ve achieved a special kind of stupid. I do not object to its presence as an idiot check, but if we are comparing viable queues it has no place.
Now, these are the queues I think we need:
Additionally I think we need to consider the situation where we aim for an S% of 0.6667 – for this I think we need 3 types of queues. We need a sensible bleed queue, a sensible weave queue and a lazy bleed queue. The lazy bleed queue is the one I mentioned where we pop shield barrier together with shield block to empty our rage bar and have 9 seconds to build up the 60 (55) rage for the next shield block.
The complete, sensible bleed queue. I pre-empted this in the bleed section above, but this is the full pseudo code for it. The basic idea is that I am looking only one ability into the future. Doing more is doable but unnecessarily complicated – better to just continue using abilities until we get to the threshold.
IF (rage >= 60 AND remaining shield block cooldown = 0) USE shield block
ELSIF (rage >= 95 AND sword and board active AND remaining global cooldown < remaining shield block cooldown)
OR (rage >= 100 AND sword and board not active AND remaining shield slam cooldown < remaining shield block cooldown)
OR (rage >= 100 AND remaining battle shout cooldown < remaining shield block cooldown)
OR (rage >= 105 AND remaining revenge cooldown < remaining shield block cooldown)
OR (rage >= 110 AND remaining berserkers rage cooldown < remaining shield block cooldown) USE shield barrier
Basically the question is whether incoming rage would make you cap before shield block comes off cooldown – if yes, bleed now. I’m well aware that the 1 rage per 3 seconds is overlooked. This is deliberate and the impact is minute.
The complete, sensible weave queue. The idea is that shield barrier can be used in the 3 second gap between shield blocks, and that the value of that shield barrier outweighs any cost that may be incurred if shield blocks are occasionally delayed.
An underlying goal is to still strive for an S% of 0.6667 so it may be sensible to have the weave decision contingent on whether the last shield block (or couple of shield blocks) have already been delayed. Fortunately, shield block has two charges, so if we just first check if shield block is off cooldown and use it if it is, when a shield block delay has built to 3 seconds we will automatically have two shield blocks in a row.
Additionally, we need to decide if we want to use shield block while shield barrier still has some absorb left in it. On the one hand, S% at 0.6667 is a stated objective and waiting for shield barrier to decay or be hit can prolong the shield block delay – but because shield barrier duration is only 6 seconds and shield blocks can be used back to back even the worst case does not compromise our target S%. On the other hand a shield barrier with only very little absorb left in it is perhaps best considered not up. While it is simple in-game with addons to make decisions based on this, for modelling it becomes a needless complication. It does not introduce a risk of S% going below 0.6667 and therefore is not worth modelling.
Last, we have the question of the bleed valve. Especially if we somehow manage to have 12 seconds of uninterrupted shield block we may have a situation where rage caps while we are under shield block. For the purpose of the integrity of the weave I would propose such rage capping is accepted and assessed. If it is substantial maybe a bleed valve can be considered. Note that the rage >= Y factor used below is not a rage valve because it is not checked at all times, only when at the beginning of a shield block gap. That said, it may obviate the need for a rage valve.
Note that it is possible to use shield block while shield block is up to add 6 seconds to its duration. There is a built-in delay (though it doesn’t show as a global cooldown) so with 120 rage you can use shield block two times maybe 1 or 1.5 seconds apart ending up with a total uptime of 12 seconds with 10+ seconds remaining shield block buff duration after shield block has been used the second time.
IF (rage >= 60 AND shield barrier is not up AND remaining shield block cooldown = 0) USE shield block
ELSIF (shield block is not up AND shield barrier is not up AND remaining shield block cooldown > 1.5 AND rage >= Y) USE shield barrier
Shield barrier will only be used if we are in a shield block gap that has 2-3 seconds left. If the shield barrier is cast at the earliest possible time and a string of misses occur so it decays after 6 seconds the following shield block gap will be exactly 0 seconds. If rage influx is erratic and that subsequent shield block gap becomes longer as a result shield blocks will continue to take priority for rage expenditure until both shield block charges are within one second of being fully on cooldown at which point shield barrier can once again occur. By requiring shield block cooldown to be above 1.5 seconds (and it will of course always be below 3 seconds) we should avoid using shield barrier twice in one shield block gap as well as using shield barrier in shield block gaps that are so small that the value of weaving in a shield barrier is questionable.
I listed AND rage >= Y. It can be excluded (or have Y set to 20) for a pure weave queue. The question is (as asked above in the weave critique section) if a weave queue will perform differently if it maximizes the shield block delays or is modified to minimize them. The values I think are interesting to investigate are 20, 60, 80 and 100.
I am intuitively opposed to Y below 60 – and even 60 I’m not too fond of. We’re staring in the face of dropping a low-rage shield barrier and emptying our rage bar with no imminent prospects of a shield block. If sitting on low rage at the end of a shield block it seems wiser to me to reserve that rage for the next shield block so it may occur with not too big a delay. For this reason I think the real decision is going to be between the 80 and 100 rage versions of this. Maybe the problem is not so much emptying the rage bar as it is emptying the rage bar if all you can put up is a pathetic shield barrier. A strong shield barrier may justify emptying the rage bar. For that reason, maybe 40 is also a value that bears investigation. I do expect 20 to fare particularly poorly though.
The lazy bleed queue. There are a couple of reasons I want to include this. First, I believe that if a sub-optimal queue takes a lot less attention to maintain it can end up performing better in a real situation – it gives the tank more mental freedom to react to mechanics and situations and use emergency buttons. Second, it’s what I currently sometimes do (when busy with mechanics, calling things on ventrilo etc) and I’d be curious to see how much I actually lose by doing it this way. As I described before I think most spikes (3 attacks or more) will include either the first or last attacks under shield block and for that reason a shield barrier that covers the first or last part of shield block can help with those spikes. I completely agree that mitigation on top of mitigation when there are periods with no mitigation at all is probably not ideal, but since 2 attacks are rarely enough to kill a tank having the third attack in the spike both blocked and fully absorbed should not be completely disregarded. Of course, this argument only applies when the dangerous spike has first and second attacks in the block gap so it’s good for probably half the of the dangerous 3 attack spikes, but a larger and larger proportion as we move to 4, 5 and 6 attack spikes.
IF (remaining shield block cooldown = 0) USE shield block; USE shield barrier
Remember both are off the global cooldown so can be used in the same fraction of a second – just make sure to hit shield block first. The hidden global cooldown that prevent you from using shield block twice in the same fraction of a second does not apply to using first shield block and then shield barrier. They can land at effectively the same time.
Due to rage generation cooldowns this queue may end up with shield block gaps above 3 seconds – it would be interesting to know the impact on dangerous damage spikes.
I replyGreat comments, I’m not sure why WordPress is having trouble parsing your conditionals, but your clarifications cleared it up enough to be understandable.
Regarding the rest of your comments – I think your criticism of the Bleed and Weave/Bleed queues is accurate. Though keep in mind that these weren’t conceived of by me as an optimization strategy. These were me attempting to model the way warriors play based on discussions I’ve had with warriors. In other words, I was modeling what they tell me they are doing, not what I think they should do.
Your proposals for improved B and W/B queues look good to me. They basically go to the next logical step, which is estimating rage gain before SB comes off of cooldown and making choices accordingly. The reason I avoided these in the past is twofold: first, because you end up with a rather complicated conditional, which makes it hard to track down errors and cause/effect relations when things go wrong. But more importantly, players I spoke to basically said that while such a queue would be rigorous, it would also be very difficult to actually perform. And as a result, it wouldn’t be a realistic model of what a player actually does.
That said, we’ve seen that the earlier versions of B and WB weren’t beneficial anyway, so it seems sensible to implement your improved versions.
I also like the idea of the “lazy bleed.” The rationale seems sensible to me: if your serious damage events are always going to involve 2+ full melees from the 3 seconds of SB downtime, then throwing everything you’ve got at the subsequent attack is an targeted spike-mitigation strategy. So I’ll implement that one too.
And of course, I’ll fix the bugs you’ve pointed out. SBr rage consumption mechanics, primarily – I agree that the T14 tier bonus issue is mostly irrelevant with 5.2 in the near future. Are those the only two, or am I forgetting others?
As mentioned earlier I responded twice to Thecks first reply - this is the other line of responsesI don’t know which players you were talking to, but when tanking I often use something like the bleed queue that I outlined. With the obvious exception that I take much more into account. I look more than one cooldown into the future (triggering at 80 if I have both battle shout and shield slam available for instance), as well as sometimes not bleeding the instant I know that I can afford to bleed – perhaps waiting the last 2 seconds of shield block coverage and triggering my bleed at the beginning of the shield block gap. Sometimes I even compromise my rage generation – like if it’s 2 seconds before shield block expires, shield slam comes off cooldown in 1 second and I am at 114 rage. I can choose then to delay shield slam by 1 second by using first shield barrier then shield slam and both after shield block has expired. While that is a carefully constructed example it is certainly true to say that I often time my bleeds (and shield blocks) to occur at the same time as (but immediately prior to) rage generators. In the model abilities that generate rage are treated completely separately from abilities that use rage. In-game they’re tied together to a much higher degree.
Imo the bleed queue I described is actually simplistic.
Funnily enough, the weave queue is difficult for me. For some reason it’s more natural to me to respond to rage levels and take timings into account as a secondary thing than tying myself to relatively close timings. I think that if you were to implement weaving, the way I described it is how you would do it. But should you use a Y of 20, 40, 60, 80 or 100? I frankly have no clue. It’s an area where I wouldn’t even like to test. This is an area where I’d value a model to pinpoint one as optimal or a couple as viable before I even start playing with it. In theory, this should be the absolutely optimal way to tank – as you have pointed out staggering mitigations usually is, and the whole point of this weave queue is to stagger mitigations in as optimal way as possible.
On the one hand you could say it’s an exercise worth doing to understand the maximum theoretical value of staggering mitigations for a warrior (and a useful benchmark for more manageable queues), but we also know that as soon as we’ve proved that it is clearly superior someone is going to practice it, get it to work, publish a guide, maybe program an addon to support it etc.
I think the Shield Barrier rage cost being variable from 20 to 60 is the only real bug I found – I’m not sure which other you are referring to. The only other thing I can think of is if you had shield block done wrong. I didn’t know, which is why I made sure to explain that shield block used while shield block is already up will just add 6 seconds to the duration of the shield block buff. Additionally (and of no real importance to the model, it can be safely ignored) shield block has a hidden internal cooldown so you cannot use it twice (by accident either) by pressing the key twice – the key presses have to be at least 1 second or 1.5 second apart. But for modelling it doesn’t really matter if you get 12 seconds shield block now, or 6 seconds now and an additional 6 seconds 1.5 seconds later. It will still end at the same time. Shield block is off the global cooldown.
And now TheckI’m a bit like a broken record. Re-reading your reply seemed prudent as dialogue is supposed to go two ways and I’m painfully aware that I’m mostly just spouting what I think instead of responding the comments that you make. I treasure your responses, though I do not always feel there would be anything gained by me responding to your responses, if you know what I mean.
However,in re-reading this something struck me that I forgot to mention – or at least forgot to mention with reference to your points. When a warrior uses shield block a lot his damage intake profile looks a particular way – damage taken during shield block and damage taken in shield block gaps have different damage intake profiles. In a sense my lazy bleed strategy is an unthinking (though intended) way to implement shield barrier as a response to a damage spike. I claim that most dangerous damage spikes will include two hits in the 3 second shield block gap and that following the 3 second block gap with an automatic shield barrier (after rage has been used on shield block) will function as a response to a low-health situation a large percentage of the time low-health situations occur.
In other words, one additional reason why the lazy bleed strategy may be worth modelling.
The thought comes partly from your point that damage intake profiles are important to consider if we are to evaluate shield barrier as a survival response. While I agree with the principle that strings of hits (with no dodge/parry/miss) are particularly interesting to investigate, I initially felt that assessing the damage intake over the last few hits seemed an incomplete simulation. Of (deliberately) overlooked and particular importance is whether healers are filling you up or whether they are preoccupied. Similarly, most bosses have varying ways to do more or less dmg at times. Bottom line is that it’s health that matters, not just damage. In some cases healers will use cooldowns when known spikes occur and all of that is completely true, and at the same time completely not necessary to model something useful. While I strain against using a simple “if damage in the last N seconds exceeds X” conditional, I must ultimately accept that it can be useful to model.
However, it would obviously need to be slightly more complicated than that. At least “if damage LESS the value of any shield barriers erected in the last N seconds exceeds X “. And still, I dovetail back to my lazy bleed strategy – since shield block gaps are of particular importance firing off a shield barrier automatically at the end of each shield block gap could well obviate the need for (and value of) that type of conditional.
Another interesting factor to consider is the characteristics that a queue must have for that type of conditional to be effective. For instance, a queue that burns rage pretty quickly and never lets it pool very high will maybe never trigger that kind of conditional.
“Regarding the discretization of SBarr: I wasn’t aware the ability worked that way, but it would be easy to fix in the simulation. That said, it won’t have a large effect on the results. Stochastically, it should all average out. If anything it may make use of Shield Barrer at <60 rage even worse, simply because there's no chance of retaining 10-15 rage by missing a threshold value."
This is exactly why I wanted it corrected. When a rage remnant is not possible for many uses of shield barrier it changes when the next shield barrier or block becomes available. Also, though I think you have a solid set of stats coming out, I would be curious to have the headline stats expanded. Partly I think there is something missing in the area of number of shield blocks (implied by S% I know) in a way that is comparable to numbers of shield barriers used. Or maybe rage spent on shield block vs shield barrier. Or damage mitigated per point of rage spent in shield block vs shield barrier. Or damage mitigation lost in shield barrier by having shield barrier expire before being used to mitigate damage. I completely agree that the most important part of the output is the damage smoothing section, but these would still be interesting to me to see. SBr(k) and SBr<60(k) I could easily do without though. I think it would be good to remove those two and put in three stats for damage mitigated (by shield block) per rage point spent on shield block, damage mitigated (by shield barrier) per rage point spent on shield barrier and damage mitigation from shield barrier that went unused.
Me againThe moving-average damage taken model certainly has limitations. As you say, often what matters is health, not how much damage you’ve taken recently. But that gets far more complicated to simulate, because you basically have to start writing an entire healing AI, amongst other issues. I’ve had some discussions with a friend of mine that does those sorts of things, but I think at that point this is simply the wrong tool for the job. A tool that’s more robust (i.e. Simcraft) is going to do a better job in that case, I think. It’s something I’m already looking into for my Paladin modeling, in fact.
That said, there are definitely advantages to this sim. For one, It’s fast and easy to modify. But perhaps more importantly, the results still have a good deal of relevance. While your healer is likely to pop a cooldown when your health drops dramatically (or for that matter, you may pop one yourself), you’re also less likely to die in that situation as a result of the cooldown. Cooldowns are the modern tank’s anti-spike mitigation, and we use them liberally.
However, that means you’re more likely to die when you or your healer fail to react (i.e. preoccupied/distracted). And that’s exactly the situation this sort of simulation tries to address. It’s even got some applicability when you are running a cooldown – for example, having a 50% cooldown active but starting at 50% health.
Theck againI wasn’t really trying to make a point for including a full healing model, just explaining my intuitive concerns with the limited damage taken recently model. I think your model does not take into account boss spike abilities, tank cooldowns or healer cooldowns and in a sense it’s better for it. It models the steady state of tanking, not the exceptions. Since the exceptions are all about tailoring your responses and acting either reactively or proactively, and either on your own or in congress with your healers, it’s not something that lends itself well to this type of modelling.
I repeat that I do think listing absorbs put up by shield barrier that ended up not being used would be a valuable addition. Removal of the current shield barrier stats and including the blocked/absorbed per rage stats is meh – could go either way – but including the wasted absorbs I think will be valuable in certain situations – not unlike the wasted rage stat in the kinds of things it reveals.
While it may not be mathematically possible (either in current gear, or ever) to get to that point, the thinking behind it is to account for the situations where high avoidance gear levels cause the absorb of shield barriers to go unused so often that (with that gear set) shield barrier based queues become strictly worse (TDR for instance) and this stat could be an early indication or explanation of why that is.
On reflection a dodge/parry/miss sequence also reduces the value of shield block. Maybe it isn’t a valuable stat. Or maybe the blocked/absorbed per rage stats combined with the absorbs wasted stat would tell us if shield block or shield barrier is hit worse by prolonged dodge/parry/miss events.
What such stats may ultimately show is that if you stack avoidance you can get to a point where shield block and shield barrier are so devalued that rage generation stats become devalued too.
On the subject of additional stats, have you considered adding a 70% and maybe a 60% section to the damage smoothing stats? It’s obvious it will be of no value for 2 attacks, but at 7 attacks it may be. In a sense the question is, at 7 attacks will 70% (or 60%) be enough damage to kill the tank, absent heals? Pre-occupied healers etc. I appreciate the lower we go there the more the rankings of queues and equipment sets will begin to resemble TDR, but bottom line is that the smoothing stats indicate the presence of a potential killing spike. 90% of 2 attacks is not a killing spike. 60% of 7 attacks may be.
And finally meI think the “wasted absorb” stat is probably worth adding as well. I probably won’t get to edit the code until after 5.2, but it will definitely be on the list of changes. Absorbed per rage spent is a simple calculation to do in post-processing, but blocked/mitigated per rage spent is trickier because of the way blocking works. First, you have to separate normal blocks and crit blocks from those with Shield Block up, which can’t be done in post-processing without more tracking variables. Second, some of those blocks and crit blocks during SB would have been blocks or crit blocks even in the absence of SB, so you’d need to subtract out those based on a simple probability model. It can be done, but I’m not sure it will tell us enough to be worth the work that goes into it.
When writing the updated 5.2 paladin simulations (published later this week, most likely) I added the 70% and 60% categories. It’s a trivial change, so I’ll certainly do that for the next round of warrior sims as well.
Topics for discussion - queues and stats.Awesome, thanks. The wasted absorb and lower percentage categories for damage smoothing are the stats I suggested I think will be most valuable.
Even if it’s simple to do I don’t think there’s any reason to include absorbed rage per rage spent if you do not include dmg mitigated through shield block/crit block per rage spent. Those two stats only have value when used in comparison. Adding more stats may appeal to the mathematician and engineer but for the casual reader it’s more important that each stat listed has a distinct value and meaning. This is also why I was arguing for the removal of some stats. It’s the old signal to noise ratio idea.
Reading your reply my mind did go on a tangent about how a stat for mitigated by shield block per rage could be interesting to show the value of mastery, but on closer reflection that would only tell us something that we already know anyway (that you block more dmg when you have higher mastery) – sure it may qualify it further, but I’m not convinced it would add any value for that.
While I personally think it’s valuable to include 70% and 60% categories at 7 attacks the value at 2 attacks is pretty slim. It may be worthwhile to either vary the number of categories you include as the number of attacks increases – or point out in the explanatory text why the lower percentage categories are particularly un-useful at the lower attacks and more useful at higher attacks.
Would you argue for the removal of any of the current stats (like I argued for the removal of SBr(k) and SBr<60(k))?
Would argue for the the inclusion of any new stats - either the ones I suggested or others. The ones I suggested being wasted absorbs, damage blocked per rage spent on shield block, damage absorbed per rage spent on shield barrier, and including 70% and 60% categories to the damage smoothing section (particularly for larger number of attacks)
Do you feel strongly that SB should be included as an idiot check, or left out completely if more realistic queues with emphasis on shield block are available?
Do you think the queues I propose are sensible, not sensible and/or an incomplete list? Is there a queue you think certainly needs to be modeled which is not already modeled and not on my list of suggestions?
Last edited by Krennick; 03-04-2013 at 11:24 AM. Reason: Edited to correct shield barrier to shield block in two places. Thanks Claudead.
I have to agree with Theck for most part. Your "sensible bleed queue" looks to be perfect, but i can't imagine many player being able to perform it with much consistency.
I appreciate you looping us into your thread and discussion. I am not often on Theck's blog now a days.
After reviewing your stats and ques I dont believe I have much to offer in the way of new ideas, but I am curious to see what Y works out to be in the weave que.
Also, this may not be inline with what you are trying to accomplish, but you mention non-AM stats would have an impact on the ques and devalue both SB and SBar. I am wondering at what levels do those stats devalue their usage and by how much, to the avail that an average player like myself can determine weight priorities based on the que preference. Thoughts?
Last edited by Xaerran; 03-08-2013 at 10:57 PM.
I don't think we're anywhere near the place where our total chance of not getting hit is high enough that it compromises the value of SB and SBar. I was going off on a tangent and speculating that a stat I intuitively felt might be useful for something, could be useful as an early warning of that.
I'm sure it could be mathematically modelled, and if we were imminently in danger of getting to that point that could be very valuable - but I think there's no chance in this equipment tier and frankly no chance in the next one either - and I strongly expect we'll see another expansion before this becomes a consideration - where the next expansion will do its own tweaks and ensure it won't happen there either.
I think DRs are going to prevent avoidance devaluing Sblock/Mastery. Even if you went for avoidance, I don't think you're going to approach the necessary curves. Avoidance is still at the bottom of the stack, imo.
"If the world is something you accept rather than interpret, then you're susceptible to the influence of charismatic idiots." -Neil deGrasee Tyson
Twitter @Aggathon || @Tankspot || Twitch.Tv/Aggathon