30,354
edits
Accuracy: Difference between revisions
m
→1/256 miss glitch: Bit more explicit; better placement/generality; the parenthetical is correct on its own terms (which do not at all include *new* checks)
(→1/256 miss glitch: impossible for whom, the orig. programmers or hackers? because a simple "OR" statement would rectify the glitch ((rnd < acc) OR (acc == 255)), so it seems improbable this was "not possible" for programmers to fix) |
Tiddlywinks (talk | contribs) m (→1/256 miss glitch: Bit more explicit; better placement/generality; the parenthetical is correct on its own terms (which do not at all include *new* checks)) |
||
| Line 49: | Line 49: | ||
==1/256 miss glitch== | ==1/256 miss glitch== | ||
In the [[Generation I]] handheld games, even moves with 100% accuracy would miss once in a great while for seemingly no reason whatsoever. This was due to accuracy being internally stored as a single byte ranging from 0 to 255 (0 to FF in hexadecimal), and the probability of a move hitting being determined by generating | In the [[Generation I]] handheld games, even moves with 100% accuracy would miss once in a great while for seemingly no reason whatsoever. This was due to accuracy being internally stored as a single byte ranging from 0 to 255 (0 to FF in hexadecimal), and the probability of a move hitting being determined by comparing a randomly generating byte to the accuracy value, with the move hitting if it was less and missing if it was equal or greater. There was therefore a 1/256 chance of the random byte being equal to 255, which could never be less than even the highest possible accuracy value, causing moves labeled as being 100% accurate to miss 1/256 of the time and yielding an effective accuracy of about 99.6%. This bug also applied to secondary effects such as poison or paralysis,{{fact}} as well as [[critical hit]]s. (It was not possible to replace the "less than" check with a "less than or equal to" check, as this would enable any of these events with an accuracy value of 0 to succeed 1/256 of the time when the random byte was equal to 0.) {{m|Swift}} was unaffected, as its effect automatically skips all accuracy checks (including the invulnerability effects of {{m|Fly}} and {{m|Dig}}) and thus truly has 100% accuracy. | ||
The bug was partially fixed in {{g|Stadium}} by allowing the move to hit if the random byte was either less than the accuracy value or exactly equal to 255; this fix effectively causes every move in the game to hit 1/256 more often. The fix did not apply to critical hits, which were still capped at a 255/256 probability. It was further fixed in [[Generation II]], which removed this extra check and instead allowed moves calculated to have 100% accuracy (after applying all modifiers) to skip the random byte generation entirely. However, this did not apply to {{m|Protect}}, which still has a 1/256 chance to fail when used for the first time. <!-- TODO: What about Stadium 2? --> All 1/256-related bugs were finally resolved in [[Generation III]], whose hardware gained the ability to more freely generate ranges of random numbers; move accuracies are stored as a number from 0 to 100, and the game performs a "less than or equal to" check on a random integer from 1 to 100. | The bug was partially fixed in {{g|Stadium}} by allowing the move to hit if the random byte was either less than the accuracy value or exactly equal to 255; this fix effectively causes every move in the game to hit 1/256 more often. The fix did not apply to critical hits, which were still capped at a 255/256 probability. It was further fixed in [[Generation II]], which removed this extra check and instead allowed moves calculated to have 100% accuracy (after applying all modifiers) to skip the random byte generation entirely. However, this did not apply to {{m|Protect}}, which still has a 1/256 chance to fail when used for the first time. <!-- TODO: What about Stadium 2? --> All 1/256-related bugs were finally resolved in [[Generation III]], whose hardware gained the ability to more freely generate ranges of random numbers; move accuracies are stored as a number from 0 to 100, and the game performs a "less than or equal to" check on a random integer from 1 to 100. | ||