Meta-map script activation
|Bulbapedia also has an article about Meta-map script activation.|
Meta-map script activation refers to a set of glitches in Pokémon Red, Blue, and Yellow. These glitches will modify the "meta-map script" (also known as GameProgressFlags in the Pokémon disassembly projects) associated with a certain map, which is a special map script used to execute code on particular maps (one byte for each map). An example of a meta-map script is one that sets the event in Pallet Town where Professor Oak stops the player from walking into the grass. It is disabled later thanks to the game changing the ID of the meta-map script later.
Unlike the temporary map scripts stored at D36E-D36F, meta-map scripts are usually permanent unless the script itself changes the meta-map script ID to a different value. They are also specific to each map, unlike the D36E-D36F address that is a pointer to anywhere in the current bank in the ROM, or RAM. Therefore, if an invalid meta-map script causes a map (e.g. a route, a level of a cave) to become glitchy, it will persist even if the player leaves the map, and saves and resets the game.
Several variations of the Trainer escape glitch can modify the meta-map script in unintended ways on the location that the player escaped from the Trainer.
One of the most characteristic effects of meta-map script activation is the walking lag effect, also known as 0 ERROR, or Zero Error (due to an error code that appears in a text box when the player brings up the start menu). Apart from making the player wait a long time between steps (hence the name "walking lag") and the error code, glitchy sound effects and game freezes may also happen, depending on the player's coordinates and time spent on the map.
Certain invalid meta-map scripts also allow for arbitrary code execution.
The glitch can be pulled off by three variations of the Trainer escape glitch.
The first one involves setting up a "death-warp", returning to the original location to rematch the Trainer and defeating them without flashing the start menu.
The second one involves talking to an NPC on the original route while encounters are disabled and defeating them.
The third one involves forcing an encounter with an unbeaten Trainer on the original route through "text box matching". Text box matching basically forces the game to load the equivalent text box for the last text box in memory, and have that text box trigger a Trainer encounter.
The glitch map map 0xFE in English Yellow will set up glitch scripts on various maps, many of which will freeze the game.
A glitch script may also be activated by manipulating items in the expanded stored items pack. This is possible with the dry underflow glitch with storage box items.
Example procedure (death-warp method)
- Encounter a Pokémon in the grass in the sight of the last Trainer in Viridian Forest (closest to Pewter City).
- Black out in the wild encounter (e.g. by poison). The "!" will appear but you will return to the last Pokémon Center without battling the Trainer.
- Return to Viridian Forest without opening the start menu (it is also best to avoid any text box to make sure the upcoming battle begins).
- The battle with the Bug Catcher will start. Defeat them and the glitch script activation will occur.
Example procedure (fighting a Trainer on an encounter-disabled route method)
Reason given: Can battles be lost to trigger the glitch still?
- Perform any method of Trainer escape glitch that deactivates your START menu.
- Go to any Pokémon PC, change boxes to save the game.
- Reset. Your START menu will be active.
- Go to the map where the Trainer escape glitch was activated, but you shouldn't get any encounter.
- Fight any Trainer on the map. Since they can't notice you, you have to talk to them.
- Once the battle is finished, another battle may immediately start, with a glitched text box being displayed for a couple frames before being overwritten by the battle animation.
- Win all battles that may happen (up to 3 in a row have been reported to occur)
- Once the battles are over, the map will have the walking lag glitch activated.
Example procedure (text box matching method)
1. Go to Vermillion City.
2. Walk up to the route north of Vermilion.
3. From here, perform a Trainer-Fly glitch by flying away from the trainer in the upper left hand corner of the route.
4. Choose to fly back to Vermilion City.
5. Walk to the route that is east of Vermilion.
6. Fight any trainer here. It does not matter who the player fights, as long as the trainer walks at least one step towards the player.
7. After the trainer battle, the player should go back to Vermilion and talk to the lady wandering about outside (her text box ID is 01) - see the image below for the lady:
8. The player should then walk up to the route north of Vermilion one last time and the player will battle the Trainer with a level 20 Squirtle (if the Trainer was unbeaten). The walking lag glitch will begin afterwards.
Manually setting up a glitch script with stored PC items
Setting up the dry underflow glitch with stored PC items allows the player to manipulate certain meta-map scripts by modifying the item past item 50.
For example, item 100's quantity controls the map script for Route 8 (address D601 in Red/Blue, D600 in Yellow). Though a quantity of 1 for this item will set up a CD2D/Special-stat encounter (as if activating the Trainer escape glitch), out of bounds values are glitch scripts associated with this glitch. As in the usual Trainer escape glitch, bit 0 of $CD60 and $D730 must not be set for the CD2D/Special-stat encounter to appear. If the encounter doesn't occur even after preparing the Special stat/or CD2D, the player still has to reset them by changing boxes and resetting the game, and pushing a Strength boulder/having another Trainer walk up to the player etc.
This method is ideal for altering a meta-map script at ease, especially if it corresponds to an item quantity. The player may also be able to manipulate all 256 meta-map scripts for the map (but if the script corresponds with an item, manipulating a Cancel (0xFF) for script 255 might be harder). Furthermore, as there are only 256 item/quantity pairs in the expanded PC and the addresses after item 128 quantity are a mirror of items 1-128 again, it is usually only possible to corrupt up to D63A (W_MANSION1CURSCRIPT) in Red/Blue or D639 (both W_CINNABARISLANDCURSCRIPT and W_MANSION1CURSCRIPT) in Yellow this way.
The first meta-script address in both Red/Blue and Yellow is W_OAKSLABCURSCRIPT (Red/Blue, D5F0/ Yellow, D5EF) and is PC item 91's quantity. The last accessible ones W_MANSION1CURSCRIPT (Red/Blue, D63A) and W_CINNABARISLANDCURSCRIPT/W_MANSION1CURSCRIPT (Yellow, D639) are PC item 128's quantity.
Triggering mechanism with the Trainer escape glitch
With the Trainer escape glitch, a text box always pop up before the special encounter happens. That is usually the Start menu, either because the player has been in a non-glitched area with trainers, or because the player has flashed the Start menu beforehand. However, by viewing a text box in an area without trainers ("text box ID matching"), or by not viewing a text box at all (usually with the death-warp method), the text box that pops up can be something else. In particular, it may belong to a trainer.
A trainer's text box is special: It executes a script that behaves differently according to whether the trainer has been defeated, and whether the trainer saw the player. In particular, if the trainer hasn't been defeated, and bit 0 of $CD60 isn't set, then the text box itself is responsible for starting the fight and adjusting the meta-map script ID. Normally, the meta-map script ID would be 0 (CheckFightingMapTrainers), and the text box advances it by 2, so that it becomes 2 (EndTrainerBattle, which should be executed after the fight).
Of course, when the Trainer escape glitch is active, everything becomes a mess. First, the meta-map script ID is already 1 (DisplayEnemyTrainerTextAndStartBattle), so the text box sets it to 3 (usually already out of bounds). Furthermore, if this text box itself is displayed by the meta-map script, DisplayEnemyTrainerTextAndStartBattle, then the script will increase the meta-map script ID again to 4. All of this happens before the fight (which will always be against the trainer, since the text box sets the enemy data, overwriting any special stats/attack stages last encountered) actually begins.
What happens after the fight will depend on what the meta-map script ID 4 (or 3 if the trainer is talked to directly) points to. See below for some common examples of effects.
Concrete examples of the effects below can be found in the Blue any% run.
Repeated trainer fights
On most maps with meta-map scripts, what comes after the table of script pointers is a table of text pointers. In particular, the first few glitch meta-map scripts are likely to be trainer's texts.
As mentioned before, trainer's texts are all text scripts that may initiate the battle, and they follow the same pattern:
TX_ASM ; 08 ld hl, SomeTrainerHeaderAtXXYY ; 21 yy xx call TalkToTrainer ; CD CC 31 jp TextScriptEnd ; C3 D7 24
Here TX_ASM is a byte of 0x08 that signifies script in text. When this pointer is executed as a meta-map script, the game tries to interpret the 0x08 itself as code instead, which leads to:
ld [$yy21], sp ; 08 21 yy <xx> ; xx call TalkToTrainer ; CD CC 31 jp TextScriptEnd ; C3 D7 24
Since trainer headers are on switchable ROM Banks, the high byte of the address of one of them (xx) is always between 0x40 and 0x7F, and those values happen to all correspond to relatively "safe" (i.e. not jumps) one-byte assembly instructions.
In the grand scheme of things, the most important instruction is calling TalkToTrainer, which takes hl as the address of the trainer header. In particular, if the instruction denoted as <xx> doesn't change hl, then hl will be the address of the glitch meta-map script itself. This leads to more nonsense interpretation for the same piece of data, this time as a trainer header.
db $08 ; bit of "trainer beaten" event flag db $21 ; trainer's view range dw $xxyy ; address of "trainer beaten" event flag dw $CCCD ; pointer to text before battle dw $C331 ; pointer to text when talked to after defeated dw $24D7 ; pointer to text when defeated
Hence the game checks "bit 8 of $xxyy" (i.e. bit 0 of $xxyy+1) to see whether this "trainer" has been defeated. However, this is not bit 8 of the trainer header in question. The reason is that address $xxyy+1 is on the switchable portion of the ROM (on the bank of the map), but the function to manipulate flag arrays is on bank 3, so this actually checks $xxyy+1 on bank 3, which is some completely unrelated data. Anyway, if the flag value turns out to be 0, then another fight begins, and the meta-map script ID advances by 2.
Unlike the special stat encounter, on this code path, the trainer class and the roster number depends on the "last text box ID". In particular, if the meta-map script is arrived by fighting a trainer, then the fight it triggers is still against the same trainer, since TalkToTrainer itself never changes this ID.
"Walking lag" effect
In the above case, the "trainer defeated" flag is some unrelated data, so another possibility is that it is 1 ("already defeated"). In this case, the script just displays the "text when talked to after defeated". However, since this is a piece of glitch text on a glitched code path, instead of a text box, glitches happen.
- When actually talking to a trainer, the text script is executed through DisplayTextID, which sets up a lot of things to transition from "overworld mode" to "text box mode". The glitch meta-map script directly executes TalkToTrainer without setting up all that, which means any text is printed on an invisible screen buffer, and cannot be seen normally.
- The text can be seen by bringing up the Start menu, but due to the "lag" effect explained below, it may be necessary to mash the Start button.
- However, the game will still try to hide any sprites behind the text box, which leads to sprites near the bottom of the screen disappearing without apparent reasons.
- The "text" is taken from $C331, which is actually the the second byte of the fourth sprite in the OAM buffer.
- If there has never been at least four sprites on the screen since the last fight (exiting a fight clears OAM), then the address will begin with two bytes of 0x00. The first 0x00 is interpreted as a text command to display what follows as a text string, and the second 0x00 is interpreted as a control character, which triggers an error trap, printing "%d ERROR." and ending the text display. Here "%d" is a temporary variable in HRAM that is supposed to be the ID of the current text displayed by DisplayTextID, but since we didn't come from that code path, it is usually the ID of the last text displayed.
- If there has been more than four sprites on the screen, then the address may contain several glitch text commands. Since glitch text commands are usually interpreted as sounds, glitchy sounds will play.
- Since DisplayTextID usually takes care of the last button press to close a text box, this glitch text box will close without an input.
- The above process happens on every overworld frame as long as the player isn't in the middle of a step. Since displaying text takes time (depending on the player's text speed option), the player will only be able to move or interact in-between those invisible glitch text boxes, resulting in an apparent "walking lag".
- Finally, in this case, the above-mentioned instruction "ld [$yy21], sp" may also show an effect. The effect depends on the value of yy, which in turn depends on the map and the script ID. For example, if $yy21 is in the OAM buffer, then the top left quarter of some sprite on the screen may be flickering.
Under this state, trainers won't see the player (because that is handled by the normal meta-map script), but the player can still talk to trainers to initiate a fight, which will advance the meta-map script ID by 2.
Map 0xFE corruption
After the player enters Pokémon Yellow's map 0xFE without a freeze using a safe level-script pointer for DC0E, they will be warped to map 0x99 (a house in Fuchsia City).
After using the expanded items pack to escape this map (as the exit by default will link back to the house), the player will be able to access maps with invalid meta-map scripts.
The scripts written by map 0xFE corruption are always the same, as the corruption for D5EF+ is due to the game copying ROM data from 20:5193 onward into that portion of RAM (possibly in the middle of 20:4F14 SurfingPikachu1Graphics1).
|Address||Label||New script ID (HEX)||Source of corruption|
Fixing the glitch
Reason given: Add methods with details for each map
The glitch comes from the game advancing the map script ID but triggering more battles due to reading invalid flags, and not setting the ID back to 0 (the intended way), or from a glitch with the side effect of corrupting the map script.
List of meta-map script addresses
See MetascriptDex. There are also some differences between the Red/Blue and Yellow layouts.