Pokémon FireRed and LeafGreen

This page details bugs of Pokémon FireRed and LeafGreen.

Roaming Pokémon Roar Glitch#

If one of the Roaming Pokémon uses Roar to remove itself from battle, it will completely disappear from the game and locking the player out of obtaining it (outside of trading, of course). While Suicune is fortunate enough to not know Roar when it's encountered as a Roaming Pokémon, Raikou and Entei do know Roar as Roaming Pokémon and are thus affected by this glitch. This glitch actually occurs if the Roaming Pokémon uses any move that removes itself from battle (including Whirlwind or Teleport), but since Roar is the only "self-removal" move that any of the Roaming Pokémon in Gen 3 can know when they're encountered, it's impossible for this to occur with any other moves in normal gameplay. This glitch was also technically present in Emerald, but because the Roaming Pokémon in that game (Latios and Latias) can only learn Roar via TM, it can never occur in normal gameplay.

The reason this glitch occurs is due to an oversight in how the game checks its battle outcome variable to despawn Roaming Pokémon: Due to an obscure glitch in Ruby & Sapphire that caused Roaming Pokémon to continue roaming after their battle ended in a draw (i.e. the player defeats the Pokémon and whites out at the same time), all the other GBA Pokémon games simply checked if the last bit of the battle outcome variable (any number from 1-10) was the same as the last bit of the value for winning the battle (1) - which essentially checked to see if the battle outcome variable was an odd number:

if ((gBattleOutcome & B_OUTCOME_WON) || gBattleOutcome == B_OUTCOME_CAUGHT)
    SetRoamerInactive();

Since the applicable values with even numbers are for events that would not despawn the Roaming Pokémon (the player losing, the player running, and the Pokémon fleeing), and most of the ones with odd numbers are for events that would despawn the Roaming Pokémon (the player winning, the battle ending in a draw, and the player catching the Pokémon), this should still work as intended... had it not been for the value for a Pokémon using a move that removes itself from battle, which is an odd number despite being for an event that shouldn't despawn Roaming Pokémon. Due to this oversight, a Roaming Pokémon using a move that removes itself from battle is internally treated as if the player had knocked it out, which results in the Roaming Pokémon being permanently despawned from the game.

Surprisingly, this bug was fixed in the Nintendo Switch re-releases of FireRed and LeafGreen, released 22 years after the original GBA games. The fix for this bug was actually rather simple, as the re-releases despawn the Roaming Pokémon by only checking if the battle outcome variable was the same as the values for events that would result in them despawning (the player winning the battle, the player catching the Pokémon, or the battle ending in a draw):

if ((gBattleOutcome == B_OUTCOME_WON) || gBattleOutcome == B_OUTCOME_CAUGHT || gBattleOutcome == B_OUTCOME_DREW)
    SetRoamerInactive();

Why the original games didn't simply do this instead is a riddle for the ages.