ZZAZZ glitch: Difference between revisions

Jump to navigation Jump to search
Content added Content deleted
>Torchickens
>Torchickens
Line 15: Line 15:
==Cause==
==Cause==


Whether a Trainer causes the ZZAZZ glitch or not is controlled by two things; firstly their Trainer class (controlled by byte D059 in Red/Blue or D058 in Yellow) and secondly their roster (controlled by byte D05D in Red/Blue or D05C in Yellow). For the effect to be noticeable the Trainer class may have to be a glitch Trainer, because glitch Trainers in Generation I typically have large base money payouts.
Whether a Trainer causes the ZZAZZ glitch or not is controlled by two things; firstly their Trainer class (controlled by byte D059 in Red/Blue or D058 in Yellow) and secondly their roster (controlled by byte D05D in Red/Blue or D05C in Yellow).


The Trainer class is important because each Trainer class has a certain base money payout, and the roster is important because the last level{{clarify}} in the roster is multiplied by the base money payout to calculate the Trainer's prize money.
In Pokémon Red/Blue/Yellow, money is stored so that a hexadecimal value represents a decimal value, which is related to why the ZZAZZ glitch writes 99 (normally dec:153) to things.


The following factors will cause greater ZZAZZ glitch corruptions:
Upon encountering a ZZAZZ glitch Trainer, its base money payout will be multiplied by the level of the last Pokémon and the result (the prize money) will be stored at D079 (D078 in Yellow), capped at "009999".

*If the Trainer is from a glitch Trainer class, because glitch Trainer classes in Generation I typically have large base money payouts.
*If the last level of the Pokémon is high or 0 (technically 256).

In Pokémon Red/Blue/Yellow, money is stored so that a hexadecimal value represents a decimal value, which is related to why the ZZAZZ glitch writes 99 (normally dec:153) to things.


Upon encountering a ZZAZZ glitch Trainer (or any Trainer), its base money payout will be multiplied by the level of the last Pokémon and the result (the prize money) will be stored at D079 (D078 in Yellow), capped at "009999".
Multiplication in the winning money calculation is implemented as a consecutive addition (like 3*4 is 3+3+3+3), but a glitch occurs when the money caps at 9999. Every time the game resets the payout back to 9999, the game moves the payout money pointer 3 bytes forward, so the game keeps writing hex:9999 to memory addresses located past the winning money bytes.


Multiplication in the winning money calculation is implemented as a consecutive addition (like 3*4 is 3+3+3+3), but a glitch occurs when the money caps at 9999. Every time the game resets the payout back to 9999, the game moves the payout money pointer 3 bytes forward, so the game keeps writing hex:9999 to memory addresses located past the winning money bytes when it still has additions left to do.
The more times that the money value in the current pointer caps at 00 99 99, the more bytes are corrupted.


The first byte in the series (XX 99 99) is never written to, meaning that some values stay the way they were. The extent of corruption depends on how many additions the game used. Bytes may not be kept at 99 if they change naturally in battle. An example is the address D083 (D082 in Yellow), which may be constantly changing before the player sends out their Pokémon so that the low HP noise is played.
The first byte in the series (XX 99 99) is never written to, meaning that some values stay the way they were. The extent of corruption depends on how many additions the game used. Bytes may not be kept at 99 if they change naturally in battle. An example is the address D083 (D082 in Yellow), which may be constantly changing before the player sends out their Pokémon so that the low HP noise is played.