Talk:Attack table

What this means
"After discounting misses and dodges, 5% of remaining attacks (hits) will do crit damage." i reverted the change that added this line in the introduction. it is the OPPOSITE of the meaning of the attack table.Emit 22:25, 19 August 2007 (UTC)

Removing Multiple Attack roll theory
I feel it is time for the multiple attack roll theory to be removed from this page. The conventional wisdom among experienced raiders is that the single attack roll theory is correct. Assumptions based on the single attack roll theory have withstood testing. DaveTheJackal has been the only skeptic for a while, and his objections are trivial. Thoughts or comments? Emit 18:29, 9 April 2007 (EDT)


 * I agree. We KNOW it's one roll for a standard melee swing or standard ranged attack.
 * Beaza 8:33, 17 April 2007 (PDT)

OK, I've removed the multi roll theory. It was based mostly on backstab testing, which we've established is controlled by another algorithm. This is the page only for pc auto attack and monster melee attacks, with the implication that special moves may be similiar. Emit 11:53, 7 May 2007 (EDT)


 * I agree, too, although I'd like to make some mention of the backstab data in the "yellow damage" section.
 * --Tracer 20:28, 9 May 2007 (EDT)
 * I'm fine with that, but I can no longer find the reference for that data.Emit 16:03, 22 May 2007 (UTC)
 * Fixed the linkEmit 17:52, 19 June 2007 (UTC)

..
The ranged attack table is incorrect. In pvp most ranged attacks from a hunter that deal direct damage can be blocked. I have blocked auto shots, aimed shots and multishot. I do not know if it is possible to block arcaine shot or stings. Also critical chance and block chance appear to be independent for ranged attacks. I have blocked both crit and non crit aimed/multi/auto shots. I also don't know if you can block ranged attacks from other sources (shoot gun, mobs) or only from hunters--Awkram 13:44, 15 October 2006 (EDT)

This could easily be yet another case of different rules for PvP. I do see you said PvP, but the point needs emphasising that the article as-is is probably correct for PvE. The sight linked to in references goes to great pains to point out that blocking differs between PvE and PvP when considering 'yellow damage' attacks. This article does need to emphasise that these differences exist and note where any given table is for PvE only, for PvP only, or applicable to both. Athan 15:30, 25 October 2006 (EDT)
 * Ranged attacks can be blocked now. I've updated the table.Emit 15:52, 29 March 2007 (EDT)

---

Another important question is just how fine-grained the tables are in practice. I would assume that, given Blizzard quote such things as dodge, parry, block and crit chance to 2 decimal places in the UI, the resolution is to 1/100th of a percent. This effectively means each table has 10000 available slots, and anything left over will be ignored. This is however an assumption and it's possible Blizzard, in practice, only use 1000, or even 100, slots. This is important as it needs taking into consideration when weighing different equipment setups and/or different buff setups. It's no use getting extra theoretical DPS from a different setup if that's due to 0.04% extra crit chance when only whole percentage points of crit chance are taken into account.

So, anyone got a definite cite, or failing that unquestionable empirical data, to backup how many slots the table has in practice ?

Athan 15:25, 25 October 2006 (EDT)

Crushing blow chance
Duvon's last edit to Example 3 changed the Crushing Blow chance for the boss mob from 15% to 35%. Assuming that the target has 300 Defense, this does not match the numbers shown in the Formulas:Defense article -- a boss mob is considered level 63 for all intents and purposes, and as such only 15% of its attacks should be Crushing Blows against a level 60 target with fully trained (but otherwise unbuffed) Defense.


 * Tracer 17:04, 13 November 2006 (EST)

This page needs to be updated to reflect the chage to Crushing Blows made around the release of Lich King. Boss mobs can no longer crush players, although mobs 4 levels higher can. --Darth603 (talk) 15:23, 7 August 2009 (UTC)

= True Sequence Table =
There seems to have been a lot of speculation about the order of combat results in the 1 to 100 chart. I have changed the sequence of the entries in the combat chart for this page to reflect that which is really in WoW. However, there are MANY examples using an incorrect order of combat events, and fixing them all is a bit beyond my available free time.
 * --Beaza 16:28, 30 November 2006 (PST)

Your comments in the article indicate that the precedent order, as currently listed in the first table, is "from Blizzard", implying that Blizzard has made a statement to that effect. Did a Blizzard representative actually make such a statement? I'd like to see it in print so I can include the statement in this article.
 * -- Tracer 14:53, 1 December 2006 (EST)

