So, there have been two Pokemon Crystal save glitch movies so far. Both of which abuse the laughable checksum system and use checksum collision to corrupt the main save data. It was thought that this technique would ultimately be just slower in Gold/Silver due to the classic save glitch ACE exploit, type 0xD0, required a third Pokemon in the party. However, I've recently discovered that this requirement is really only needed for Gold. Silver happens to have some slight differences with type 0xD0 ACE, that being a usable pointer was in the middle of box names! This eliminated the need for a third Pokemon, making save glitch far better in Silver than Crystal. Now Silver is the fastest gen 2 game!

Read the previous 2 save glitch submissions for the details, but essentially we want to corrupt Cyndaquil so it has no moves, while also making sure the checksum passes.

Type 0xD0 is the type move 0x00 has on the move summary screen. This type sources itself from VRAM, which is subject to locking, so the corruption done is variable and dependent on timing. This timing can be manipulated slightly using PrintLetterDelay, just like RNG. Anyways, this corruption can overflow the tile map, and the corruption happens to reach some data regarding animations. Particularly, the animation ID can be corrupted, and this animation ID happens to use a jump table that has some interesting values past its valid entries. For 0x91, the pointer is 0xD8CD, which is in the middle of box 2. 0x91 can be corrupted in using the player's name (R is character 0x91).

This uses yet again MrWint's box code for input to opcode. There were some minor modifications done to work around character limitations.

Here is a paste of the tracelog and the values set from the input to opcode payload: https://pastebin.com/raw/B7R0Cmf1

To note, movie does something a bit differently to get to Mt. Silver. Instead of creating a warp, I just change the map connection so it goes to Mt. Silver (and in front of Red) and I move myself next to the map connection, so taking 1 step down triggers it. This also happens to make autoinput taken from 00:0000 to work, so all I need to do is enable autoinput and it'll just work.

ThunderAxe31: Judging.

ThunderAxe31: All right, the movie looks optimized and it correctly beats the game.

There is just one special note I need to make. After some discussion with the other judges, as well as the precedent set with this submission, we decided that using glitches that are affected by uninitialized SRAM bytes is considered fair. For this reason, it shouldn't be considered as a requirement to wipe the save data by using in-game functionalities, like this movie does. Additionally, this movie does also write a proper save file once, before performing the save glitch, so there wouldn't be much of controversial even if we wanted to see it that way. However, the time lost is not considered as suboptimal play, but rather as a personal choice from the author. Additionally, the previous publications are also making use of this in-game feature, so it's understandable that the author decided to follow the trend set by movies that have been accepted in the past, in order to make sure that the new submission would comply with the rules. Though, this isn't always the case, as rules may change and judgement precedents may not always reflect them; when in doubt, always ask directly to the judges. Anyway, please remember to avoid wiping the save data for future submissions, unless that is required for performing a faster glitch.

Since the movie contents are very similar to the published Pokémon Crystal movie, this movie is going to obsolete it. It does also pretty much reflect the same audience reaction, so it's also going to inherit the Moons tier. Accepting over [4285] GBC Pokémon: Crystal Version "save glitch" by CasualPokePlayer in 03:55.59.

Spikestuff: Publishing.