Glitch City Laboratories Archives

Dang! So I got the code working finally, and even though IssoTM's coder is French, you only need to be able to 1. understand the code itself, and 2. know translations of the items (a lot of which are similar to the English as well).

I was setting the stats of my Mew using some ACE and set both bytes to 255 for each stat (HP, ATK, DEF, SPD, & Special) and every time the value ended up as "F35" with the F not changing when I move into a different area. Does that equate to 13335? And if so, why does pound still not one-hit KO everything? For example, an Onix, where it isn't super effective. It feels like I've either massively overestimated the value, the calculation for not-very-effective damage really cuts down a lot or the glitch numbers don't work correctly. Or something else I've completely overlooked.

0x0F35 = 3893

I already had F35 values when I used gameshark codes to put FF FF in a stat. It that is what you did then it probably equals 65 535, in fact  :P

But why doesn't it makes your Pokémon a real bad ass? I'm not sure about how this works. Maybe you have to change Exp. Stats too?

I was setting the stats of my Mew using some ACE and set both bytes to 255 for each stat (HP, ATK, DEF, SPD, & Special) and every time the value ended up as "F35" with the F not changing when I move into a different area. Does that equate to 13335?

And if so, why does pound still not one-hit KO everything? For example, an Onix, where it isn't super effective. It feels like I've either massively overestimated the value, the calculation for not-very-effective damage really cuts down a lot or the glitch numbers don't work correctly. Or something else I've completely overlooked.

I dont know all the specifics, but a stat of 65535 would almost certainly cause an overflow in the damage calculation. A more reasonable number like 5000 might work out better.

I dont know all the specifics, but a stat of 65535 would almost certainly cause an overflow in the damage calculation. A more reasonable number like 5000 might work out better.

And if so, why does pound still not one-hit KO everything? For example, an Onix, where it isn't super effective. It feels like I've either massively overestimated the value, the calculation for not-very-effective damage really cuts down a lot or the glitch numbers don't work correctly. Or something else I've completely overlooked.

About the code you mentioned: this payload takes advantage of the register hl containing the address of item 3 (the initial payloads put the address of item 3's identifier in the [tt]hl[/t] register, then transfers execution there with [tt]jp hl[/tt]).

I'll try to break it down for you, line by line:

[tt]inc c[/tt] - increases the value of the [tt]c[/tt] register by 1. Used here as junk code, so we can use the item quantity to represent the opcode we want to execute, instead of the item identifier.
[tt]dec hl[/tt] - decreases the value of the [tt]hl[/tt] register by 1. The [tt]hl[/tt] register did contain the address of item 3's identifier, after this line it contains the address of item 2's quantity.
[tt]dec c[/tt] - decreases the value of the [tt]c[/tt] register by 1, the same register that was decreased 2 lines ago. Again, this is junk code, used so we can represent the next opcode as a quantity, rather than an item. I'll take the time to explain why this is needed: if you look at the Big List, if you express the quantity 43 as an item, it represents the Secret Key. It's possible (albeit a little annoying) to have two stacks of a regular item, but not so without cheating, or manipulating memory some other way, for a key item.
[tt]dec hl[/tt] - As before, the value of the [tt]hl[/tt] register is decreased. After this line, the [tt]hl[/tt] register contains the address of item 2's identifier.
[tt]inc (hl)[/tt] - The brackets around [tt]hl[/tt] mean "the memory address contained in the register"; so, this line increases the value contained in the memory address that is the value of the [tt]hl[/tt] register by 1. As mentioned, at this point, the [tt]hl[/tt] register contains the address of item 2's identifier; so, this line increases item 2's identifier by 1.
[tt]ret[/tt] - This line returns from the function that the game called to use the 8F item, and therefore returns control back to the game.

About why your attempted payload didn't work: you ALMOST got it right. Different CPUs use different byte orders, known as "endianness". You specified the memory address in your payload as big endian, where the most significant byte comes first, that is, [tt]D7 B3[/tt] corresponds to the address [tt]0xD7B3[/tt]. However, the Game Boy's CPU, which is a modified version of the Z80, uses little endian format, where the least significant byte comes first, that is, [tt]B3 D7[/tt] corresponds to the address [tt]0xD7B3[/tt].

Stuff like "ld" and "inc" are assembler mnemorics. In this instance, "ld" is short for "load" and "inc" short for "increment". I mentioned earlier that the Game Boy uses a modified Z80. So, if you want to learn about the assembler, you can look up Z80 assembly/assembler; Google can help you there. Another thing that will help is this hexadecimal to Game Boy CPU mapping and, of course, the BIG List.

Hopefully this has helped you!

The third item's amount should correspond to B3 and the TM15's identifier should correspond to D7 according to the big list, so the whole thing should correspond to 0xD7B3 and it's still not working. Why?

The third item's amount should correspond to B3 and the TM15's identifier should correspond to D7 according to the big list, so the whole thing should correspond to 0xD7B3 and it's still not working. Why?

The event flag for beating Sabrina is bit 1 of 0xD7B3, but this won't give you her badge. Do you want to make the game think you beat Sabrina, or do you want her badge?