Glitch City Laboratories Archives

Glitch City Laboratories closed on 1 September 2020 (announcement). This is an archived copy of a thread from Glitch City Laboratories Forums.

You can join Glitch City Research Institute to ask questions or discuss current developments.

You may also download the archive of this forum in .tar.gz, .sql.gz, or .sqlite.gz formats.

Generation III Glitch Discussion

TAS used to use Protect/Detect/Endure repeatedly in Gen III, interesting effects - Page 1

TAS used to use Protect/Detect/Endure repeatedly in Gen III, interesting effects

Posted by: OwnageMuch
Date: 2013-01-20 22:19:13
http://www.nicovideo.jp/watch/sm19862416

Note the success chances each time he uses the move

The statistics displayed are, in this order:

Game speed
Consecutive move number
Chance of move success
Approximate percentage chance of move success
Cumulative percentage chance of success
Number of frames taken to use the last move (time taken to manipulate RNG)
Same as above, but in seconds

It's interesting to see that the chances become rather messed up.

Re: TAS used to use Protect/Detect/Endure repeatedly in Gen III, interesting effects

Posted by: OwnageMuch
Date: 2013-01-23 22:31:25
Youtube mirror to make it easy for those without a NND acocunt:

http://www.youtube.com/watch?v=CKfStXqIaB8

Re: TAS used to use Protect/Detect/Endure repeatedly in Gen III, interesting effects

Posted by: MysticFlygon
Date: 2013-01-25 06:52:36
As far as I can tell, the player is simply using knowledge of the Pseudo-Random Number Generator to land on exactly the right frame to make protect/endure successful. What intrigues me, however, is the player's ability, at some points, to use an item after designating their move, but before the opponent attacks. Does anyone have an explanation for this?

Re: TAS used to use Protect/Detect/Endure repeatedly in Gen III, interesting effects

Posted by: OwnageMuch
Date: 2013-01-25 16:38:06

As far as I can tell, the player is simply using knowledge of the Pseudo-Random Number Generator to land on exactly the right frame to make protect/endure successful.


Yes, but the probability of success is also shown. You'll notice that rather than decreasing each time, it fluctuates greatly when used more times consecutively that was intended.

Re: TAS used to use Protect/Detect/Endure repeatedly in Gen III, interesting effects

Posted by: Tsukuu
Date: 2013-01-25 17:51:01

What intrigues me, however, is the player's ability, at some points, to use an item after designating their move, but before the opponent attacks. Does anyone have an explanation for this?


I have no idea what you meant there, but as far as I can tell, the Makuhita has a Focus Band, Ralts has a Bright Powder, and everyone else has Quick Claw. So at the beginning he attacked right when landing at the respective frames that every held item would activate, later used Max Elixir when Makuhita's Focus Band would activate, and at the end made Ralts' Bright Powder activate again to use Destiny Bond safely and take Armaldo down.

Re: TAS used to use Protect/Detect/Endure repeatedly in Gen III, interesting effects

Posted by: Blaziken257
Date: 2013-02-08 22:55:06
This is quite odd. This glitch didn't make sense to me at first – I was wondering how bad the math could have been to calculate the odds. But, it seems that the game uses a lookup table, so the probabilities (out of 65535) are hardcoded in. In an English Ruby ROM, you can see this starting at ROM offset 0x1FACF6 – in a hex editor, you can see the following byte sequence:

[tt]FF FF  FF 7F  FF 3F  FF 1F[/tt]

