Programming Pokémon Showdown Damage Calculator

View attachment 241816

Is the text of this calc intentional? If not, it’s probably something to look at
Did you make sure the clefable was at full life ? I noticed something similar yesterday where everything would ohko a mon using 30% damage dealing moves but that was because I had set the defending pokemon to 8% remaining hp in a previous calc and it stayed despite changing the species of the defending pokemon several times.
 

sanguine

friendly fire
is a Tiering Contributor
Did you make sure the clefable was at full life ? I noticed something similar yesterday where everything would ohko a mon using 30% damage dealing moves but that was because I had set the defending pokemon to 8% remaining hp in a previous calc and it stayed despite changing the species of the defending pokemon several times.
It probably had something to do with this, but I do remember the Clefable’s health remaining unchanged, but it’s fixed now for me anyway, so it ended up not mattering.
 

pre

pkmn.cc
View attachment 241091
PS user marcelodk noticed that outrage seems to be missing from the GSC calc (tested on Dratini)
Steel Beam is not a spread move and shouldn't be Doubles spread-reduced
I've verified that these should now be fixed. As of our latest deploy, our data is coming straight from PS, so we shouldn't have any more gaps or bugs in our move/item/abilities/species data going forward (unless PS also has the same bug!)
 

pre

pkmn.cc
Deployed a new version of the calc with these fixes.

it says oranguru is level 80..when he is level 88 in gen8 ty
Fixed, the tier being (PU) is what tripped things up. Thanks.

Setting a Pokemon's secondary typing to (None) makes it act as if it still has that secondary typing. (Changing it to an alternate typing works, but setting specifically to (None) does not).
Although it is currently a pure Water-type, Magearna still gets STAB on Fleur Cannon and is immune to Draco Meteor.
Fixed, thanks for the report.

Max flare seems to be working incorrectly in the calculator

Other max moves seem to be working properly.
Thanks, Max Flare turns out to very strangely have 100 BP in the game's data files whereas all the other damaging max moves are 10 BP which is what tripped things up. This should now be handled correctly.
 
Sandstorm (and hail) isn't being considered when calculating whether an attack has a chance to OHKO (it works fine when considering whether an attack has a chance to 2HKO).
252 Atk Gigalith Stone Edge vs. 252 HP / 252 Def Abomasnow: 320-378 (83.3 - 98.4%) -- guaranteed 2HKO after sandstorm damage
 
Why would it display the weather damage when the move is OHKO-ing?
I think they might mean it has a chance (but not a guarantee) to OHKO without sandstorm, and then sandstorm damage should increase that chance, but it's not taking that chip damage into account?
Here's one example:

Lvl 55 252 SpA Choice Specs Abomasnow Blizzard vs. 36 HP / 0 SpD Deerling: 236-278 (87.4 - 102.9%) -- 25% chance to OHKO after hail damage
Possible damage amounts: (236, 236, 240, 242, 246, 248, 252, 254, 258, 260, 264, 266, 270, 272, 276, 278)


Important clarification: it says "after hail damage," but that's not actually changing the numbers - I got the same calculation after removing the hail:

Lvl 55 252 SpA Choice Specs Abomasnow Blizzard vs. 36 HP / 0 SpD Deerling: 236-278 (87.4 - 102.9%) -- 25% chance to OHKO
Possible damage amounts: (236, 236, 240, 242, 246, 248, 252, 254, 258, 260, 264, 266, 270, 272, 276, 278)


The Deerling in this calc had exactly 270 HP, so the numbers that already OHKO it are the last four: 270, 272, 276 and 278. I'm sorry I picked such weird example Pokémon! The Abomasnow is just the default one leveled down to 55, and the Deerling is the LC Life Orb one leveled up to 100. I just picked a non-hail-immune Pokémon at random and then adjusted until I could recreate the situation. OTL
But yeah, that's 4/16 of the possible rolls so far - which is already the 25% just from the damage of the move, without accounting for the hail damage that happens later, and I think Apathetic Inaction is pointing out that that's all the calculation attempts to do.
In this case, I might be messing up rounding or something, but I THINK everything from the 254 and higher should be doing it, which would be a 56.25% chance to OHKO...? I might be wrong!

