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.