Trainer ID collision

From Glitch City Wiki
Jump to navigation Jump to search

A Trainer ID collision happens when the game randomly generates the same Trainer ID for two different playthroughs. This can happen "naturally" with a very low probability (for Generation I and II, the probability is 1/65536), or it can be induced by luck manipulation or by changing the Trainer ID through arbitrary code execution. A Trainer ID collision may cause the game to "erroneously believe" that those are in fact the same playthrough, e.g. a Pokémon traded between them may not be considered an outsider (although depending on the game, some properties other than the Trainer ID may be checked as well). In particular, in Generation II, a Trainer ID collision allows the player to carry over some parts of the save file into a new game.

In Generation II

When the player tries to save the game, if there is an existing save file, the game compares the Trainer ID in the save file with the player's current trainer ID to determine whether the save file is from the current playthrough (i.e. the player continued from the save file) or a previous playthrough (i.e. the player started a new game). This will affect the wording the game uses to ask the player whether to overwrite the old save file ("There is already a save file" vs. "There is another save file"). Also, only in the latter case (or if there is no valid existing save file) will the game call the function ErasePreviousSave[1], which erases some parts of the save file that would not otherwise be overwritten when saving the game; namely, that includes boxes, Hall of Fame data, link battle statistics, mystery gift, and (in Crystal) Battle Tower status[2]. Furthermore, in Crystal, ErasePreviousSave is also responsible for saving the player's gender (which is not part of the main data, probably because it was introduced in Crystal)[3].

Consequently, a Trainer ID collision with the existing save file will cause the game to skip ErasePreviousSave, allowing the player to carry over stored Pokémon, etc. into a new game. A notable application of this is the Battle Tower SRAM glitch (the Trainer ID collision allows the player to preserve the battle Tower status when making a new save, and to pass an independent check when trying to resume a Battle Tower session to ensure the save file is for the current playthrough, which is also based solely on Trainer ID[4]).

References

  1. The function AskOverwriteSaveFile, which calls ErasePreviousSave if there is no existing save file or the Trainer IDs do not match
  2. The function ErasePreviousSave in the disassembly
  3. The piece of code that saves the player's gender, which in English versions is normally only reached through ErasePreviousSave
  4. The function used by Battle Tower scripts to check whether save file is for the current playthrough