# Talk:Reversal (move)

## Contents

## Percentages

to clear up the percentage thing, i'm quite good at math so here goes:

The general percentage formula is (HP_{current}/HP_{max}) x 100 = Percentage

Now, let us assume that the pokemon with reversal has max 300hp, and uses reversal with only 1hp remaining. The formula would be:

(1/300) x 100 = 1/3 or 0.3 recurring

the game should round this to the nearest integer value, namely 0%

Q.E.D. 折り紙ガイ 16:05, 24 April 2008 (UTC)

## Generation V

Do we have to update this to list the Generation V Pokemon too? Speriend 23:28, 1 May 2011 (UTC)

- New comments to the bottom please. And yes, this should be updated with the Gen V Pokémon. Werdnae (talk) 23:49, 1 May 2011 (UTC)

Sorry, new here. Are we allowed to use other respected Pokemon sources for info?

Speriend 00:43, 3 May 2011 (UTC)

## Generation II breeding info doesn't add up

I may be missing something, but it doesn't look like a lot of the Pokémon listed under the breeding list for Generation II *should* be able to learn Reversal. Rhyhorn is listed as being able to learn it if bred with a Kangaskhan, but because Kangaskhan is always female, you can't breed one with a Rhyhorn or Rhydon and get a baby Rhyhorn, and Kangaskhan can't pass down the move. Most of the ones listed as being chain-bred in that generation (Pichu, Rattata, Mankey, Cyndaquil, Sentret and Houndour) are then impossible, because the only remaining options would be each other (and this also cancels the possibility of Miltank learning it, since her father would have to be one of those six or Rhyhorn). Rhyhorn's page mentions learning it from the male Nidoran line, which is more plausible, but their pages don't list the move at all. Is there a missing link that would have helped all of this make sense together?

Bombada 05:12, 24 September 2011 (UTC)

- Smeargle is in the Ground egg group. Also, There may be some that are actually impossible to get - these lists are often determined from in-game data, and IIRC there have been cases where it can't actually happen without hacking, but it's still programmed in. Werdnae (talk) 05:48, 24 September 2011 (UTC)

## Reversal with Explosion?

What happens if the opponent uses Explosin or Self-Destruct and you use Reversal? Does it hit the opponent (in double or triple battles)? What about if the Explosion user holds a Focus Sash or has Sturdy and uses it at full health? Jdrawer 15:56, 1 June 2012 (UTC)

- I don't really know what you mean; Reversal works just like all the other damaging moves like Tackle and Water Gun. And the Pokémon still faints if it has Focus Sash Sturdy.--
**電禅Den Zen**16:14, 1 June 2012 (UTC)

## Percentages are wrong

I was reading through pokecrystal's source code (pret) and was rather confused when trying to match the code with the info here. Eventually I realized that the information in here isn't correct with Generation II (particurly not for 200 and 20-80 power). I looked up if this changed later -- and it did not. http://www.smogon.com/bw/articles/bw_complete_damage_formula#bp-mods has technical details on how exactly damage calculation is done. This page's description of Flail/Reversal is consistent with what I am seeing in the generation II code. If percentages are still desired, they should rather be: 200 power at HP<2%, 150 power at HP<10%, 100 power at HP<20%, 80 power at HP<35%, 40 power at HP<68%, otherwise 20 power. --FIQ (talk) 15:24, 9 February 2017 (UTC)

