I was about to post the same, it also creates an issue with sacred sword, whereby the defense boost is not ignored.
-
The moderator of this forum is jetou.
-
Welcome to Smogon! Take a moment to read the Introduction to Smogon for a run-down on everything Smogon, and make sure you take some time to read the global rules.
-
Get your votes in for the 2024 Smog Awards!
Programming Pokémon Showdown Damage Calculator
- Thread starter Austin
- Start date
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.
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!)
Deployed a new version of the calc with these fixes.
Fixed, the tier being (PU) is what tripped things up. Thanks.
Fixed, thanks for the report.
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.
Fixed, the tier being (PU) is what tripped things up. Thanks.
Fixed, thanks for the report.
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.
Bumping because this is quite needed for GSC games and it never seemed to get a reply.
This is obnoxious to handle with the current UI but if Earthworm, SoulWind and ABR all ask me to do something I prioritize it. I will look into Hidden Power handling across all gens tomorrow.
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!
Yeah, that pretty much exactly what I meant, thanks for taking the time to explain it better than I did.
Thanks, fixed.
Still working on the HP mess. Don't want to touch the OHKO calc mess, welp.
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?
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
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
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.
I mean, it doesn't, so it would be helpful if next time you specify (I assume) that you mean in Randoms Mode.
OK sorry for the delay SoulWind, Earthworm, ABR. Wading into this Hidden Power mess, there are a couple of things to balance:
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)
- The set that was imported by the user
- What the user manually overrides for the IVs in the UI
- Attempting to maintain legality
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)
This should be done.
The move selector and set selector should work pretty much as described.
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).
This is fixed.
Thank you for identifying that the fact that they were Gmax was the problem, this was very helpful and saved a lot of time.
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.
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.
fixed
Last edited:
lol didn't get back to you, but yes this was done a while ago :)