I don't have anything (web page etc) I can point you to, but I am sure it's right. Trust a stranger. :)
 * --Beaza 21:37, 1 December 2006 (PST)

There is NO official comment from Blizzard about the order of the attack table. Actually the whole article is speculation until officially confirmed. And that needs to be clearly stated.

JDeVille 19:42, 15 April 2008 (UTC)

Possible fault in Single Table Theory
This is a recent development and I considered that it possibly casts doubt onto the entire theory of a single table deciding attack results. What I wish to consider is the addition of dual wielding to the Shaman class and the way this interacts with Stormstrike.

When using the Stormstrike ability while dual wielding any successful defensive actions (parry, dodge, possibly miss even I will need to double check) occur a single time for the ability, there is a single line in the combat log indicating that your Stormstrike failed, however assuming you're stormstrike is not somehow prevented the two weapon swings will have certain events, most notably critical strikes, calculated separately.

This is to say, if your Stormstrike fails, both swings fail, but if a crit occurs, it is only one swing that has crit, and the other has to crit separately (I have seen them both crit in addition to single crits or non-crits).

while this could be an exception to the norm it clearly demonstrates two seperate things being worked out by the server.

Using this table (since as a yellow dmg attack it cannot glance) I can say for certain that it seems to be calculating down to parry and possibly block (I will double check this with a warrior) treating Stormstrike as a single attack and then calculating the final 2 steps after separating them into two swings.

The only explanation other than two separate checks would be that each swing checks separately the whole time and if a dodge, parry, etc. occurs to either one, both fail, but this would seem like an unfair solution giving people a better chance to avoid stormstrike than any other melee attack.


 * Basic melee and ranged attacks use a combat table. The occasional (but rare) "melee" ability is actually handled almost like a spell on the server. The server does its best to make it seem like a melee attack (with dodge, parry, block, etc) but it's really just a special case.
 * --Beaza 09:51, 20 December 2006 (PST)


 * That doesn't wholly explain why the stormstrike is treated as a single attack on occassions and two separate ones at other times, if an AoE spell can be resisted by a single mob and hit the rest normally. Unless the implication is that the melee events (dodge, parry, etc) are simply layered over a spell for melee abilities, making these melee abilities the only thing with 2 separate tables occuring? Or am I wrong in assuming spells operate off a similar table?
 * --Drunkspleen 17:52, 21 December 2006 (PST)


 * Spells do not have a combat table. Spells are either fully resisted or not. If a spell also does damage (not counting melee abilities) then it passes through a second filter that can reduce the amount of damage taken (including being reduced to 0 damage, which is displayed like a full resist from pass 1).
 * --Beaza 09:34, 8 January 2007 (PST)

Question regarding Paladin Talent, Precision
Hi, could anyone please explain how Precision fits into all this? Since an ordinary hit has the lowest priority in the table, anything above 100% is truncated and Miss/Dodge/Block/Parry/etc percentages are absolute, wouldn't that mean the bonus 1% - 3% that a Paladin gets from Precision is useless?

Thanks!


 * "Hit" is the opposite of "Miss" in this case. The normal miss chance is 5% but that chance is reduced when you have items or talents that allow you to hit something better. A +1% to hit turns into -1% chance to miss, making it 4% instead.
 * --Beaza 19:38, 18 January 2007 (PST)

Another faulty assumption in the single table theory
Generating random numbers is relatively straight forwards and quick, it consists of performing a multiplication, an addition and a division.

True such methods do not generate numbers between 0-100 but then they can easily be made to generate values in the full range of positive integers (2^32 discrete values for 32 bit integers and 2^64 discrete values in the case of 64 bit integers) which should provide enough granularity to be effective, since the % chances in WoW seem to be rounded to 2dp rather giving at most 10000 discrete values between 100.00 and 0.00.

Further, I assume that rather than converting the random numbers generated to floating points and comparing them to the % chance of this or that, they convert the % values of such an event (e.g. a critical, glancing blow etc) to an integer by multiplying the maximum value for a randomly generated number by the % chance and storing this result as an integer.

i.e. if a 32 bit random number generator is used and the chance of a critical is 15% then all random numbers generated that fall below (2^32 x .15) are criticals.

This calculation needs only to be performed once each time a character's abilities change and will be more or less static for mobs.

Since all the operations performed in combat are integer operations they're relatively quick and straight forwards.

