Extremely high base power moves (e.g. max boosted Last Respects) cause impossible damage calculations

[InvalidOS]

I was messing around with creating an absurd damage calc involving Last Respects, but I noticed that it produced odd values, and absolutely huge ranges that seem impossible.

Here's some calcs showing this off:

50 - +6 252+ Atk Metronome Huge Power Houndstone Helping Hand Power Spot boosted Last Respects vs. -6 Lvl 1 0 HP / 0- Def Ralts on a critical hit: 29180-61316 (265272.7 - 557418.1%) -- guaranteed KO in 1 turns

5500 (impossible in-game, but resulted in an extremely weird calc) - +6 252+ Atk Metronome Huge Power Houndstone Helping Hand Power Spot boosted Last Respects vs. -6 Lvl 1 0 HP / 0- Def Ralts on a critical hit: 64-61912 (581.8 - 562836.3%) -- guaranteed KO in 1 turns

5050 (Last Respects cap, from using Revival Blessing to have Pokemon faint 100 times) - +6 252+ Atk Metronome Huge Power Houndstone Helping Hand Power Spot boosted Last Respects vs. -6 Lvl 1 0 HP / 0- Def Ralts on a critical hit: 2888-64032 (26254.5 - 582109%) -- guaranteed KO in 1 turns

Metronome was at 5 turns.

Some images showing settings:

50

5500

5050

[AnnikaCodes]

Why is this impossible? A level 1 Ralts has very low HP, so for a powerful attack to do between 2,600 and 5,600 times its HP is not that unreasonable?

[InvalidOS]

The impossible part is the extremely low damage rolls. Stuff like the 5500 BP Last Respects doing 64 damage, or even the 5050 BP one doing 3876. Those numbers are absurdly low for the moves being used.

[KrisXV]

That’s because of damage overflow.

[mmorrisonlk]

Expanding on what KrisXV said about damage overflow. The calculator has several references to OF32 which is defined in the util file as export function OF32(n: number) { return n > 4294967295 ? n % 4294967296 : n; } This function takes a number n and checks if it's over the unsigned 32 bit integer limit. If it is more than the limit it divides that by the integer limit and returns the remainder as the new value of n. So if we were counting at the top end it would go 4294967295, 4294967296, 1, 2, 3..

The surprisingly low values you noticed are one of the areas where the remainder of the division ends up on the smaller end. Though I'm sure that means that several values are over the integer limit even if it isn't as obvious as the 64 result. This limitation is not so much a limitation of the damage calculator but a limitation of how numbers are handled by TypeScript. There is likely a solution to this problem but it would involve a far more extensive rewrite of the overall calculator only to accommodate amusing theory crafting of absurd conditions.

In short, your number got too big. The calculator lied to you to save your computer getting upset with you. Unless this applies in a scenario remotely achievable in game then it isn't likely to be worth the time it would take to fix. Maybe they could consider adding an error message to let you know that you have caused an integer overflow and it had to round the number down? If people are really bothered by it.

[KrisXV]

That's not correct, this isn't a bug, this is 100% intentional.