11,900
edits
Talk:Damage: Difference between revisions
→Please fix the page
Nescientist (talk | contribs) |
Nescientist (talk | contribs) |
||
| (6 intermediate revisions by 5 users not shown) | |||
| Line 121: | Line 121: | ||
::::::In fact, I actually forgot the Choice Band the first time I did this, and it still got 12-16, so I guess that proves that you were right about the Choice Band multiplier (at least in Showdown's logic). But the Electric Terrain Multiplier definitely isn't applied to BP or the attack stat. So with this new info in mind, it looks like Electric Terrain is being applied (in Showdown) BEFORE the random value, like so (with the initial damage of 2): 2 x 1.5 (terrain) x .85 (rand) x 1.5 (STAB) x 4 (SE) = 3 x .85 x 1.5 x 4 = 2 x 1.5 x 4 = 3 x 4 = 12. This would explain the jump in damage from 4 (without field) to 12 (with field), since without the field the random value would essentially negate the STAB bonus. So Showdown's order differs from yours, it seems. --[[User:MASLEGOMAN|MASLEGOMAN]] ([[User talk:MASLEGOMAN|talk]]) 22:34, 14 December 2016 (UTC) | ::::::In fact, I actually forgot the Choice Band the first time I did this, and it still got 12-16, so I guess that proves that you were right about the Choice Band multiplier (at least in Showdown's logic). But the Electric Terrain Multiplier definitely isn't applied to BP or the attack stat. So with this new info in mind, it looks like Electric Terrain is being applied (in Showdown) BEFORE the random value, like so (with the initial damage of 2): 2 x 1.5 (terrain) x .85 (rand) x 1.5 (STAB) x 4 (SE) = 3 x .85 x 1.5 x 4 = 2 x 1.5 x 4 = 3 x 4 = 12. This would explain the jump in damage from 4 (without field) to 12 (with field), since without the field the random value would essentially negate the STAB bonus. So Showdown's order differs from yours, it seems. --[[User:MASLEGOMAN|MASLEGOMAN]] ([[User talk:MASLEGOMAN|talk]]) 22:34, 14 December 2016 (UTC) | ||
:::::::I thought it didn't change because nothing had changed. It's interesting, though, because Showdown's damage calculator really does have an additional factor in between ''Weather'' and ''Critical'' (see [https://github.com/Zarel/honko-damagecalc/blob/master/js/damage.js here], line 518), whereas Showdown's battle engine powers up the base power (see [https://github.com/Zarel/Pokemon-Showdown/blob/master/data/moves.js here], line 4198). And that matches what the userpage and Bulbapedia have, and also that the [http://www.pokemon-sunmoon.com/en-us/pokemon/tapu-koko/ this official website] says Electric Terrain is "raising the '''power''' of any Electric-type moves" (and not damage dealt by them). Until proven otherwise, we just have to treat the official website more reliable than Showdown's damage calculator (especially when it's even contradicting their own battle engine). [[User:Nescientist|Nescientist]] ([[User talk:Nescientist|talk]]) 23:55, 14 December 2016 (UTC) | :::::::I thought it didn't change because nothing had changed. It's interesting, though, because Showdown's damage calculator really does have an additional factor in between ''Weather'' and ''Critical'' (see [https://github.com/Zarel/honko-damagecalc/blob/master/js/damage.js here], line 518), whereas Showdown's battle engine powers up the base power (see [https://github.com/Zarel/Pokemon-Showdown/blob/master/data/moves.js here], line 4198). And that matches what the userpage and Bulbapedia have, and also that the [http://www.pokemon-sunmoon.com/en-us/pokemon/tapu-koko/ this official website] says Electric Terrain is "raising the '''power''' of any Electric-type moves" (and not damage dealt by them). Until proven otherwise, we just have to treat the official website more reliable than Showdown's damage calculator (especially when it's even contradicting their own battle engine). [[User:Nescientist|Nescientist]] ([[User talk:Nescientist|talk]]) 23:55, 14 December 2016 (UTC) | ||
::::::::Ok, I did the experiment in the actual games. I had my friend use a level 1 Pichu (SpA 6, holding Choice Specs) use Thunder Shock (BP 40) on my level 50 Minior (SpD 120) and level 63 Wishiwashi (SpD 182). In both cases I got 2 damage per attack, with and without Electric Terrain out. When the same was tried on my level 32 Pelipper (SpD 53; admittedly not great but all I had on-hand), it consistently took 4 damage, regardless of terrain. So Showdown's calculator is wrong! The Pelipper calculation, entered into the calculator with the exact stats, items, and terrain, is quoted at 12-16 damage (the calculator doesn't actually have Thunder Shock, so I used Charge Beam, which is only 10 power higher, but it shouldn't matter, seeing as everything from Nuzzle to Volt Tackle yields the same results). When removing terrain, the calculator's prediction drops down to 4, which says to me that it doesn't know what order to calculate terrain in. I know at high levels this probably won't matter too much, but this might still be wiggling the end results a few HP higher than you'd truly see in the game, so it may be worth them looking into. --[[User:MASLEGOMAN|MASLEGOMAN]] ([[User talk:MASLEGOMAN|talk]]) 06:25, 16 December 2016 (UTC) | |||
:::::::::Thanks for testing. That's actually a neat way to find out whether something "affects damage" or "affects power" (although moderately hard to execute). I'm personally always interested in any explicit confirmation on which it is (for anything, especially on whatever wasn't there back in Gen V). | |||
:::::::::FYI, you can just manually adjust the power of any move within that calculator, so you can have a Thunderbolt with BP 40 or whatever you like. [[User:Nescientist|Nescientist]] ([[User talk:Nescientist|talk]]) 11:14, 17 December 2016 (UTC) | |||
== Regarding stacking "other" effects (attn: Nescientist) == | |||
On my talk page, while discussing this page before it was overhauled, [[User:Nescientist]] informed me of the exact formula used for applying multiple "other" effects in the damage calculation. A quote follows, for anyone else wanting to follow this conversation: | |||
*FYI, the complex stuff is that those modifiers aren't really just decimals, but 16-bit integers that are then divided by 0x1000, and they are appended as M<nowiki>''</nowiki> = ((M * M') + 0x800) >> 12 (Quote from [[User:Nescientist]] taken from [[User talk:Felthry]]) | |||
I have done some analysis, and I am now reasonably certain that this is exactly multiplying the two numbers. Using sixteen-bit integers divided by 0x1000 is exactly equivalent to using Q3.12 fixed-point numbers to represent the data. This means that a value of 1 would be indicated as 0b0001 0000 0000 0000 (split into 4-bit blocks for readability), while 2 would be 0b0010 0000 0000 0000 and 1/2 would be 0b0000 1000 0000 0000. Multiplying these two numbers in the standard manner would be M<nowiki>''</nowiki> = (M * M') >> 12. This is true because each number is, in effect, X << 12, where X is the intended value; << 12 is equivalent to multiplying by 2<sup>12</sup>, or 0x1000. Now, if each number is represented as X * 0x1000, this means that multiplying M * M' would be the same as multiplying (X * 0x1000) * (Y * 0x1000). Dividing by 0x1000, equivalent to a right shift by 12 bits (i.e. >> 12), makes this into (X * Y) * 0x1000, which is exactly (X * Y) in the Q3.12 format. | |||
Now for the interesting bit. What they have with the 0x800 here is actually to make the end result round properly, as opposed to simply truncating it as the normal method would. This is equivalent to adding 1/8192 to your final result; this number is used because the resolution of a Q3.12 number is 1/4096. If the bit in position 0x800 (i.e. the 12th bit from the right) is 0, adding 0x800 will do nothing, and this extra bit will be truncated off, thus rounding down, when the right shift occurs. If this bit is 1, adding 0x800 would have the effect of rounding up, adding 1/4096 to the truncated value, as the addition would cause a carry into position 0x1000. | |||
Thus, the formula M<nowiki>''</nowiki> = ((M * M') + 0x800) >> 12 is exactly the way to multiply two Q3.12 numbers or indeed any two Qn.12 numbers, while rounding in the conventional manner to be as accurate as possible. | |||
Sorry for the impromptu lesson in fixed-point arithmetic; I wanted to prove this result rigorously so that we can be absolutely certain that it holds up! In fact, this also holds for 2's-complement signed fixed-point numbers, but I won't bother proving that as the "other" value is never negative. --[[User:Felthry|Felthry]] ([[User talk:Felthry|talk]]) 16:24, 28 February 2017 (UTC) | |||
== Please fix the page == | |||
Whoever changed this page, please revert it. The new form is difficult to read (and by that I mean difficult to look at) and lacks information that the previous one had. If any changes or new information acquired, it requires only an addendum and not complete overhaul of the page. {{unsigned|RecoverShield}} | |||
:I'm quite sure most of our pages would actually look cleaner, had we ceased updating and correcting them. | |||
:Maybe just try to look out for benefits as well: For example, I'd argue the fact that it now "lacks" information it used to have actually ''is'' a benefit, for the most part: it was repetitive information (and/or didn't quite belong here in the first place). | |||
:If you do have a specific concern and/or recommendation, please feel free to bring it up. | |||
:(Maybe this as a side note: of course, it's easier not to change something than to change it, or to do a small scale change rather than a large scale one. It's also easier for readers to adapt to a tiny "addendum" than an "overhaul". Anyway, even though general statements like "If X, then just Y is required not Z!" are easy to be made, to be effective in a specific case like this, I think they also require a specific understanding of what X is, and what Y and Z would entail. As seen on this talk page and elsewhere, very roughly speaking, I and others more or less favored Z in this case.) [[User:Nescientist|Nescientist]] ([[User talk:Nescientist|talk]]) 16:13, 13 March 2017 (UTC) | |||