Compare this approach (i.e. making a simple quick and discrete roll for the chance of each type of hit/critical/dodge etc) to the work involved in recalculating a whole table each time a character moves or is affected by a buff, debuff etc etc (and the same for all mobs) and the argument that the single table approach is more computationally efficient begins to fall to pieces.

Just think about it, each time a mob's status changes tables have to be recalculated for all player characters in their vicinity and vice versa, it just doesn't make sense.
 * --DaveTheJackal 11:38, 28 March 2007 (PST)


 * All of your theories about whether it's handled with integers or floating point have nothing to do with using a “table” format. As for you theory the game would have to recalculate entire tables for everyone in a region, that’s just not how programs work. Each value (chance to dodge, block, parry, etc) is stored separately. If one of those values changes then only that value changes. There is no need to change an entire table because describing the “table-based approach” is just a means of making the concept understandable to non-programmers. There is also no reason to change entire tables because there is no reason to recalculate anything before that value is needed. IF it had been a true logic table then that table would have been marked as “dirty” when a value changed but never recalculated entirely until the table were needed again, IF it were needed again. That’s how you make efficient code. However, that point it moot because in reality it’s ONE random roll and then a series of checks to determine the number range under which that one roll has fallen, and thus which result has just occurred (is it a dodge, parry, etc). In fact, the first number range discovered that matches suspends further math. For programmers, the pseudo-code would be something like this:
 * roll = get a random value
 * if (roll is between 0 and the miss chance) {
 * it’s a miss
 * return
 * }
 * if (roll is between miss and miss+dodge) {
 * it’s a dodge
 * return
 * }
 * if (roll is between miss+dodge and miss+dodge+parry) {
 * it’s a parry
 * return
 * }
 * // and so on -- note in this I did not simplify the code to make it faster because it's pseudo-code to show the idea
 * Finally, you can see here that another theory of yours (that order does not matter) is only true until the total sum of all chances is greater than 100% because then the random roll can never reach combat results that would require rolls above 100%. (P.S. How did you post from the future? It's only 9am PST. )
 * --Beaza 08:52, 28 March 2007 (PST)
 * if (roll is < miss%) {
 * do_miss
 * }
 * else if (roll is <dodge%) {
 * do_dodge
 * }
 * else if (roll <parry%) {
 * do_parry
 * }
 * makes much more sense to me. BTW Didn't anyone ever tell you to never ever ever have more than one exit point from a subroutine? No, with an optimizing compiler it is not any more efficient. ;-)
 * Another gem of wisdom he might have passed on to you is K-I-S-S, "keep it simple stupid". Not only makes code much more maintainable but makes the life of the optimizing complier much easier in making your code fast and efficient to execute. The people at blizzard have far more complicated things to worry about without making the combat resolution so complicated.
 * --DaveTheJackal 22:00, 28 March 2007 (UST)
 * I'd like to respond to this bit from above: "Just think about it, each time a mob's status changes tables have to be recalculated for all player characters in their vicinity and vice versa, it just doesn't make sense." Well, look at it this way.  There are 6 or 7 numbers that need to be recalculated if something changes, % chance to miss, dodge, parry, etc.  These numbers have to be constantly updated regardless of how many rolls will be used.  There's no overhead in "keeping a whole table up to date".  That phrase is loaded.  The same numbers have to be kept up to date in both systems.


 * Also, DaveTheJackal, the Single Roll theory has been proven. It is possible to stack up enough miss, dodge, parry, and block that crushing blows are pushed off the table.   The numbers are usually about 10% miss, 15% parry, 15% dodge, 60% block.  With this much mitigation, tanks are never crushed.  Under a multi roll theory, crushing blows would still happen, whenever an attack was not a miss, parry, dodge, or block.


 * Thirdly, Blizzard has slyly (wink wink nudge nudge) confirmed the single roll theory


 * I can see you have problems understanding WHY they would use a single attack roll. IMHO it is keep the accuracy of the character sheet.  If your character sheet shows 5% block, 5% parry, 5% dodge, etc., the only way to keep those numbers true is to use a single roll.  With multiple rolls, then the percent chance of one result depends on where it falls in the check order.Emit 15:23, 29 March 2007 (EDT)

Yet another questionable point about the single table theory
In the single table theory what does the precedence of one attack type over another actually mean?

Answer: nothing, it's just the order in which things appear on the table and they may as well appear in any order since it's a single table and ordering makes no difference.

For the multiple roll approach it makes perfect sense and does have a real effect on game play: first a miss is checked for if that doesn't happen they check for a dodge by the enemy, then a parry and so on.

If one even occurs there's no need to check further down the table as the result of the strike is known (increasing the efficiency of a multiple roll approach even further).

Since criticals can apparently be parried this might further suggest that separate sets of rolls is made for attacker and defender and the outcome of each (attack and defense) is decided separately.
 * --DaveTheJackal 12:52, 28 March 2007 (PST)


 * And as for this last theory, again efficient code does as little as possible in the smallest amount of space possible. You would not make a series of random value rolls (that are actually quite expensive compared to normal every day code) for every single swing of every single weapon in the game for every player on the server over and over and over. No, you make one roll per swing and figure out a way to get all the results you need from that one random value. That’s how you keep the code small and efficient to support thousands of players at the same time on one machine. It IS one random roll per combat swing. In fact, you’re not thinking through the math. If you have a series of checks with variable chance, and then you change one of the earlier percentages then you are inadvertently changing all future chances as well. This can be demonstrated with two results. Let’s say there is only miss and dodge (and of course hit is what’s left over). Let’s say you have a 20% chance to miss and 20% chance to dodge (thus 60% will be a hit on what’s left over). In reality this will be 20% miss, 16% dodge, and 64% hit because only 80% of the time will it be a non-miss result. If 20% of the non-miss results are a dodge then 16% of the time you’ll dodge. If the miss chance were to drop from a buff, to say 10%, then suddenly dodge rates change as well because 10% of attacks will miss and 90% will not miss. Of the 90% there will be 20% dodges which is now suddenly 18% (as 20% of 90%) and hits have become 72% of attacks. WoW chances to miss, dodge, parry, etc do not change in ways dependent upon each other so this is yet further proof there is one random roll.
 * --Beaza 09:13, 28 March 2007 (PST)


 * Random number generation is NOT expensive compared with everything else in the game, a pseudo random number is generated using the formula
 * r(n+1) = (A.r(n)+M) mod C
 * Where r(i) is the ith number in the sequence and A, M and X are constants. Like I said one multiplication, an addition and a division. Whether integers or floating point is used IS important as processors perform integer operations orders of magnitude faster than floating point. Compared with the number of multiplications additions and decisions that have to be made in constucting just one of your tables this is nothing. Look at the length of your explanation and the number of different contingencies the code would have to cope with whilst building those tables each time a player's situation changes, not to mention the data storage needed, and you will see just how much more work is required your way. Plus the fact that, as you stated, blizzard has said that certain types of outcome of a player attack have precedence over each other, how is this reflected in your single table method? The answer is that it is not. How long would each of your tables last? One maybe two hits before something changes on the battle field? A mob moves or a short lived player buff fades? Each time several complicated computations have to be performed and tests that determine what goes in to one of these tables. It just doesn't hold water. At least not in the eyes of a C/C++ programmer of 20 years experience (me).
 * "WoW chances to miss, dodge, parry, etc do not change in ways dependent upon each other so this is yet further proof there is one random roll." - you have statistical proof of this? You have already stated that according to your theory numbers sometimes get pushed off the table, this would change the probability of them occuring FAR more than the small changes in value shown above.
 * --DaveTheJackal 21:49, 28 March 2007 (GMT)
 * this bit: "How long would each of your tables last? One maybe two hits before something changes on the battle field? A mob moves or a short lived player buff fades? Each time several complicated computations have to be performed and tests that determine what goes in to one of these tables. It just doesn't hold water. At least not in the eyes of a C/C++ programmer of 20 years experience (me). "


 * look at his pseudo code above. The table is just a metaphor.  There isn't an actual table data structure that has to be updated.  Look here:
 * if (roll is between 0 and the miss chance) { it’s a miss ;return }
 * if (roll is between miss and miss+dodge) { it’s a dodge ;return }
 * if (roll is between miss+dodge and miss+dodge+parry) { it’s a parry ;return }
 * Ignore the fact that he uses "return" instead of "else" for a minute. U just do this in the attack function, you don't maintain actual attack tables..... I can see why the idea looks stupid if you envisioned each characters data structure had an array of pointers to huge combat tables. LOL! of course thats not how it is. srsly Emit 16:05, 29 March 2007 (EDT)
 * "No returns in a routine" was one of things they taught in school that I learned in real life is not as practical for writing and maintaining real applications as is it on paper in a class about the theory of programming. (Life > School) Back to my point, like I said, it was pseudo-code. Let's go ahead and assume it's "if else else else" like you wrote, but instead of a roll for every conditional it's using the same roll but changing the range tested, the same way I wrote. I think the point we're discussing is whether there's more than one roll and not whether the routine has returns.
 * Looking at your example, if your miss% changes then every percentage chance of tests after it also changes (your dodge% and parry% etc). Run any combat logger and you'll see that your chance to miss, dodge, parry, etc are not changing from the values displayed in your UI against even-con creatures regardless of changes to any ONE of those values. (I.e. if you add dodge rating then parry chance does not change.) For your code to still function correctly, any change to miss% would have to reverse engineer a new dodge% and parry% etc to keep the same UI values. This means not only are you making useless random rolls, but you are adding even more code to “renormalize” the non-miss percentages back to their proper values. Also, doing work is always slower than not doing work, so it doesn’t matter if rolling random values is “slow or fast”, not rolling a value is always faster than rolling one.
 * Also, regarding maintaining the code, we cannot forget that this was written over the course of a whole beta. I played in the earliest of Alpha through a special contact, and therefore of course in every Beta as well. I saw the combat code change over time. Imagine the nightmare for a designer to try to balance the combat system if every time he changed someone’s dodge value their parry value changed too? Or imagine the nightmare for the programmer who would have had to rewrite the reverse engineering function that renormalizes all subsequent percentages. Or, even if you imagine it the way I wrote in pseudo-code there is technically a problem. The designers would not be able to reorder the tests (like to make parry come before dodge) without also rewriting the way the range values were calculated. If you want to be picky about the pseudo-code I write then I will propose something better:
 * roll = Random
 * if (Miss(roll))
 * DoMiss;
 * else if (Dodge(roll))
 * DoDodge
 * else if (Parry(roll))
 * DoParry
 * else if (Glancing(roll))
 * DoGlancing
 * else if (Block(roll))
 * DoBlock
 * else if (Crit(roll))
 * DoCrit
 * else if (Crush(roll))
 * DoCrush
 * else
 * DoHit
 * // each of the routines of the form if (Miss(roll)) would be like this:
 * bool Miss (float& roll) {
 * // do stuff here related to accessing or calculating miss_chance
 * roll = roll - miss_chance
 * return roll <= 0
 * }
 * // This form of the code would make is use as little space and time as possible, and would allow designers to reorder the tests any way they wished without affecting the balance, and would allow the designers to adjust the percentage values without affecting the balance of any other variables except the one changed.
 * The "combat table" people talk about is just a simple way of expressing how the above code would effectively function. I'm not a fan of calling it a combat table, but there is no doubt at all that one roll is made for each swing.
 * --Beaza 14:19, 28 March 2007 (PST)
 * '"No returns in a routine" was one of things they taught in school that I learned in real life is not as practical for writing and maintaining real applications' yes there are situations where it's not practicable or way easier to us a return but doing things the way you wrote them? 'Spagetti programming'.
 * 'not rolling a value is always faster than rolling one.', not if the number of additional checks and calculations you have to perform is greater, which I believe would be the case in your scheme. Not to mention the overhead of storring all these values (at least one table for each player and/or mob, dynamically created as the game plays. It's just nonsense.
 * 'you are adding even more code to “renormalize” the non-miss percentages' show me the statistics that any renormalization occurs and I'll believe you. Using your method no renormalization takes place and as you admit gross changes in the % chance occur when some values are pushed off the table. You do not seem to have any basis for your predictions here. Does this 'pushing of values off the table occurr? Do you have the stats to prove it?
 * According to at least one talent calculator I have used the actual chances of criticals etc shown DOES in fact differ from the % chance shown on my character sheet. Perhaps this is the renormalization to which you refer?
 * Please present your evidence and I will bow to your better judgement, the one piece of evidence that is presented is that of the backstab, which is show statistically to adhere much more closely to a multi roll methodology than a single roll.
 * An no I will not 'take the word of a friend'.
 * --DaveTheJackal 00:37, 29 March 2007 (GMT)


 * I've given the facts. You can accept them or not. Just let me advize you keep digging on this one if you're not buying it, because it's one roll. It is.
 * --Beaza 16:45, 28 March 2007 (PST)
 * The point I'm trying to make is that oppinion and supposition have no place in a wiki when presented as fact. How do you know it is one roll? Please, present your evidence. I see nothing to support it, and given that multiple roll algorithms *seem* to be used by some talent/DPS calculators (though I cannot be sure) the weight of opinion seems to be against you. At what level, for example, would criticals against a MOB become impossible using your formula?
 * Edit: your information regarding spell resistances also seems to be incorrect, i frequently get messages saying 151 damage (51 restisted) for shadow bolts (my main is undead). How so if spells either work or not? --DaveTheJackal 00:37, 29 March 2007 (GMT)
 * it is one roll. see my bit above.  Also, go ask this question @ forums.worldofwarcraft.com, you will be answered thoroughly.  try the warrior forums.Emit 15:41, 29 March 2007 (EDT)
 * I'm done with combat. I'll answer your spells question though. Spells that deal damage can fail entirely for two reasons (1) the target resists due to level difference or (2) the target reduces the damage to 0 through spell resistance (which appears in your log as a resist as well, so there is no way to tell them apart). Spells that do not deal damage are either resisted or not, and if not then the spell effect is applied. Spells that deal damage but are not fully resisted do 25%, 50%, 75% or full damage, again based on resistance. If the target has no spell resistance then you won't see any partial damage values, so the example you gave appears to be a 75% damage result on a target with some spell resistance.
 * --Beaza 17:16, 28 March 2007 (PST)
 * Well at least your comments on spells make sense. What exactly does 'i am done with combat mean'. Can't provide any statistical data at all? I'm not sure how the glancing blow % is calculated in your formula but i have scored both normal hits and criticals against creatures +5 levels, is this true to your calculations? I was front facing with 17% critical.--DaveTheJackal 14:07, 29 March 2007 (GMT)


 * It means I do not intend to provide the source of my proof, so I didn't think there was a reason to continue that debate. Glancing blow % chance and % damage are already in the wiki on another page. The parts that I have not already rewritten were correct before I read the page. The parts that were wrong I fixed and the parts that were missing I added. You can read about it there. Critical hits, as I recall, were already correct when I first saw the page so I changed nothing meaningful that I remember. You can read about critical hits on this wiki for that info. In both cases the last time I checked was at level 60, but since nothing significant about those parts of the combat system change, I assume those pages are still correct.
 * --Beaza 09:04, 29 March 2007 (PST)


 * DaveTheJackal wrote on 28 March 2007:


 * In the single table theory what does the precedence of one attack type over another actually mean?


 * Answer: nothing, it's just the order in which things appear on the table and they may as well appear in any order since it's a single table and ordering makes no difference.


 * It DOES makes a difference in the case where all the possible outcome chances combined exceed 100%. Take a look at the second table in Example 2 in the article.  Because the combined miss, dodge, parry, block, and critical hit chance of the attack is greater than 100%, one of those outcomes has to get at least partially "pushed off the table."  Since critical hit has lower precedence than the other 4 outcomes, it's the critical hit chance that gets reduced.


 * Since criticals can apparently be parried this might further suggest that separate sets of rolls is made for attacker and defender and the outcome of each (attack and defense) is decided separately.


 * Criticals can be parried? How so?  There's certainly no indication in the combat log of a "parried crit".


 * --Tracer 20:26, 9 May 2007 (EDT)

Table might need two columns to be clear
The sum of Block and Parry values are "soft-capped" collectively at 15%, right? Then group Miss, Dodge, and Parry under the collective heading "Miss Outcomes". Group Glancing Blow, Block, Critical, Crushing Blow, and Ordinary Hit under the collective heading "Hit Outcomes". Dictate that "Miss Outcomes" cannot collectively exceed 85% of all possibilities, regardless of its composition. Now Block can override Crushing and Crit, but the others can't -- just like we've observed so far.

I don't know whether Ordinary Hit should be a default belonging to neither category. We'd have to get someone with insane Dodge and Parry, and Resilience enough to eliminate Crit chance, to fight something his own level and find out. Druids can reach this point with the aid of trinkets, but they can't Parry. Rogues?

One interesting side effect, if this is all accurate, is that a sufficiently high Dodge chance can cramp Parry down to zero. 18:50, 7 July 2007


 * Never heard of this "soft-cap" before. Could you cite a source for this?
 * --SeerBlade 18:37, 27 November 2007 (UTC)

Yellow damage two roll system
I'm not convinced that a 3% discrepancy in Vulajin's crit rate over an uncontrolled sample of mobs proves that Yellow attacks use a two roll system. Is there any other evidence of this that has been gathered since TBC? Has anyone tried a more controlled demonstration of either one or two die roll systems for other Yellow attacks? Even if we do have conclusive proof of a two roll system, do we know how that two roll system works and can we put those details into this page?

--SeerBlade 18:37, 27 November 2007 (UTC)

Example 2
As in Example 2 is written the chance to miss, dodge, parry and block are 9%. After checking the single categorys 9% are only for the chance to miss right. Dodge must be 6,5%; parry around 12-15%.


 * The change to Weapon Skill mechanics in 2.1 increased the base Miss Rate vs. level 73 mobs from 5.6% to 9%. It is not clear to me whether the base Dodge, Parry, and Block rates vs. level 73 mobs also increased from 5.6% to 9%, but it's probable that they have.  Anybody have any data or links to official posts?  -- WoWWiki-Tracer 16:06, 29 April 2008 (UTC)

Magic-damage melee special attacks that can be blocked
The subsection on Magic-damage melee attacks states that such attacks cannot be Blocked.

While this is certainly true for magic-damage melee auto-attacks, such as the melee swings from fire elementals, there have been cases where I've seen magic-damage melee specials get blocked. (For instance, while fighting the Erratic Sentries on the Isle of Quel'Danas with my protection paladin, I've seen more than once in my combat log "Erratic Sentry's Crystal Strike hits you for 114 Arcane (204 Blocked)."

Does anybody know whether magic-damage melee specials dealt by players can be Blocked? (E.g. Seal of Command procs?)

-- WoWWiki-Tracer 16:03, 29 April 2008 (UTC)

on the dual wield formula page it is said that base miss chance vs raid mobs would be 24.6% which is obviously not equal to 28%. someone should correct this

(http://www.wowwiki.com/Formulas:Dual_Wield)

Crit before Block?
I believe that combat table needs to be adjusted: critical hits occur before blocks in the attack table. The reason for this is two-fold: first, it would have been possible to reach crit-immunity once you become uncrushable without stacking defense rating or resilience. Secondly i made a small test on my level 18 warrior fighting a level 11 bear (level difference gives me 5.6% extra avoidance) so that blocks are slightly hanging over the table with Shield Block up. Combat log shows : Sillygnome gains Shield Block. Elder Black Bear's melee swing hits Sillygnome for 15. (Critical) Elder Black Bear's melee swing hits Sillygnome for 4. (7 Blocked) Sillygnome's melee swing hits Elder Black Bear for 36 Physical. Shield Block fades from Sillygnome.

Fibby (talk) 23:52, 11 August 2008 (UTC)

What was your shield block percent, and how much defense did you have? According to my proposed formula below, your example would be possible if you didn't remove crits from the attacker's table, and your block rating was less than 100% (since shield block along only raises it by 75%). Say the attacker didn't roll a miss/dodge/parry, and you failed the block roll for the first hit. The hit would go through, and if it was originally determined to be a crit, then a crit it would be. Highly unlikely given the circumstance, but within the realm of possibility. The second hit was blocked (shield block = 75% for 6 seconds), and its damage reduced accordingly. --DocMartin (talk) 22:20, 1 January 2009 (UTC)

Uncrushability = complete melee immunity?
As stated by the pages for Attack Table and Uncrushability, the idea behind attaining uncrushability is to fill out the boss' attack table with Miss, Dodge, Parry and Block.

Unless critical details have been left out, this means that Uncrushability is actually melee immunity (at least in case of frontal attacks vs. passively Uncrushable tanks).

If Uncrushability 'does not' equal melee immunity, it should be explained why not.

If Uncrushability 'does' equal melee immunity, this is obviously significant enough to deserve clear-cut mention, beyond the following line I dug out at the Crushing Blow page: "This amount of avoidance and mitigation pushes crushing blows (as well as crits and normal hits) off the Attack Table."

I would have added the "melee immunity" conclusion straight to the main articles, but I assume I'm missing a point since noone else pointed it out?

Saying that Holybrick now cannot be crushed seems like a massive understatement if truth is he can't be hit at all?


 * If I understand the question correctly, melee immunity is not possible, pretty much because of caps implemented by diminishing returns. However, when your total avoidance is 102.4% or higher (calculated with DR in mind), regular hits fall off the combat table, and "combat rolls" can only result in a a) miss, b) parry, c) dodge, or d) block. A blocked hit, however, is still only partially mitigated. The original amount of the hit will be reduced by your armor and block ratings, but you will still take a hit. -Howbizr (talk) 19:53, 7 March 2009 (UTC)


 * Clarification: When the character hitting is level 80, and the mob is level 83, it's 102.4% avoidance. If the attacker (like in pvp) is only level 80, then only 100% avoidance is needed to have regular hits fall off the table. -Howbizr (talk) 19:55, 7 March 2009 (UTC)