Short version: I think if the move has a chance (but not a guarantee) to OHKO, the calculator claims to account for the hail damage but might not actually be doing so.
I hope this was helpful! I hadn't known about this until Apathetic Inaction reported it, but this was how I interpreted their bug report, so I was just trying to clarify what they meant!
 
I think they might mean it has a chance (but not a guarantee) to OHKO without sandstorm, and then sandstorm damage should increase that chance, but it's not taking that chip damage into account?
Here's one example:

Lvl 55 252 SpA Choice Specs Abomasnow Blizzard vs. 36 HP / 0 SpD Deerling: 236-278 (87.4 - 102.9%) -- 25% chance to OHKO after hail damage
Possible damage amounts: (236, 236, 240, 242, 246, 248, 252, 254, 258, 260, 264, 266, 270, 272, 276, 278)


Important clarification: it says "after hail damage," but that's not actually changing the numbers - I got the same calculation after removing the hail:

Lvl 55 252 SpA Choice Specs Abomasnow Blizzard vs. 36 HP / 0 SpD Deerling: 236-278 (87.4 - 102.9%) -- 25% chance to OHKO
Possible damage amounts: (236, 236, 240, 242, 246, 248, 252, 254, 258, 260, 264, 266, 270, 272, 276, 278)


The Deerling in this calc had exactly 270 HP, so the numbers that already OHKO it are the last four: 270, 272, 276 and 278. I'm sorry I picked such weird example Pokémon! The Abomasnow is just the default one leveled down to 55, and the Deerling is the LC Life Orb one leveled up to 100. I just picked a non-hail-immune Pokémon at random and then adjusted until I could recreate the situation. OTL
But yeah, that's 4/16 of the possible rolls so far - which is already the 25% just from the damage of the move, without accounting for the hail damage that happens later, and I think Apathetic Inaction is pointing out that that's all the calculation attempts to do.
In this case, I might be messing up rounding or something, but I THINK everything from the 254 and higher should be doing it, which would be a 56.25% chance to OHKO...? I might be wrong!

Short version: I think if the move has a chance (but not a guarantee) to OHKO, the calculator claims to account for the hail damage but might not actually be doing so.
I hope this was helpful! I hadn't known about this until Apathetic Inaction reported it, but this was how I interpreted their bug report, so I was just trying to clarify what they meant!
Yeah, that pretty much exactly what I meant, thanks for taking the time to explain it better than I did.
 

pre

pkmn.cc
Short version: I think if the move has a chance (but not a guarantee) to OHKO, the calculator claims to account for the hail damage but might not actually be doing so.
JavaScript:
    const chance = computeKOChance(
      damage, defender.curHP() - hazards.damage, 0, 1, 1, defender.maxHP(), toxicCounter);
    if (chance === 1) {
      return {chance, n: 1, text: `guaranteed OHKO${afterText}`};
    } else if (chance > 0) {
      return {
        chance,
        n: 1,
        text: qualifier + Math.round(chance * 1000) / 10 + `% chance to OHKO${afterText}`,
      };
    }

    for (let i = 2; i <= 4; i++) {
      const chance = computeKOChance(
        damage, defender.curHP() - hazards.damage, eot.damage, i, 1, defender.maxHP(), toxicCounter
      );
      ...
This is the relevant section. It seems the eot.damage (end of turn damage, like hail) is only considered when computing the KO chance for 2+ HKOs (code for more than 4 hits is elided). I imagine the original authors intention was to prevent including after text for guaranteed OHKO scenarios where it isn't needed? For the %OKHO case though it seems like there are maybe three choices?

a) don't include after text at all, just show the raw % OHKO chance from the hit.
b) recompute KO chance from the first line, but this time include the eot.damage to get the new %
c) hidden option c: show both the KO chance with and without EOT damage

I'm not sure what is desirable here. a) is simple but leaves out some info, b) is probably the way id go and c) is 'most right' but also becomes verbose and cluttered and isnt what we do anywhere else so seems inconsistent.