- I found out that Flail does have the proper formula. I'll change this accordingly. --FIQ (talk) 15:29, 9 February 2017 (UTC)
- No, I believe both ways of displaying it are totally consistent (bar some approximations), only that this one is far more usable. I get the exact same values than were here before when I recalculate it (not the ones at Flail). Maybe you forgot that they operate on integers (always round down), or something? I think we should copy this way of displaying it to Flail, not the other way around. No need to introduce
**P**noone cares for. Nescientist (talk) 15:45, 9 February 2017 (UTC)- I am fully aware that the game runs on integers. The formula is the exact formula used in the game internally, which results in the percentage approximations I gave. These are generally more accurate than what used to be here, particurly in the 200BP and 20BP case. 2/48 is more than 2 whole percentages away from 5% which this page used to give as "approximation" for the 200-150BP threshould. If CurHP/MaxHP is less than 2/48 (so less than ~2%), then it uses 200BP. The previous version was completely misleading in this case, implying less than 5% which isn't even close. There were similar issues in general for other percentages, but not as badly approximated as this one -- the second worst one being the 20BP threshould which was listed as 71-100% -- it is 69ish-100% (33/48 and above). To clarify any potential misunderstanding, I decided to simply just copy the Flail table which also list P numbers that the game uses internally, and clearly stating that the percentages are approximations (in addition to improving them). --FIQ (talk) 18:20, 9 February 2017 (UTC)
- I have now recalculated the values rather than simply copying a table. I'm sorry, it appears that I was in the wrong, partially. The original table *was* wrong, but not to the extent that I was making it out to be, particurly in the 200BP case (2/48 is 4%ish, not 2%ish, no matter what I am thinking). I fixed the percentages. I'll leave Flail untouched for now, in case you feel that the original table was better (In that case, consider using these percentage values at least). --FIQ (talk) 18:36, 9 February 2017 (UTC)
- (conflicted) To clarify, I propose to remove any mention of
**P**, even though that is technically how it is done. - Assume that a Pokémon has max 100 HP. Then, if it currently has 4 HP, we get P=(48*4)/100, which is 1 (aka 1.92 rounded down), which is ≤ 1. So, if a Pokémon has 4% of its HP, the power will be 200. That's what this page used to say; now it says something different. Thresholds should be at (approximately) 4, 10, 20, 35, 68 percent.
- So, can we agree on that? Again, I see no reason to introduce
**P**just because that's how it's technically done; the thresholds should be sufficient. Nescientist (talk) 18:44, 9 February 2017 (UTC)- Seems reasonable. Note that the 100HP case you layed out is an outlier, reduce the HP by a mere 4 makes the 4HP become too much for 200BP. But percentages would at worst be off by 1 either way. I generally like exact details myself, but Bulbapedia has generally never been a place for that. --FIQ (talk) 18:57, 9 February 2017 (UTC)
- Eh, that's what we're here for, right? Make it exact. I think I'm making progress there.
- Yeah, you cannot really reflect that division rounding thing 100% exactly when you remove the
**P**, but if it's okay with you that we may be off by one percent in some cases, we can get rid of**P**, make it way more easy for average readers to understand. (For now, I'm going with "~HP%"; you'll see in a minute, and then you'll be able to adjust, if you feel the need to.) Sound good? Nescientist (talk) 19:05, 9 February 2017 (UTC)- I think I'd rather have the initial threshould at 0-3%, since 2/48 is 0.04167 which is close enough to 4 that a substational amount of max HP values has 4% as the point where you lose 200BP. Looks good otherwise. --FIQ (talk) 19:21, 9 February 2017 (UTC)
- There's no reason the %s even need to be cut off at the nearest integer... I'm not sure why y'all thought that was "best", but I hope more precise values have settled the problem. Tiddlywinks (talk) 19:29, 9 February 2017 (UTC)
- Thanks, I think that's better (although it's of course still "cut off", so not 100% accurate). It was all integers before, I think that was why.
- Anyway, do we maybe want to reverse the table? I think you usually prefer ≤ (or even better <), and that would match the text/description a little better, no? Nescientist (talk) 20:48, 9 February 2017 (UTC)

- There's no reason the %s even need to be cut off at the nearest integer... I'm not sure why y'all thought that was "best", but I hope more precise values have settled the problem. Tiddlywinks (talk) 19:29, 9 February 2017 (UTC)

- I think I'd rather have the initial threshould at 0-3%, since 2/48 is 0.04167 which is close enough to 4 that a substational amount of max HP values has 4% as the point where you lose 200BP. Looks good otherwise. --FIQ (talk) 19:21, 9 February 2017 (UTC)

- Seems reasonable. Note that the 100HP case you layed out is an outlier, reduce the HP by a mere 4 makes the 4HP become too much for 200BP. But percentages would at worst be off by 1 either way. I generally like exact details myself, but Bulbapedia has generally never been a place for that. --FIQ (talk) 18:57, 9 February 2017 (UTC)

- I am fully aware that the game runs on integers. The formula is the exact formula used in the game internally, which results in the percentage approximations I gave. These are generally more accurate than what used to be here, particurly in the 200BP and 20BP case. 2/48 is more than 2 whole percentages away from 5% which this page used to give as "approximation" for the 200-150BP threshould. If CurHP/MaxHP is less than 2/48 (so less than ~2%), then it uses 200BP. The previous version was completely misleading in this case, implying less than 5% which isn't even close. There were similar issues in general for other percentages, but not as badly approximated as this one -- the second worst one being the 20BP threshould which was listed as 71-100% -- it is 69ish-100% (33/48 and above). To clarify any potential misunderstanding, I decided to simply just copy the Flail table which also list P numbers that the game uses internally, and clearly stating that the percentages are approximations (in addition to improving them). --FIQ (talk) 18:20, 9 February 2017 (UTC)

- No, I believe both ways of displaying it are totally consistent (bar some approximations), only that this one is far more usable. I get the exact same values than were here before when I recalculate it (not the ones at Flail). Maybe you forgot that they operate on integers (always round down), or something? I think we should copy this way of displaying it to Flail, not the other way around. No need to introduce