Yet Another Multiple Roll Conspiracy
Here's the way I envision the two-roll combat table (precedence: miss,dodge,parry,block,crush,crit,hit) It's a pseudo-lua example to relate to the wow environment. I'm using 0-100 as simplified example, without going into detail for 102.4%, though it can be easily accounted for with variables. The code for this would not be terribly CPU intensive.

local miss,dodge,parry,block = player_defense_values local crit = mob_crit_chance - player_defense_values local crush = mob_crush_chance local mob_rnd = random_number(0-100) if (mob_rnd < miss) then do miss elseif (mob_rnd < miss+dodge) then do dodge elseif (mob_rnd < miss+dodge+parry) then do parry else if (event == swing and element == physical and player_has_shield) then mob_rnd2 = new_random_number(0-100) if (mob_rnd2 > block) then do block else check_crit(mob_rnd) end elseif (event == swing) then check_crit(mob_rnd) else do spellhit end end local check_crit(mob_rnd) if (mob_rnd < crush) then do crush elseif (mob_rnd < crush+crit) then do crit else do hit end end

Now with comments: --get the attacker/defender percent values to fill out the combat table local miss,dodge,parry,block = player_defense_values local crit = mob_crit_chance - player_defense_values local crush = mob_crush_chance --attacker rolls a random number to see if the blow is landed local mob_rnd = random_number(0-100)

