It’s another highly technical game glitch explanation, although from a source we don’t often follow here: even though it has to do with explaining glitch Pokemon from the first generation of that series, it was the ending presentation of RustCon 2020 given by Siân Griffin, despite having little to do with Rust, other than showing the possible results of not having strong memory safety in your programming language.
It’s 39 minutes long, and it might prove difficult to get through for some, but it’s good and interesting information:
I will give you an overview:
When the original Pokemon games generate a random encounter with wild Pokemon in the overworld, they refer to one of two lists in RAM memory, copied there from ROM. One list is for “grass” Pokemon, that are generated when walking through tall grass, and one is for “water” Pokemon, that are generated when in riding a Pokemon using Surf over water tiles. The lists are copied when entering a new region, with a differing enemy generation table.
Due to an oversight in the tile checking code, a different subtile is checked when generating a Pokemon from each list. This means it’s possible, on some shores, to generate a Pokemon from the grass list when actually on the water. If one of the lists has a Pokemon generation rate of 0% for its type, then its list doesn’t actually get copied. Some regions that are largely aquatic aren’t intended to ever generate grass Pokemon, and so have a 0% grass encounter rate, and so never copy a grass Pokemon encounter table. The Pokemon generated come from whatever was in memory before, which may be all zeros, or may be whatever used the memory in that area previously. Pokemon has little RAM to work with, so the Pokemon generation table memory has other things that use that memory, and one of those is data for the trainers you trade Pokemon with.
If you use Fly to fast travel to Cinnabar Island, you can reach a region where the grass encounter table won’t have been initialized, but you can still cause grass encounters to happen by Surfing on the shoreline. The contents of that table can be manipulated by doing something else that uses that memory beforehand. As a result, you can cause an encounter with an undefined Pokemon, which has the name MISSINGNO and has various glitch attributes.
Because the Pokemon has faulty definitions for some of its attributes, like appearance and cry, it’s possible to crash the game or wreck your save data from playing around with MISSINGNO. But if you run from it, this damage can be minimized. And when it tries to mark that you’ve seen MISSINGNO in the bit array that records which Pokemon you’ve seen, it overshoot that table and actually sets a bit in the memory that follows it, which usefully, is your inventory. Generate the right version of MISSINGNO and run from battle, and you may suddenly find yourself with over a hundred of an item in a specific slot in your inventory. If you put the Rare Candy there before, you now can give your Pokemon over a hundred experience levels, or you could create stat-gain items this way, or lots of Master Balls.
Glitches such as these seems like they’re rare, but really, there’s lots of games that have them. It’s one of the perils of coding your game in assembly, really.
