Base potency 100
I’ve heard a lot of smart players suggest potency starts at 100. But that’s inconsistent with anecdotal experience and with abilities or modifiers based on potency. Does anyone have documentation tha...
Forum Discussion
The 100% potency is not strictly accurate but it is a way to help understand what's going on. The starting point before tenacity and potency is that a debuff WILL be applied , as opposed to will always NOT be applied. What this means is that if they have 10% tenacity and you have 0% potency it is 90% likey the debuf WILL be applied on first check, but there is a second check as all debuffs have a 15% chance to be resisted. Many people assume if the tenacity is higher than the potency it will not apply , this is not the case. There is also a second check , and again this is not a minimum 15% tenacity , it is a straight 15% chance to resist any debuffs regardless of the tenacity vs potency check.
To work it out , take the potency as a decimal , add "1" and subtract the decimal tenacity. I.e 50% pot vs 125% ten = (1+ .5) - 1.25 = 25% chance to apply on first check , then 85% chance to apply on second check. The most practical example is if you want to make sure wampa does not get stunned by iden they have to have 100% more tenacity than the idens potency after all bonuses.
Some examples.
100% tenacity vs 100% potency = 100% chance to pass first check 85% chance to pass second check so 85% chance to apply.
0% tenacity vs 100% potency = 85% chance to apply
201% tenacity vs 100% potency= 0% chance to apply
Hope that helps.
This is not correct.
There are not 2 checks. There is one check to resist (except in cases where a debuff cannot be resisted or in cases where the defender is immune to that debuff, and in those cases there is no check at all).
The ONE check to resist has a percent chance to resist of (Defender's TEN minus Attacker's POT) or 15, whichever is larger.
- If my TEN is 100 and the attacker's POT is 122, then my chance to resist is 15%.
- If my TEN is 100 and attacker's POT is 101, then my chance to resist is 15%
- If my TEN is 100 and attacker's POT is 90, then my chance to resist is 15%.
- If my TEN is 100 and attacker's POT is 84, then my chance to resist is 16%
- If my TEN is 100 and attacker's POT is 75, then my chance to resist is 25%.
And so on. But it's always only one check.
Chance to resist is not the end of the story though. It's then checked against the random number generated to see if that instance lands or not based on it's chance to land. The result has to be a yes or no. As I have said below the "check" is not the same as a second calculation, it was a way to explain what might be coded as that was the OPs request. The poor performance of things like tuskin momentum or large numbers of dots in conquest suggests this is a problem area on low end devices. There are many ways to code the sequencing of the "checks" to determine if the answer is "yes" or "no" that will have quite different impacts on the performance of the application. On very old main frame devices it was often better to run the calculation split into components. Ie rather than doing 1+2+3=6 you would do 1+2 =3 then 3+3=6. (Grossly simple example). That's what I was trying to convey , not an independent second calculation. Probably my bad for the confusion.
To be fair, my request was not an explanation at all. I’m asking for documentation to end the debate. I know we can’t see code, I’m asking for something from CG that says what is true.