--miss, dodge, and parry are mutually exclusive events if (mob_rnd < miss) then do miss elseif (mob_rnd < miss+dodge) then do dodge elseif (mob_rnd < miss+dodge+parry) then do parry else --after miss/dodge/parry take precedence, it could be blocked if (event == swing and element == physical and player_has_shield) then --attacker rolls again, against block percent mob_rnd2 = new_random_number(0-100) if (mob_rnd2 > block) then do block else --hit goes completely through --still use the first mob_rnd so that if it was a crit originally, it was already pre-determined (according to blizz) check_crit(mob_rnd) end --player can't block, or this melee was some kind of elemental damage elseif (event == swing) then check_crit(mob_rnd) --spell damage would be here (mob spells can't crit) else do spellhit end end Attacker crush/crit check would be a function: local check_crit(mob_rnd) --crushing blows take precedence on the mob's hit table if (mob_rnd < crush) then do crush --then check crit chance (could be reduced to zero) elseif (mob_rnd < crush+crit) then do crit else do hit end end

When a combat event happens, the attacker and defender stats are noted. The only way a crit CANNOT occur is if the player's defense/resilience reduces the mob's crit chance to zero, or if it's blocked ("pushed off the table"). The only way a crushing blow CANNOT occur is if the mob starts with zero chance or if the player's block value is 100 percent ("pushed off the table"). If miss+dodge+parry is sufficiently high but not 100%, it drastically reduces the chance of receiving a crushing blow (but not reducing it to zero). We know that players that can't block (druids) have a higher chance of being crushed. We also know that elemental melee attacks (like fire elementals or hydross) can crit but cannot be blocked.

