Protection legion Discussion

[Valkaneer]

Isn't the off tank always taking damage in this encounter? I thought there were adds that were for the off-tank only.



Says crits only. Crit should end up being our least valued stat.



Shield Block has always been flagged as Active Mitigation, but early in the alpha it wasn't working against spells that can only be countered by Active Mitigation

Shield Block does nothing for Magic attacks, Just tested it on some water elementails that cast a frost attack. IP absorbed 15k of it while I took full damage with Shield Block up. But now Spell Shield is much stronger with the artifact.

Did they remove it? Still on wowhead: http://legion.wowhead.com/spell=46953/sword-and-board

Devastate now has a 30% chance to reset on hit. Reset on critical strike chance has been removed, unless the tool tip is wrong. So now it's just based on hit alone. I don't think Haste effects devastate either. Has trigger GCD and is instant.

This is my Crit tool tip: Chance for extra effectiveness on attacks and heals, Critical Strike: XXX (= XX%), Increases parry chance by XX%.

[Agromat]

On May 28th, FinalBossTV did a bunch of Ignore Pain testing on his Twitch stream. I was able to get on for part of it and he tested a bunch of questions I had. Here's a link to the stream. The Protection Warrior stuff starts at the 4 hour mark:

https://www.twitch.tv/finalbosstv/v/69214255

Here are some ticky-tacky details about it:

1. Ignore Pain was not being calculated correctly a couple builds ago
There were some bugs with IP values a couple builds ago for characters with less than 100% health. For instance, in this recent FinalBossTV Prot Warrior youtube video (https://www.youtube.com/watch?v=5ceIKQoAMX0), the IP values he's generating while in combat with the raid dummy around the 20:40 mark vary randomly and are much lower than they should be. So don't base theorycrafting on videos or logs from builds older than this week's (May 26) beta build.

These bugs have been fixed. If you're looking for a video of IP in action in a build that doesn't have these bugs, watch the FinalBossTV Twitch stream I linked above.

2. Ignore Pain is modified by your Versatility value
Versatility increases healing, which includes absorb values, which includes Ignore Pain. If you're calculating your Ignore Pain value, don't forget to multiply by 1 + your Versatility percentage from your character screen.

Versatility also increases the damage you deal, but it doesn't affect your attack power, so that aspect of Versatility doesn't change your IP at all.

3. Bonuses to IP% are multiplied separately, not added and applied at once
This is how all percentage bonuses in the game work, but it's worth restating. There are several bonuses that increase IP's value by a percent - Dragon Skin (up to 6%), Indomitable (25%), Never Surrender (varies), Dragon Scales (60%), and Versatility.

If you have 17.4% versatility, say, the formula for how those bonuses affect IP's value is this:

15 * AP * 1.06 (from Dragon Scales) * 1.25 (from Indomitable) * 1.174 (from Versatility)

Not this:

15 * AP * (1 + 0.06 + 0.25 + 0.174)

4. At level 110 with blue dungeon gear, IP's base value is about 20% of your base health
Here are some stats of a level 110 Warrior in blue dungeon gear:

Health: 1,865,820
Attack Power: 19,379
Versatility: 17.42%

For that character, who we'll assume has maxed Dragon Scales on their artifact, their untalented, unmodified IP is 15 * 19,379 * 1.1742 * 1.06 = 361,802, or about 20% of their health.

5. The absorb value shown in the combat log is 90% of the calculated value
IP "ignores 90% of the next X damage you take". The combat log event for applying IP shows how much damage your IP will eventually absorb, which means it shows 0.9 * your calculated IP value.

For example, when the 110 character above casts IP for 361,802, the combat log shows him gaining an absorb of 325,621. These pictures show the buff tooltip and log event for the same cast:





6. The 25% bonus from Indomitable is shown in the buff tooltip, but not in the spellbook tooltip
Here's a minor one. When you mouse over IP in your spellbook or mouse over the active IP icon in your buff bar, it shows the calculated IP value. However, if you have Indomitable, the benefit from it isn't shown in the value in the spellbook tooltip.

7. The bonus from Never Surrender scales linearly
We already knew this, but it's worth mentioning again for those who don't know. With NS, the percent bonus to your IP is equal to your percentage missing health:

IP value with NS = Base IP Value * (1 - current health %)

So, if you have 75% health, NS increases your IP value by 25%. If you have 20% health, NS increases your IP value by 80%.

8. Ignore Pain's maximum shield is equal to 2 * the value of your most recent IP
We also already knew this one, but the video confirmed it, and it's worth knowing. Here's Celastalon describing how it works, taken from this post and this post.:

Celatalon: The cap is 2x IP’s size at cast time. That cap takes into account all of the things that affect it.
Marokk: When you cast that 500K IP on top of the first one, I assume the cap is now 1000K? Also, what if you cast a third IP for another 300K absorb, is the cap 600K again? What happens to the extra absorb that's over the now 600K cap?
Celastalon: All correct. In the last case, the extra is removed.

Usually this won't affect how you play, but one implication is that you shouldn't use IP twice rapidly when you have a Dragon Scales proc active (which increases the value of your next IP by 60%). Your first IP will have a 60% bonus, but when you cast IP again, your total shield will be above your new cap and some of it will be removed. Here's a post from Ejs demonstrating how a lower 2nd IP can clip value from the first. Here are some numbers from a test Yse performed showing what happens, with annotation from me:

# IP without proc
1st 378,885 (this is Yse's base IP value. Cap = 2 * 378,885 = 757,771)
2nd 757,771 (the second shield adds to the first, creating a shield of 757,771. Cap is still 757,771, so nothing is lost)

# IP with proc
1st 454,622 (this value is 1.6 * 378,885. Cap = 2 * 454,622 = 909,244)
2nd 757,771 (the second shield adds to the first, creating a shield of 454,622 + 378,885 = 833,507. Cap is now 2 * 378,885 = 757,771, so 75,736 shield is lost)

If Yse has cast IP once, gotten a Dragon Scales proc, then cast it again, his shield would have been 378,885 + 454,622 = 833,507, which would have been well under the cap of 2 * 454,622 = 909,244.

Special thanks to Ejs, Yse, Beardyface, and L Kebess for digging through the details of this with me over the next few posts.

[Beardyface]

Usually this won't affect how you play, but one implication is that you shouldn't use IP twice rapidly when you have a Dragon Scales proc active. Your first IP will have a 60% bonus, but when you cast IP again, that 60% bonus will be above your new cap and will be removed.

Not quite, although admittedly it is confusing. Your cap is always the value of your currently cast IP, so in the scenario above, you can cast two IPs with no loss. In fact, you can always cast two IPs in a row without anything being wasted. Casting the 3rd IP is when you run into part of the IP being removed.

It's actually much simpler than that example you linked makes it. It works like this:

You can only stack Ignore Pain twice, regardless of talent choice. It works like this:

I cast IP once. We’ll call that IP A.

I cast IP again. We’ll call that IP B.

So my current IP value is A+B

I cast IP again before that IP ends. We’ll call that IP C.

Now my current IP value is B+C (C overwrites A).

If I cast IP again, which we’ll call D, then my value is

C+D (D overwrites B)

and so on…

It snapshots those values at the time they happen.

See blue verification here:

http://us.battle.net/wow/en/forum/to...16?page=15#288

[Deleted]

Not quite, although admittedly it is confusing. Your cap is always the value of your currently cast IP, so in the scenario above, you can cast two IPs with no loss. In fact, you can always cast two IPs in a row without anything being wasted. Casting the 3rd IP is when you run into part of the IP being removed.

It's actually much simpler than that example you linked makes it. It works like this:

No. If the remaining value of your previous IP is bigger than the value of your next cast, you are going to lose out because of how the cap system works. Beardyface must have misunderstood Marok and the devs response.

[Agromat]

No. If the remaining value of your previous IP is bigger than the value of your next cast, you are going to lose out because of how the cap system works. Beardyface must have misunderstood Marok and the devs response.

This. Quoting the theorycrafting thread:

Celatalon: The cap is 2x IP’s size at cast time. That cap takes into account all of the things that affect it.
Marokk: When you cast that 500K IP on top of the first one, I assume the cap is now 1000K? Also, what if you cast a third IP for another 300K absorb, is the cap 600K again? What happens to the extra absorb that's over the now 600K cap?
Celastalon: All correct. In the last case, the extra is removed.

Here's an example of how two quick IPs with a Dragon Scales proc on the first plays out. Assume I have Indomitable or Best Served Cold so my base IP value never changes, and assume its value is 300,000. I have a Dragon Scales proc active and cast IP, so it's value is increased by 60%. It's cap is double the IP value:

IP A: Value = 300,000 * 1.6 = 480,000 (cap 960,000)

Then I cast IP again. The new value is add to my existing 480,000 shield and the cap is recalculated to be twice the value of my latest IP:

IP B: Value = 300,000 (cap 600,000)

Since I already had a shield, the new value is added to the old (480,000 + 300,000 = 780,000). Since this value is higher than the new cap (600,000), the extra is removed, and I am left with an IP of 600,000.

[Deleted]

This. Quoting the theorycrafting thread:

Marokk: When you cast that 500K IP on top of the first one, I assume the cap is now 1000K? Also, what if you cast a third IP for another 300K absorb, is the cap 600K again? What happens to the extra absorb that's over the now 600K cap?
Celastalon: All correct. In the last case, the extra is removed.

Here's an example of how two quick IPs with a Dragon Scales proc on the first plays out. Assume I have Indomitable or Best Served Cold so my base IP value never changes, and assume its value is 300,000. I have a Dragon Scales proc active and cast IP, so it's value is increased by 60%. It's cap is double the IP value:

IP A: Value = 300,000 * 1.6 = 480,000 (cap 960,000)

Then I cast IP again. The new value is add to my existing 480,000 shield and the cap is recalculated to be twice the value of my latest IP:

IP B: Value = 300,000 (cap 600,000)

Since I already had a shield, the new value is added to the old (480,000 + 300,000 = 780,000). Since this value is higher than the new cap (600,000), the extra is removed, and I am left with an IP of 600,000.

Probably just me misunderstanding it but this sounds a bit nonsensical.

You say after casting the initial IP of 480K one gets an IP cap of 2*480K => 960K.
If so, then why casting a second IP doesn't simply add up to the existing one of 480K to give => 480K + the amount of the second IP, up to the cap of 960K?

If the first so called "cap" of 960K is immediately removed after casting a second IP, then how can it have any effect whatsoever? And if it doesn't have any effect whatsoever then how can it even exist? : )

[Deleted]

Probably just me misunderstanding it but this sounds a bit nonsensical.

You say after casting the initial IP of 480K one gets an IP cap of 2*480K => 960K.
If so, then why casting a second IP doesn't simply add up to the existing one of 480K to give => 480K + the amount of the second IP, up to the cap of 980K?

If the first so called "cap" of 960K is immediately removed after casting a second IP, then how can it have any effect whatsoever? And if it doesn't have any effect whatsoever then how can it even exist? : )

I honestly don't know what the logic behind it is.

[Beardyface]

This. Quoting the theorycrafting thread:

Celatalon: The cap is 2x IP’s size at cast time. That cap takes into account all of the things that affect it.
Marokk: When you cast that 500K IP on top of the first one, I assume the cap is now 1000K? Also, what if you cast a third IP for another 300K absorb, is the cap 600K again? What happens to the extra absorb that's over the now 600K cap?
Celastalon: All correct. In the last case, the extra is removed.

Here's an example of how two quick IPs with a Dragon Scales proc on the first plays out. Assume I have Indomitable or Best Served Cold so my base IP value never changes, and assume its value is 300,000. I have a Dragon Scales proc active and cast IP, so it's value is increased by 60%. It's cap is double the IP value:

IP A: Value = 300,000 * 1.6 = 480,000 (cap 960,000)

Then I cast IP again. The new value is add to my existing 480,000 shield and the cap is recalculated to be twice the value of my latest IP:

IP B: Value = 300,000 (cap 600,000)

Since I already had a shield, the new value is added to the old (480,000 + 300,000 = 780,000). Since this value is higher than the new cap (600,000), the extra is removed, and I am left with an IP of 600,000.

We may need clarification, but I think the key word in Marokk's quote is third. I've bolded it above. The extra is only removed if you try to cast a 3rd IP while the other two are up. If you cast an unbuffed IP, then a Dragon Scale buffed IP and stop there, you get the full additive value. Same if the DS buffed IP is first. However, if you cast a 3rd IP before those first two IPs expire, the 3rd IP will be unbuffed, and since it only stacks twice, your cap is now lower, and you can't use that second DS buffed IP to squeeze a 3rd IP in under the old (larger) cap.

[Deleted]

We may need clarification, but I think the key word in Marokk's quote is third. I've bolded it above. The extra is only removed if you try to cast a 3rd IP while the other two are up. If you cast an unbuffed IP, then a Dragon Scale buffed IP and stop there, you get the full additive value. Same if the DS buffed IP is first. However, if you cast a 3rd IP before those first two IPs expire, the 3rd IP will be unbuffed, and since it only stacks twice, your cap is now lower, and you can't use that second DS buffed IP to squeeze a 3rd IP in under the old (larger) cap.

It sounds quite probably. In short, the cap is reset after every 2 IP casts.
(or if your IP expires for whatever reason, obviously)

[Deleted]

Probably just me misunderstanding it but this sounds a bit nonsensical.

You say after casting the initial IP of 480K one gets an IP cap of 2*480K => 960K.
If so, then why casting a second IP doesn't simply add up to the existing one of 480K to give => 480K + the amount of the second IP, up to the cap of 960K?

If the first so called "cap" of 960K is immediately removed after casting a second IP, then how can it have any effect whatsoever? And if it doesn't have any effect whatsoever then how can it even exist? : )

1st IP is 480k, giving you a cap of 960k

2nd IP could be ie. 600k, but as you are maxed at 960k, you´ll only effectively use 480k of this IP(unless some of the absorb have already been used). The 600k IP does give you a new cap of 1200k, effective on next cast

3rd IP will be using the 1200k cap, but it´s will also determine the cap going forward.

etc.

[Agromat]

If so, then why casting a second IP doesn't simply add up to the existing one of 480K to give => 480K + the amount of the second IP, up to the cap of 960K?

When you cast the second IP, that updates the cap based on the second IP, so it's now 600k. The system doesn't care (and probably doesn't even know) that the cap used to be 960k.

If the first so called "cap" of 960K is immediately removed after casting a second IP, then how can it have any effect whatsoever?

The effect that the bigger cap can have is that you won't ever lose previous IP amounts when casting a bigger IP. Like, if my first IP is 300k and my second is 480k, then my total IP value (780k) will be smaller than the new cap (960k) and nothing will fall off.

Here's another example. Say I cast 3 IPs in a row, with a Dragon Scales proc on the last one, so the values are 300k, 300k, and 480k. Here's what happens:

IP A: Value = 300k. Cap = 600k. Total IP: 300k
IP B: Value = 300k. Cap = 600k. Total IP: 300k + 300k = 600k
IP C: Value = 480k. Cap = 960k. Total IP: 600k + 480k = 1080k, which is then reduced to the new cap of 960k

My guess for why it's that way is totally a guess, but here it is. I think they wanted you to be able to stack about up to 2 IPs, but they don't have a way of knowing what proportions of your current IP shield value came from your last cast or from previous casts. Like, at a given moment, if you have 526,493 IP left, the engine has no idea that 360,000 of it is from your last cast and the remaining 166,493 is what's left from two casts ago. By making it 2x your most recent IP, they can cap your IP without needing that information.

I think the key word in Marokk's quote is third. I've bolded it above. The extra is only removed if you try to cast a 3rd IP while the other two are up...

We're reaching the point of diminished returns of discussion. Valkaneer or Yse, do you mind testing this for us really quick in the beta when you have a moment? All you need to do is take Best Served Cold or Indomitable, tank something until you get a Dragon Scales proc, then cast two IPs in a row, writing down the value of the shield after each one.

[Deleted]

1st IP is 480k, giving you a cap of 960k

2nd IP could be ie. 600k, but as you are maxed at 960k, you´ll only effectively use 480k of this IP(unless some of the absorb have already been used). The 600k IP does give you a new cap of 1200k, effective on next cast

3rd IP will be using the 1200k cap, but it´s will also determine the cap going forward.

etc.

Are you just assuming this? It's sound, but it doesn't reflect what Agromat wrote.
After reading yet again Marokk's OP and the Blue response to it, I think Beardyface is closer to the reality.

[Valkaneer]

We're reaching the point of diminished returns of discussion. Valkaneer or Yse, do you mind testing this for us really quick in the beta when you have a moment? All you need to do is take Best Served Cold or Indomitable, tank something until you get a Dragon Scales proc, then cast two IPs in a row, writing down the value of the shield after each one.

Wish I could, but I think Yse is the only one high enough lvl to have it.

[Deleted]

The effect that the bigger cap can have is that you won't ever lose previous IP amounts when casting a bigger IP. Like, if my first IP is 300k and my second is 480k, then my total IP value (780k) will be smaller than the new cap (960k) and nothing will fall off.

Here's another example. Say I cast 3 IPs in a row, with a Dragon Scales proc on the last one, so the values are 300k, 300k, and 480k. Here's what happens:

IP A: Value = 300k. Cap = 600k. Total IP: 300k
IP B: Value = 300k. Cap = 600k. Total IP: 300k + 300k = 600k
IP C: Value = 480k. Cap = 960k. Total IP: 600k + 480k = 1080k, which is then reduced to the new cap of 960k

This is only confirming what I said, Agromat. No where in what you wrote is the "first" (nonexistent?) cap being used. The cap that is being used is always the "next" one, according to what you wrote.

This implies, at the very least, that the very first IP you cast in a fight doesn't have any cap at all. It just has its value, but no cap.

A cap is "generated" only when you cast a 2nd IP, and that cap is, according to what you're saying, 2 times the value of that 2nd IP. From this point on, every cap is simply 2 times the value of your next IP -- UNLESS your IP buff expires/drops for whatever reason, then the cycle restarts yet again, with the very first IP not having (or contributing to) any cap at all, and so on...

Am I making sense to you?

- - - Updated - - -

The last bit is important because, obviously, in a fight, one should lose their IP buff quite often -- forcing "first uncapped" IP casts quite regularly.
In my opinion, talking about a first cap is just confusing and pointless -- it's very similar to randomly and regularly multiply a function by 1.

PS: Note that all this is obviously only applicable if your description of the mechanism is accurate.

[Deleted]

This is only confirming what I said, Agromat. No where in what you wrote is the "first" (nonexistent?) cap being used. The cap that is being used is always the "next" one, according to what you wrote.

This implies, at the very least, that the very first IP you cast in a fight doesn't have any cap at all. It just has its value, but no cap.

A cap is "generated" only when you cast a 2nd IP, and that cap is, according to what you're saying, 2 times the value of that 2nd IP. From this point on, every cap is simply 2 times the value of your next IP -- UNLESS your IP buff expires/drops for whatever reason, then the cycle restarts yet again, with the very first IP not having (or contributing to) any cap at all, and so on...

Am I making sense to you?

- - - Updated - - -

The last bit is important because, obviously, in a fight, one should lose their IP buff quite often -- forcing "first uncapped" IP casts quite regularly.

No. The first IP cast does generate a cap of 2x value, however because of how the cap system works, it never becomes relevant.

Whenever an IP is cast, the cap is changed based on 2x the value of that IP, and the cap is instantly put into place.

An example would be:

IP 1: 100k (200k cap)
IP 2: 200k (400k cap) (you now have 300k absorb)
IP 3: 200k (400k cap) (You now have 400k absorb)

However if your IP cap gets smaller

IP 1: 300k (600k cap)
IP 2: 100k (200k cap) (you now have 200k asborb)
You lose out in this situation.

What I would like to know is if it is theoretically possible to essentially stack up absorbs endlessly, such as the example below:

IP 1: 100k (200k cap)
IP 2: 200k (400k cap) (300k absorb)
IP 3: 400k (800k cap) (700k absorb)
IP 4: 700k (1400k cap) (1400k absorb)

[Murlocbait]

The problem here, as Agromat said above, is that you all have reached the limit of what discussion can do with this issue. It needs to be tested so concrete results can be presented. The wording in the example and Celestalon's response are too vague to determine exactly how it works, so it can be read a couple different ways. Does the limit reset with every single IP use? Or does it reset on every odd use - so the third one resets it while the second one does not necessarily do so (but does in the example since it is larger)? It's impossible to tell, because ol' Sparkle Dragon responded with the shortest sentence possible instead of actually explaining the damn thing.

So someone just needs to test it and show the numbers that answer the questions.

[Valkaneer]

No. The first IP cast does generate a cap of 2x value, however because of how the cap system works, it never becomes relevant.

Whenever an IP is cast, the cap is changed based on 2x the value of that IP, and the cap is instantly put into place.

An example would be:

IP 1: 100k (200k cap)
IP 2: 200k (400k cap) (you now have 300k absorb)
IP 3: 200k (400k cap) (You now have 400k absorb)

However if your IP cap gets smaller

IP 1: 300k (600k cap)
IP 2: 100k (200k cap) (you now have 200k asborb)
You lose out in this situation.

What I would like to know is if it is theoretically possible to essentially stack up absorbs endlessly, such as the example below:

IP 1: 100k (200k cap)
IP 2: 200k (400k cap) (300k absorb)
IP 3: 400k (800k cap) (700k absorb)
IP 4: 700k (1400k cap) (1400k absorb)

I don't think so, he said every third cast makes a new IP cap value. So the First two had a cap of 600 (Cap made off the 1st cast), but the third reset the value of 960k (new cap based on third cast), so it skips the 2nd cast as part of the cap equation. And now you will lose 120 absorb.

[Ashenia]

Wish I could, but I think Yse is the only one high enough lvl to have it.

Will do it soon when I stop playing Overwatch, it's not a problem.

[Deleted]

I just tested it the following way to see when the cap activates and how it works. I popped an IP with all my gear equipped, then removed it all immediately and popped a second one. I am level 105 so my values are low but the results should be the same.

IP 1: 193k (close to 400k cap)
IP 2 (no armor): 105k (giving me a cap AND effective absorb of 210k)

[Deleted]

No. The first IP cast does generate a cap of 2x value, however because of how the cap system works, it never becomes relevant.

Whenever an IP is cast, the cap is changed based on 2x the value of that IP, and the cap is instantly put into place.

An example would be:

IP 1: 100k (200k cap)
IP 2: 200k (400k cap) (you now have 300k absorb)
IP 3: 200k (400k cap) (You now have 400k absorb)

Like I said, talking about a first cap here (when it has zero use in the entire system) is just confusing and pointless -- it's very similar to randomly and regularly multiply a function by 1.

Does a first cap appear in some combat log of some sort? Or has Bliz confirm it somewhere? If not, then the rational approach should be to conclude it's not there (or at the very least, to act like it) since it has no use, and wouldn't affect anything even if it "were" there.

Anyways, if we agree that a first cap doesn't contribute in any possible way, then there's no point in stretching this on any further -- it's not adding anything to the discussion ; )

- - - Updated - - -

I just tested it the following way to see when the cap activates and how it works. I popped an IP with all my gear equipped, then removed it all immediately and popped a second one. I am level 105 so my values are low but the results should be the same.

IP 1: 193k (close to 400k cap)
IP 2 (no armor): 105k (giving me a cap AND effective absorb of 210k)

Good job. Could you try with 3 casts?