Meta-map script activation: Difference between revisions
Jump to navigation
Jump to search
Content added Content deleted
>Sherkel m (Sherkel moved page Glitch meta-map script activation to Meta-map script activation: I think the fewer pages that begin with "glitch" in the title, the better) |
>Sherkel mNo edit summary |
||
| Line 2: | Line 2: | ||
{{Bulbapedia2|0 ERROR}} |
{{Bulbapedia2|0 ERROR}} |
||
''' |
'''Meta-map script activation''', previously known as '''walking lag glitch''', and as '''0 ERROR''' or '''Zero Error''' due to error codes that may appear during the text box matching method, refers to [[glitch]]es in {{RBY}}. |
||
These glitches will modify the 'meta-map script' associated with a certain map, which is a special map script used to execute code on particular maps (one byte for each map). 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. |
These glitches will modify the 'meta-map script' associated with a certain map, which is a special map script used to execute code on particular maps (one byte for each map). 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. |
||
| Line 17: | Line 17: | ||
If the player loses, a text box may appear before the player is sent back to their black out location. |
If the player loses, a text box may appear before the player is sent back to their black out location. |
||
Certain |
Certain unused meta-map scripts may also allow for [[arbitrary code execution]]. |
||
==Activation== |
==Activation== |
||
| Line 131: | Line 131: | ||
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. |
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 [[Trainer escape glitch#Special stat encounter|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 |
Unlike the [[Trainer escape glitch#Special stat encounter|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=== |
==="Walking lag" effect=== |
||