I'm still leery of the term "passively uncrushable". 100% miss+dodge+parry is unhittable. 100% block is uncrittable/uncrushable. 100% miss+dodge+parry+block just lies somewhere in between.

Since I don't have a concrete example, I'll use what was posted above: "10% miss, 15% parry, 15% dodge, 60% block is uncrushable". Out of 100 attacks, 40% won't hit you. Out of the 60 attacks that do hit, 60% will be blocked. Out of those 24 that really hit you, 15% of those could be crushing. Statistically speaking then, 4 attacks out of 100 could be crushing blows (worst case scenario). That's assuming you're just standing there. With random numbers, stats changing during the fight, shield block, etc, there's a real good chance that you'll receive zero crushes... but I don't have any WWS to prove it. --DocMartin (talk) 22:20, 1 January 2009 (UTC)


 * I'm working on updating these articles, but I just wanted to make a couple key points:
 * Crushing blows have basically gone away. You can only get crushed if something is 4 levels or more above you. Raid bosses, the highest level mobs, are only 3 levels higher than you.
 * I don't think you can push crits off the table from 100% block chance. Assuming you had no other avoidance, zero agility, etc... You'd still have 5% base miss chance, plus 5.6% crit chance (assuming you were level 80, and the boss was level 83). However, 10.6% of that 100% block chance would get wasted, and pushed off the table. -Howbizr (talk) 20:06, 7 March 2009 (UTC)