Jump to content

Meta-map script activation: Difference between revisions

→‎Triggering mechanism with the Trainer escape glitch: Described effects in more general terms, linking to the Blue any% route for concrete examples.
>Bbbbbbbbba
(Needless to say, I found this video too late.)
>Bbbbbbbbba
(→‎Triggering mechanism with the Trainer escape glitch: Described effects in more general terms, linking to the Blue any% route for concrete examples.)
Line 96:
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. ForSee example,below infor thesome Viridiancommon Forest, meta-map script ID 4 points to ViridianForestText2, which is a pieceexamples of text script:effects.
 
==Common effects==
ViridianForestText2:
Concrete examples of the effects below can be found in the [[Pokémon Blue any% No Save Corruption speedrun route|Blue any% run]].
TX_ASM ; 08
 
ld hl, ViridianForestTrainerHeader0 ; 21 42 51
===Repeated trainer fights===
call TalkToTrainer ; CD CC 31
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.
jp TextScriptEnd ; C3 D7 24
 
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 [$4221yy21], sp ; 08 21 42yy
ld<xx> d, c ; 51xx
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.
The first instruction does nothing since it tries to write to the ROM, and the second instruction also doesn't do much, since TalkToTrainer only cares about the register hl, whose value is still ViridianForestText2. This leads to more nonsense interpretation for the same piece of data, this time as a trainer header.
 
TheIn firstthe grand scheme of things, the most important instruction doesis nothingcalling sinceTalkToTrainer, itwhich triestakes tohl writeas tothe address of the ROMtrainer header. In particular, andif the second instruction alsodenoted as <xx> doesn't dochange muchhl, sincethen TalkToTrainerhl onlywill cares aboutbe the registeraddress hl,of whosethe valueglitch ismeta-map stillscript ViridianForestText2itself. 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 $5142xxyy ; 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 $5142xxyy" (i.e. bit 0 of $5143xxyy+1) to see whether this "trainer" has been defeated. SinceHowever, this is ''not'' bit 8 of the trainer header in question. The reason is that address $5143xxyy+1 is on the switchable portion of the ROM (on the bank of the map), andbut the function to manipulate flag arrays is on bank 3, so this actually checks $5143xxyy+1 on bank 3, which is some completely unrelated data. Anyway, if the flag value turns out to be 0, sothen another fight begins, and the meta-map script ID advances yetby again to 62. (The fight is still against the same trainer, since on this code path, the trainer class and the roster number depends on the "last text box ID", and TalkToTrainer itself never changes this ID.)
 
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 glitch 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.
After this second fight, meta-map script ID 6 is executed, which points to ViridianForestText4. This is pretty much the same thing, except that $5142 (ViridianForestTrainerHeader0) changes to $515A (ViridianForestTrainerHeader2), and this "trainer" is actually already fought, so this script just displays the "text when talked to after defeated". The "text" ends up triggering an error trap, displaying as something like "0 ERROR.", with the text box closing without an input. Furthermore, since this text is displayed on a glitched code path, the game actually stays in "overworld mode", where the tilemap buffer isn't copied to the VRAM every frame, and all text boxes are invisible. However, displaying this text still takes time, and it's displayed on every overworld frame as long as the player isn't in the middle of a step, resulting in a "walking lag". (The text box can be seen by mashing the Start button to bring up the Start menu.)
 
== Map 0xFE corruption ==
Anonymous user
Cookies help us deliver our services. By using our services, you agree to our use of cookies.