Incidentally, this may be the same bug reported by Akumeoy?
I don't know if this is a bug or a design choice, but the chance-to-KO feature goes a bit screwy when the maximum damage is exactly enough to KO.
+2 252 SpA Life Orb Thundurus Thunderbolt vs. 212 HP / 0 SpD Tyranitar in Sand: 250-294 (63.4 - 74.6%) -- guaranteed 2HKO after Stealth Rock and 1 layer of Spikes
+2 252 SpA Life Orb Thundurus Thunderbolt vs. 208 HP / 0 SpD Tyranitar in Sand: 250-294 (63.6 - 74.8%) -- guaranteed 2HKO after Stealth Rock and 1 layer of Spikes
+2 252 SpA Life Orb Thundurus Thunderbolt vs. 204 HP / 0 SpD Tyranitar in Sand: 250-294 (63.7 - 75%) -- 6.3% chance to OHKO after Stealth Rock and 1 layer of Spikes
+2 252 SpA Life Orb Thundurus Thunderbolt vs. 200 HP / 0 SpD Tyranitar in Sand: 250-294 (63.9 - 75.1%) -- guaranteed 2HKO after Stealth Rock and 1 layer of Spikes
+2 252 SpA Life Orb Thundurus Thunderbolt vs. 196 HP / 0 SpD Tyranitar in Sand: 250-294 (64.1 - 75.3%) -- 6.3% chance to OHKO after Stealth Rock and 1 layer of Spikes
+2 252 SpA Life Orb Thundurus Thunderbolt vs. 192 HP / 0 SpD Tyranitar in Sand: 250-294 (64.2 - 75.5%) -- 6.3% chance to OHKO after Stealth Rock and 1 layer of Spikes
 
Not sure if this is the right place to post. I am trying to build an application with the calc npm package. The core feature of my application kinda revolves around being able to overwrite the type of the move being used and the type of the defending Pokemon to any type combination. I noticed that this works in the deployed calc but I'm having difficulty figuring out how it's done. The constructor for the Pokemon class does not have types as a writable value (in pokemon.ts) so where is the overwrite happening?
 

pre

pkmn.cc
Not sure if this is the right place to post. I am trying to build an application with the calc npm package. The core feature of my application kinda revolves around being able to overwrite the type of the move being used and the type of the defending Pokemon to any type combination. I noticed that this works in the deployed calc but I'm having difficulty figuring out how it's done. The constructor for the Pokemon class does not have types as a writable value (in pokemon.ts) so where is the overwrite happening?
You're perfectly welcome to ask questions here about the package, but #other-dev in https://spo.ink/dev might get you your answer quicker!

The overrides parameter that the Pokemon and Moves constructor takes allows you to override the core SpeciesData and MoveData respectively. cf.

https://github.com/smogon/damage-calc/blob/master/calc/src/test/calc.test.ts#L737
https://github.com/smogon/damage-calc/blob/master/src/js/shared_controls.js#L693
 

pre

pkmn.cc
If an attack has a chance to OHKO something with passive healing, can the passive healing not show up in the calc result? Like here:

252+ Atk Guts Conkeldurr Facade (140 BP) vs. 252 HP / 4 Def Clefable: 341-402 (86.5 - 102%) -- 12.5% chance to OHKO after Leftovers recovery

That "after Leftovers recovery" doesn't need to be there; leftovers won't do anyone any favors in avoiding an OHKO. It's just extra text that muddies the calcs of anyone who doesn't take care to copy-paste only the relevant information.
Sandstorm (and hail) isn't being considered when calculating whether an attack has a chance to OHKO (it works fine when considering whether an attack has a chance to 2HKO).
I think they might mean it has a chance (but not a guarantee) to OHKO without sandstorm, and then sandstorm damage should increase that chance, but it's not taking that chip damage into account?
Here's one example:

Lvl 55 252 SpA Choice Specs Abomasnow Blizzard vs. 36 HP / 0 SpD Deerling: 236-278 (87.4 - 102.9%) -- 25% chance to OHKO after hail damage
Possible damage amounts: (236, 236, 240, 242, 246, 248, 252, 254, 258, 260, 264, 266, 270, 272, 276, 278)


Important clarification: it says "after hail damage," but that's not actually changing the numbers - I got the same calculation after removing the hail:

Lvl 55 252 SpA Choice Specs Abomasnow Blizzard vs. 36 HP / 0 SpD Deerling: 236-278 (87.4 - 102.9%) -- 25% chance to OHKO
Possible damage amounts: (236, 236, 240, 242, 246, 248, 252, 254, 258, 260, 264, 266, 270, 272, 276, 278)


