Safari Zone exit glitch: Difference between revisions
Jump to navigation
Jump to search
Content added Content deleted
| Line 8: | Line 8: | ||
==Explanation== |
==Explanation== |
||
When the player performs this glitch, the memory address D365 (the exit location for certain warps) is changed to something other than Fuchsia City (007) in a number of instances. It is normally the expected exit location, though flying to a place also updates D365 to the value of that location. |
When the player performs this glitch, the memory address $D365 (the exit location for certain warps) is changed to something other than Fuchsia City (007) in a number of instances. It is normally the expected exit location, though flying to a place also updates D365 to the value of that location. |
||
#When you fly to a place. |
#When you fly to a place. |
||
| Line 23: | Line 23: | ||
For other maps for D365, exit point hex:04 may also be valid, for example, after the player performs the Safari Zone exit glitch with Cerulean City they will step outside of the Bike Shop and no Glitch City will be caused. There may not be a valid exit point hex:04 for maps such as Sea Route 20 though, so the game may load a Glitch City after trying to use the invalid exit point data. |
For other maps for D365, exit point hex:04 may also be valid, for example, after the player performs the Safari Zone exit glitch with Cerulean City they will step outside of the Bike Shop and no Glitch City will be caused. There may not be a valid exit point hex:04 for maps such as Sea Route 20 though, so the game may load a Glitch City after trying to use the invalid exit point data. |
||
These Glitch Cities are not unique 'glitch areas', but rather glitchy versions of existing maps. This can be confirmed by tracking the memory address D35E (the current map location) or viewing the Town Map; the location or location name will be the same as the location you were in before the PA called you to say your Safari Zone time was over. |
These Glitch Cities are not unique 'glitch areas', but rather glitchy versions of existing maps. This can be confirmed by tracking the memory address $D35E (the current map location) or viewing the Town Map; the location or location name will be the same as the location you were in before the PA called you to say your Safari Zone time was over. |
||
===Escaping from the Safari Zone=== |
===Escaping from the Safari Zone=== |
||
| Line 30: | Line 30: | ||
In Gen I, the game keeps track of a script ID for almost every overworld map. The script ID indicates the "status" of that specific map (e.g. [[Trainer escape glitch|whether the player is being seen by a trainer]]), and determines the overworld script that runs every frame when the player is in that map. The piece of script responsible for asking the player "leave early?" when the player tries to do so is script #5 in the Safari Zone entrance. A "yes" answer would end the Safari game properly, make the player walk out, and change the script ID back to 0 (the initial state). A "no" answer is supposed to make the player return to the Safari Zone, and leave the script ID at 5 (so that the player is asked again if they try to leave again). |
In Gen I, the game keeps track of a script ID for almost every overworld map. The script ID indicates the "status" of that specific map (e.g. [[Trainer escape glitch|whether the player is being seen by a trainer]]), and determines the overworld script that runs every frame when the player is in that map. The piece of script responsible for asking the player "leave early?" when the player tries to do so is script #5 in the Safari Zone entrance. A "yes" answer would end the Safari game properly, make the player walk out, and change the script ID back to 0 (the initial state). A "no" answer is supposed to make the player return to the Safari Zone, and leave the script ID at 5 (so that the player is asked again if they try to leave again). |
||
However, the script makes the player walk in both cases, and "player being forced to walk" is another status that needs to have its own script ID. Hence in both cases, the script ID is actually changed to 6, with the script ID that should come afterwards (either 0 or 5) stored in memory address CF0D. When the auto walk ends, script #6 reads the value in memory address CF0D and assigns it to the script ID. |
However, the script makes the player walk in both cases, and "player being forced to walk" is another status that needs to have its own script ID. Hence in both cases, the script ID is actually changed to 6, with the script ID that should come afterwards (either 0 or 5) stored in memory address $CF0D. When the auto walk ends, script #6 reads the value in memory address $CF0D and assigns it to the script ID. |
||
The oversight is that moving up will return the player to the Safari Zone first, which is a separate map, so the Safari Zone entrance script ID is stuck at 6 until the player walks back out. Normally, the script correctly read out the value 5 from CF0D and everything is fine. But the value of CF0D is not saved with the save file, and reverts to 0 upon reset. Therefore the script will erroneously change the script ID to 0, allowing the player to get the welcome message by walking down to the desk, and answer "no" to leave. |
The oversight is that moving up will return the player to the Safari Zone first, which is a separate map, so the Safari Zone entrance script ID is stuck at 6 until the player walks back out. Normally, the script correctly read out the value 5 from CF0D and everything is fine. But the value of CF0D is not saved with the save file, and reverts to 0 upon reset. Therefore the script will erroneously change the script ID to 0, allowing the player to get the welcome message by walking down to the desk, and answer "no" to leave. |
||