Main Menu
Main Page
Forums
Recent changes
Random page
Help

Databases
GlitchDex
AttackDex
AreaDex
DexDex
ItemDex
TMHMDex
TypeDex
More

Major Glitches
Trainer escape glitch
Old man glitch
Celebi Egg glitch
SRAM glitch
Buffer overflow techniques
Pomeg glitch data corruption (Glitzer Popping)
Tweaking
Pokémon cloning
Select glitches (Japan)
Time Capsule exploit
Arbitrary code execution
More

Other Glitch Categories
Glitches by generation
Japan-only/language specific glitches
Natural glitches
Non-core series glitches
Non-Pokémon glitches
Recurring glitches
More

References
Pokémon GameShark codes
The Big HEX List
GB programming
Curiosities
Debugging features
Error traps
Non-glitch exploits
Pokémon glitch terminology
Unused content and prerelease information
More

Useful Tools
8F Helper
GBz80 to Items
Old man trick name generator
PATH (Prama's Advanced Tweaking Heaven)
Save file editors
Special stat/Pokémon converter
Trainer escape Trainer Pokémon finder

Affiliates
Legendary Star Blob 2 (Hakuda)
Pokémon Speedruns wiki
PRAMA Initiative
Become an affiliate!

Technical
Site Source Code

Search Wiki

 

Search Forums

 

Author Topic: TAS used to use Protect/Detect/Endure repeatedly in Gen III, interesting effects  (Read 3118 times)

0 Members and 1 Guest are viewing this topic.

blahpy

  • Yeah! Pomeg Berry!
  • Member+
  • *
  • Offline Offline
  • Gender: Female
    • View Profile
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.

blahpy

  • Yeah! Pomeg Berry!
  • Member+
  • *
  • Offline Offline
  • Gender: Female
    • View Profile
Youtube mirror to make it easy for those without a NND acocunt:

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

MidnightNinetales

  • Member+
  • *
  • Offline Offline
  • Gender: Female
  • It's an adorable PUT IT AWAY.
    • View Profile
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?

blahpy

  • Yeah! Pomeg Berry!
  • Member+
  • *
  • Offline Offline
  • Gender: Female
    • View Profile
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.

Pawny

  • ༼ つ ◕‿◕ ༽つ
  • Member+
  • *
  • Offline Offline
  • Gender: Female
  • I'm sharp! :3
    • View Profile
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.
« Last Edit: January 25, 2013, 05:51:56 pm by Pawny »
Hug me~!

Blaziken257

  • Member+
  • Offline Offline
  • I am Error!
    • View Profile
    • Tulunk Village
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:

FF FF  FF 7F  FF 3F  FF 1F

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:

76 00  A5 00  A6 00  66 00

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 00 00 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.
« Last Edit: February 08, 2013, 11:05:35 pm by Blaziken257 »

blahpy

  • Yeah! Pomeg Berry!
  • Member+
  • *
  • Offline Offline
  • Gender: Female
    • View Profile
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:

FF FF  FF 7F  FF 3F  FF 1F

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:

76 00  A5 00  A6 00  66 00

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 00 00 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?

Blaziken257

  • Member+
  • Offline Offline
  • I am Error!
    • View Profile
    • Tulunk Village
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
« Last Edit: February 10, 2013, 08:01:44 pm by Blaziken257 »

Photon-Phoenix

  • Gotta pop dem windows.
  • Administrator
  • *****
  • Offline Offline
  • Gender: Male
    • View Profile
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.