The Deerling in this calc had exactly 270 HP, so the numbers that already OHKO it are the last four: 270, 272, 276 and 278. I'm sorry I picked such weird example Pokémon! The Abomasnow is just the default one leveled down to 55, and the Deerling is the LC Life Orb one leveled up to 100. I just picked a non-hail-immune Pokémon at random and then adjusted until I could recreate the situation. OTL
But yeah, that's 4/16 of the possible rolls so far - which is already the 25% just from the damage of the move, without accounting for the hail damage that happens later, and I think Apathetic Inaction is pointing out that that's all the calculation attempts to do.
In this case, I might be messing up rounding or something, but I THINK everything from the 254 and higher should be doing it, which would be a 56.25% chance to OHKO...? I might be wrong!

Short version: I think if the move has a chance (but not a guarantee) to OHKO, the calculator claims to account for the hail damage but might not actually be doing so.
I hope this was helpful! I hadn't known about this until Apathetic Inaction reported it, but this was how I interpreted their bug report, so I was just trying to clarify what they meant!
These should all now be fixed. I actually decided to go with a hybrid approach here - if the attacker is faster than the defender we don't show end of turn damage (because presumably its more interesting to see if you can KO the defender without giving them a chance to strike back), but if the attacker is slower it will show the full EOT text. Also, it won't show EOT text like Leftovers recovery when it doesn't need to. Its possible we may want to rework things to show both raw OHKO percentage and OHKO percentage considering hazards and EOT, but for now I think this is a rather convenient way to get around that. Thank you all for the reports
 

pre

pkmn.cc
Reposting because I'm pretty sure it got glanced over, Power Spot is an ability which multiplies damage. Still hasn't been added.
This is a known issue, there is a bug filed on GitHub, anyone can do it, its a trivial change. There are many other effects like Mud/Water Sport, Ion Deluge, Charge, etc we do not currently support either. This is not even remotely worth my time to implement in Honko's UI, so please fine someone to open a pull request if you feel this is important.

gen 8 lacks garbodor, hatterene and alcremie
I mean, it doesn't, so it would be helpful if next time you specify (I assume) that you mean in Randoms Mode.
 

pre

pkmn.cc
OK sorry for the delay SoulWind, Earthworm, ABR. Wading into this Hidden Power mess, there are a couple of things to balance:
  • The set that was imported by the user
  • What the user manually overrides for the IVs in the UI
  • Attempting to maintain legality
One thing right off the bat is that the UI's moveset import does not currently properly implement the correct PS import mechanics which will autofill in DVs/IVs for Hidden Power if theyre not explicitly specified. This is fairly straightforward to implement in the calc, and will make it so that the preloaded sets and sets you import via the Import / Export box will actually have the correct IVs/DVs for Hidden Power (including just assuming 31 across the board for Gen 7+). This is straightforward and unambiguously The Right Thing To Do.

The more nuanced bit is the interaction between the set selector vs. the move selector vs. the IV fields. The way I plan to implement it is 'last write wins', where if you import a set or futz around with the IV fields and come up with with specific IVs and then all of a sudden give it Hidden Power with the IV fields will all be reset to the 'default PS IVs' for that Hidden Power (in Gen 2-6 at least, in Gen 7+ I don't need to ever trample the IVs one changing Hidden Power). I think we should also probably update the Hidden Power type and BP based on what is going on in the IV fields to reflect the cartridge mechanics.

I'm going to correct the moveset import logic first, please let me know if the second bit wouldn't solve your problem (and if not, please help me understand the interaction between these fields that would be most desirable)
 

pre

pkmn.cc
One thing right off the bat is that the UI's moveset import does not currently properly implement the correct PS import mechanics which will autofill in DVs/IVs for Hidden Power if theyre not explicitly specified. This is fairly straightforward to implement in the calc, and will make it so that the preloaded sets and sets you import via the Import / Export box will actually have the correct IVs/DVs for Hidden Power (including just assuming 31 across the board for Gen 7+). This is straightforward and unambiguously The Right Thing To Do.
This should be done.

The more nuanced bit is the interaction between the set selector vs. the move selector vs. the IV fields. The way I plan to implement it is 'last write wins', where if you import a set or futz around with the IV fields and come up with with specific IVs and then all of a sudden give it Hidden Power with the IV fields will all be reset to the 'default PS IVs' for that Hidden Power (in Gen 2-6 at least, in Gen 7+ I don't need to ever trample the IVs one changing Hidden Power).
The move selector and set selector should work pretty much as described.

I think we should also probably update the Hidden Power type and BP based on what is going on in the IV fields to reflect the cartridge mechanics.
I've punted on this - felt it more important to ship the first two things. The calc will not update the Hidden Power moves type and base power as you adjust IVs, nor will it try to figure out some set of IVs to match your entered Hidden Power type and power. Realistically the first one (IVs -> Hidden Power) isn't *too* hard in general (its just hard given the way the current UI is written), the other direction is kind of oof (unless we precompute the 'most desirable' IVs for each hidden power type and power from 30->70 instead of just 70 like we do today).

This involved a lot of code so I would be surprised if there was not a couple of bugs introduced - this code is deployed now, please let me know if you encounter any issues. Sorry for the long delay on addressing this after Earthworm's initial post, we probably should have acknowledged it was seen earlier (Austin and I typically react to the post to let you know if we've seen it, but perhaps some more explanation into why it is difficult and would take a while would have been appreciated)

One further potential gotcha: I've coded it so that if you change a move selection which was previously Hidden Power to a move which is not Hidden Power in Gen 2-6, all of the IVs/DVs are set to max. This isn't safe to do naively, and would require some sort of complicated field provenance tracking to do safely (was a IV field set by the user or automatically due to adding Hidden Power?) and even then would be kind of obtuse. However, this change still seems like it would be desirable more often than not when futzing with Hidden Power on sets that it seemed worth doing, but this isn't perfect (eg. very easy to 'fool' if you have two hidden power moves selected in the dropdowns, but like... don't do that).
 

