• Welcome to The Cave of Dragonflies forums, where the smallest bugs live alongside the strongest dragons.

    Guests are not able to post messages or even read certain areas of the forums. Now, that's boring, don't you think? Registration, on the other hand, is simple, completely free of charge, and does not require you to give out any personal information at all. As soon as you register, you can take part in some of the happy fun things at the forums such as posting messages, voting in polls, sending private messages to people and being told that this is where we drink tea and eat cod.

    Of course I'm not forcing you to do anything if you don't want to, but seriously, what have you got to lose? Five seconds of your life?

Need coding help with catch rate percents

Rot8er_ConeX

New member
Pronoun
he
I'm trying to make a Pokemon fan game, and one of the features of the Pokedex is the stats page, which shows species/form-specific stats that are normally invisible to players - the base stats, EV yield, base happiness (which is referred to in game as "initial friendliness"), egg steps to hatch (for Pokemon that have eggs), etc.

One of the things posted in this page of the Pokedex is the Capture Rate. I have the "rareness" numbers in their most up-to-date forms. These numbers display as both a number and a bar as if from a bar graph. But I'd also like to display a "using a Pokeball, while the Pokemon is at max health" kind of number, like the percents that Bulbapedia has in their capture rate sections. Upon browsing their links, I eventually found a link to this lovely algorithm.

I want these "likelihood of capture" percentages to work under the following assumptions, which are the same ones that Bulba used for theirs:
- The player is throwing an ordinary Poke Ball (Ball Modifier of 1)
- The Pokemon trying to escape is at full health (so HP(max)*3-HP(current)*2 becomes just HP(max)*1 and therefore the two HP(max)es on either side of the fraction cancel each other out).
- The Pokemon trying to escape does not have a status affliction (Status Modifier of 1)
- No O-Powers or Pass Powers will be used, because they don't exist in my game.
- No "mystery grass" modifier.
- A Critical Capture won't happen. (so that CC/255 is 0 and that 1-(CC/255) is 1)

Which means that:
X=((3M-2H)*G*C*B/3M)*S*O
X=((3M-2M)*1*C*1/3M)*1*1
X=((M)*C/3M)
X=C/3


Y remains as it is:
Y=65,536/((255/X)^(3/16))

Now, here's where I'm confused. How do I convert this number Y into a meaningful percent? I tried the formula given on that calculation page ((Y/65,536)^4, with a multiplication by 100 in order to turn it into a percent rather than a decimal. I am now getting percents that are slightly higher than those displayed on Bulbapedia, or on this calculator. Is this merely because I'm disregarding critical captures?

In case anyone's curious, here's my actual code, in Ruby:
Code:
    catchPercentX=catchRate/3
    catchPercentY= 65536 / ((255/catchPercentX)**0.1875)
    catchPercent=((catchPercentY/65536)**4)*10000
The resulting number is then divided by 100 to create a percent that has two decimal places.
 
Last edited:
Bulbapedia's displayed percentages are wrong; they're assuming the capture chance is X/255, when in reality the formula in gen 5/6 works out to (X/255)^0.75 (they're effectively using the fourth-generation formula, although that's also a wrong approximation of that because of rounding errors). Are you sure your numbers aren't lining up with my calculator even when there's no chance of a critical capture? Can you give an example where your results differ from the calculator?
 
Abomasnow
Your calculator gives a result of 14.815%
My code gives a result of 15.51%

Machop
Your calculator gives a result of 33.773%
My code gives a result of 35.35%


Honestly, now that I know Bulbapedia is not to be trusted because they're stuck in Gen IV, and looking at how close the results are, it MAY be because I'm forgetting to round certain things down or something.
 
I'm getting 14.821% if I do the calculation you posted above for Abomasnow (the difference between 14.815% and that makes sense as a result of the rounding to the nearest 1/4096 that the game does, and which my calculator emulates, but that wouldn't account for the bigger difference that you're getting).

From some brief Googling, it looks like Ruby does integer division by default when its operands are both integers. This would mean catchRate/3 gets automatically rounded down to the nearest integer (because both the catch rate and 3 are integers), and so does 255/catchPercentX (because catchPercentX got rounded down, so both that and 255 are integers). If I perform these as integer divisions, I get the answer of 15.51% for Abomasnow like you are. So it looks like that's the issue! You should be able to fix it by explicitly using floats: if you write catchRate/3.0 and 255.0/catchPercentX, you should get the correct result (apart from that rounding, but given you're only using four significant digits, it's definitely correct enough without bothering with that).

Hope that helped!
 
Huzzah, that worked! I wasn't able to impliment it until now because the wind decided to knock down a crapton of power lines near where I live...
 
Back
Top Bottom