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 that establishes this as true or false?
You have missed the point (understandable as the conversation pivoted from how does it work to how is it coded)
Okay, maybe you mean "steps" in a coding sense, and maybe the conversation did "pivot" but in your earlier comment you were using the word "check" not "step":
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 ,
If you really mean coding steps and not separate checks, then you should probably go back and edit this comment so that you don't confuse people. There is no second check.
My information is based on datamined information from near the beginning of the game. Those posts all say the same thing. It’s tenacity minus potency. There is nothing added to potency. The only modifier in the calc is the min 15% chance. It seems like the reason the 100% potency idea comes up is because people try to explain the mechanisms as if the debuff is checking to see if it lands. Basically from the debuffs point of view. My understanding is that the check is from the characters point of view. Can it avoid the debuff. From that point of view, there is only one tenacity check. And coding wise it’s very simple to set a min value to any check, so it doesn’t require two checks. It’s one calculation to get the value needed and then a “roll” to see if it’s successfully avoided.
All of this is second hand info though. I did none of the research and am just repeating what others who did the research said. There’s an article on https://gaming-fans.com/2017/05/understanding-potency-tenacity/#:~:text=PsychoPoet,%20author%20of%20our%20popular%20speed%20optimization,%20offense/CC/CD,
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.
you’re saying what he says here I think. But again, this is not documentation because CG hasn’t given its blessing. I’m wanting this because I don’t think we have all of the information and it’s important for how things work.
It’s based off information data mined from the game. You can see the development of the formula of you look through Reddit. I don’t believe CG ever released any specifics about how it works, but they seldom give details on how the game actually calculates anything.
For my purposes, it’s accurate enough. Much of the information we have on game calculations came through datamining and testing by players. I can understand wanting CG to give details, but without that I’ll trust this tested information versus speculation from people.
Capital Games TeamCapital Games Team