These are 16-bit little endian values (in decimal, this would be 65535, 32767, 16383, and 8191, which matches up with the probabilities in the video). After that, if Protect were to still succeed, the game seems to read the bytes afterward – it appears the bytes are meant for other data (what it is for, I don't know), but the game interprets them as probabilities. Here are the next eight bytes, just to demonstrate:

[tt]76 00  A5 00  A6 00  66 00[/tt]

In decimal, these are 118, 165, 166, and 102, which matches up with the next four probabilities of Protect. If you look at a hex editor, you can see the following ones also match up, and eventually you will see the byte sequence [tt]00 00[/tt] at 0x1FAD8E, which is where the probability is zero.

It looks like Game Freak didn't anticipate that Protect would succeed more than 4 times. Oops!

(I wonder: How hard would it have been for Game Freak to program it so the value is simply halved every time (rounded down), instead of using a table? Weird.)

Also, I didn't use a disassembler for this at all (my experience for GBA assembly hacking is rather poor) – I simply used a hex search to find this.

EDIT: I took a very quick look at other Gen III games and it seems that FR/LG and E seems to have different probabilities after the two consecutive instances of 65535/65535 (i.e. turns 51 and 52). The offsets are in different places in every ROM as well. I'll post hex strings later if nobody has a problem with it, or someone else can do it if they get to it first.

Re: TAS used to use Protect/Detect/Endure repeatedly in Gen III, interesting effects

Posted by: OwnageMuch
Date: 2013-02-09 02:57:16

This is quite odd. This glitch didn't make sense to me at first – I was wondering how bad the math could have been to calculate the odds. But, it seems that the game uses a lookup table, so the probabilities (out of 65535) are hardcoded in. In an English Ruby ROM, you can see this starting at ROM offset 0x1FACF6 – in a hex editor, you can see the following byte sequence:

[tt]FF FF  FF 7F  FF 3F  FF 1F[/tt]

These are 16-bit little endian values (in decimal, this would be 65535, 32767, 16383, and 8191, which matches up with the probabilities in the video). After that, if Protect were to still succeed, the game seems to read the bytes afterward – it appears the bytes are meant for other data (what it is for, I don't know), but the game interprets them as probabilities. Here are the next eight bytes, just to demonstrate:

[tt]76 00  A5 00  A6 00  66 00[/tt]

In decimal, these are 118, 165, 166, and 102, which matches up with the next four probabilities of Protect. If you look at a hex editor, you can see the following ones also match up, and eventually you will see the byte sequence [tt]00 00[/tt] at 0x1FAD8E, which is where the probability is zero.

It looks like Game Freak didn't anticipate that Protect would succeed more than 4 times. Oops!

(I wonder: How hard would it have been for Game Freak to program it so the value is simply halved every time (rounded down), instead of using a table? Weird.)

Also, I didn't use a disassembler for this at all (my experience for GBA assembly hacking is rather poor) – I simply used a hex search to find this.

EDIT: I took a very quick look at other Gen III games and it seems that FR/LG and E seems to have different probabilities after the two consecutive instances of 65535/65535 (i.e. turns 51 and 52). The offsets are in different places in every ROM as well. I'll post hex strings later if nobody has a problem with it, or someone else can do it if they get to it first.

Thanks for finding this out. I expected it to be something along these lines.

I find it interesting that they went only as far as three successes. I wonder if this happens in other games too?

Re: TAS used to use Protect/Detect/Endure repeatedly in Gen III, interesting effects

Posted by: Blaziken257
Date: 2013-02-10 19:51:38
I have no idea what happens in the other three generations, but I'm curious to what people find. It is weird that Game Freak only programmed it with three successes in mind.

In any case, I took all five English versions of Gen III, and wrote a custom tool to find the hex string FF FF FF F7 FF 3F FF 1F (it only appeared once in each version), and extracted each probability until it found one that was 0. The ROM offsets that store these probabilities are listed. One problem, though, is that the video assumes that the denominator is 65535, while Bulbapedia (and its source) assume that it's 65536. I have no idea which is right, but for now I'll assume it's 65536 and take that into account.

Ruby and Sapphire seem to be identical here, as do FireRed and LeafGreen.

Eventually, I'll do this same thing for other languages, in the off-chance that they are different (it's possible, since MissingNo. does look different in the Spanish versions of first gen games).

Since it's very long, I'll link to it instead:
http://pastebin.com/hCALjDAx

Re: TAS used to use Protect/Detect/Endure repeatedly in Gen III, interesting effects

Posted by: GARYM9
Date: 2013-02-11 00:04:27
I just hex searched Pokemon Diamond.

The hex string does not exist, so its either using different probabilities or they finally started calculating the value.