pre

pkmn.cc
gen 8 lacks garbodor, hatterene and alcremie
yessir gen 8 /rcalc lacks those 3 monsters (hatterene alcremie and garbodor
This is fixed.

It also lacks Lapras. All of those mons always use their Gmax form in rands, which seems to be the reason they aren't in the rands calc.
Thank you for identifying that the fact that they were Gmax was the problem, this was very helpful and saved a lot of time.
 

Amir

Banned deucer.
I was making a team around Chandelure when I was doing some experimenting with calcs I noticed this weird bug with Aegislash-Blade output damage.
252+ Atk Choice Band Aegislash-Blade Shadow Sneak vs. 80 HP / 0 Def Chandelure: 252-296 (89.6 - 105.3%) -- 0% chance to OHKO after Leftovers recovery
It says 0% chance to OHKO when the percentage for the max roll is 105%.
To add on, using the manual calculation the answer should be around 6/16 chance to OHKO from using the possible damage amounts.
Possible damage amounts: (252, 254, 258, 260, 264, 266, 270, 272, 276, 278, 282, 284, 288, 290, 294, 296)
The numbers I have in bold are the damage rolls for the OHKO.

https://imgur.com/a/ohUzd2u Here is a screenshot as proof I haven't fiddled with anything.
Thank you.
 

Austin

Schismatic
is a Programmeris a Forum Moderatoris a Community Contributoris a Battle Simulator Moderator Alumnus
Moderator
Bug Report:
252+ Atk Choice Band Strong Jaw Dracovish Fishious Rend (170 BP) vs. 252 HP / 252+ Def Weezing-Galar: 339-399 (101.4 - 119.4%) -- guaranteed OHKO

It does not factor in that Neutralizing Gas cancels out Strong Jaws.
Thus, BandoVish only does 70% ish damage agains Galar Weezing.

This is also propably true for other neutralizing abilites aswell. I'd appreciate a bugfix for that. Thanks for your work. ;)
fixed

Max Moves still deal some damage through Protect, but this isn't reflected by the calculator
Yveltal Max Darkness vs. protected Ho-Oh: 0-0 (0 - 0%) -- possibly the worst move ever
This was fixed a while ago
 
Last edited:

Austin

Schismatic
is a Programmeris a Forum Moderatoris a Community Contributoris a Battle Simulator Moderator Alumnus
Moderator
Would it be possible to have Random Battle sets in here, or otherwise make it easy to calc things that have 84/84/84/84/84/84 investment with a neutral nature? It gets a bit tedious to have to redo that every time I want to make a calc in randbats.
lol didn't get back to you, but yes this was done a while ago :)
 
  • Haha
Reactions: pre

Users Who Are Viewing This Thread (Users: 1, Guests: 0)

Top