How to Make your own Cheat Codes

[Vega]

Yes. A simple typo on my part.

And no need to apology. I understand IRL obligations. My own job requires me to go out of town almost every week.

[Unnamed]

Just want to point out that THIS is in my opinion the best thread on mariokartwii.com

The reason is very simple: This tutorial is not only applicable to Mario Kart Wii, but also to almost every other game. The procedure of checking values and finding the instruction that changes these values after they changed is exactly the same for almost every game, but the layout (where you can find the settings) naturally changes from emulator to emulator.

[LightKingdom666]

Yes. A simple typo on my part.

And no need to apology. I understand IRL obligations. My own job requires me to go out of town almost every week.

Hello again. It's been a while since I last checked in, but I've been very busy these past few years.

Regarding the last thing we talked about two years ago, I'd like you to explain how to identify which registers are secure and which aren't. Regarding Mario Sports Mix, you say the register r11 isn't secure (in that case, how can I identify them for other games?).

I didn't understand the r27 + 0x496 thing either.

Remember how 2 years ago my problem was that my instructions matched yours, but the addresses didn't? Well, I tried simply changing the address of the code you created, and it ended up with something like this:

Code:

C35B59E8 00000008
7D8802A6 4800000D
030E0F03 0E0F0000
7D6802A6 396BFFFF
38600006 395B0470
7C6903A6 8C0B0001
9C0A0028 4200FFF8
7D8803A6 38600000
60000000 00000000

The code actually works pretty well. The problem is that it only works for me in Dolphin and not on the Wii (when I select a character the game freezes), and my intention was to create Wii codes in Dolphin to play them on the Wii. I also tried changing the Hooktype from USBLoaderGX, but it didn't work.

[_Ro]

"The problem is that it only works for me in Dolphin and not on the Wii"

If you enable panic handlers on Dolphin, do you get any crash popup?

[LightKingdom666]

"The problem is that it only works for me in Dolphin and not on the Wii"

If you enable panic handlers on Dolphin, do you get any crash popup?

Well, during character selection, the game has an option to change the character's color or costume by pressing the + button. In Dolphin, when I try to do so, I get this message:

"Invalid write to 0x000084b4, PC = 0x80002370"

And then, afterward, it gives me the option to "Continue" or "Ignore the Message." If I click "Continue," the message persists, but if I click "Ignore the Message," the game continues (in Dolphin only, because we already mentioned that on the Wii, it crashes when selecting a character).

[_Ro]

At the custom code (Check address 80002370), it's trying to load from an invalid address. Check what that instruction is, for example, lwz r12, 0x10 (r11), it means r11 address is invalid.

Please take a ascreenshot

[LightKingdom666]

At the custom code (Check address 80002370), it's trying to load from an invalid address. Check what that instruction is, for example, lwz r12, 0x10 (r11), it means r11 address is invalid.

Please take a ascreenshot

Are you referring to this part of the code indicated by the arrow?

Code:

C35B59E8 00000008
7D8802A6 4800000D
030E0F03 0E0F0000
7D6802A6 396BFFFF
38600006 395B0470 ⟵
7C6903A6 8C0B0001
9C0A0028 4200FFF8
7D8803A6 38600000
60000000 00000000

[Vega]

If you're using the NTSC-U version of the game (which I've used), your hook address (C3xxxxxx) should be the same as mine. Are you using a PAL version?

Regarding the r27 thing...

Registers r14 thru r31 are Non-Volatile Registers (aka Global variable registers). These means some of these registers may hold memory addresses that will always point to some key/critical info that COULD be useful/related to your code. The memory addresses will change/vary/update but offsets (used to find desired info) relative to them will not.

On my MSM code whenever the game executes at 0x815b5268, r27 is a memory address. That address + 0x496 always points to the character's "packet". Packet basically being a small chunk of memory that contains attributes to that character (such as Slot number). Because I have access to this "packet" and no how to find it (thanks to r27), this allows me to expand/add features to the code such as Changing every character selectively.

"Invalid write to 0x000084b4, PC = 0x80002370"

This means the instruction at 0x80002370 is executing a store (i.e. stw/sth/stb) instruction to a invalid/non-existent memory address.

The gecko code handler places cheats codes at 0x80002XXX addresses. Meaning there's a store instruciton in your code that's writing/storing to a invalid address.

In the code there is only 1 store instruction.

Code:

stbu r0, 0x28 (r10)

In assembled hex form it is the 9C0A0028 part of the code.

The stbu instruction is invalid because r10 is not a memory address. Well does the code write/modify to r10 beforehand? Yes it does, with the following instruction...

Code:

addi r10, r27, 0x470

The only way r10 can end up being an invalid address is because r27 was not a memory address when this addition occurred.

r27 is not an address probably because of your incorrect hook address of the code (the C3xxxxxx part).

Keep in mind i've only tested the code in 3v3 basketball, nowhere else and it was only a handful of tests. Very possible the code is just "buggy" and needs fixing in general.

[LightKingdom666]

If you're using the NTSC-U version of the game (which I've used), your hook address (C3xxxxxx) should be the same as mine. Are you using a PAL version?

Regarding the r27 thing...

Registers r14 thru r31 are Non-Volatile Registers (aka Global variable registers). These means some of these registers may hold memory addresses that will always point to some key/critical info that COULD be useful/related to your code. The memory addresses will change/vary/update but offsets (used to find desired info) relative to them will not.

On my MSM code whenever the game executes at 0x815b5268, r27 is a memory address. That address + 0x496 always points to the character's "packet". Packet basically being a small chunk of memory that contains attributes to that character (such as Slot number). Because I have access to this "packet" and no how to find it (thanks to r27), this allows me to expand/add features to the code such as Changing every character selectively.

"Invalid write to 0x000084b4, PC = 0x80002370"

This means the instruction at 0x80002370 is executing a store (i.e. stw/sth/stb) instruction to a invalid/non-existent memory address.

The gecko code handler places cheats codes at 0x80002XXX addresses. Meaning there's a store instruciton in your code that's writing/storing to a invalid address.

In the code there is only 1 store instruction.

Code:

stbu r0, 0x28 (r10)

In assembled hex form it is the 9C0A0028 part of the code.

The stbu instruction is invalid because r10 is not a memory address. Well does the code write/modify to r10 beforehand? Yes it does, with the following instruction...

Code:

addi r10, r27, 0x470

The only way r10 can end up being an invalid address is because r27 was not a memory address when this addition occurred.

r27 is not an address probably because of your incorrect hook address of the code (the C3xxxxxx part).

Keep in mind i've only tested the code in 3v3 basketball, nowhere else and it was only a handful of tests. Very possible the code is just "buggy" and needs fixing in general.

No, I don't use the PAL version, I use the NTSC-U version (just like you). In fact, if you want, I can even show you some screenshots as proof:



Look at the two rectangles highlighted in red, and also check the address highlighted in green.

Regarding register r27, it appears like this for me:



It doesn't appear highlighted in red like the others, so I don't know.

[Vega]

So it appears there are two responsible instructions (funcs) that writes the character slot during character selection. Which is not too big of an issue. More code testing would need to be done to know which hook is best.

You cannot hook my code's source using the address you've found for numerous reasons:

Reason 1: I used a slightly diff hook than what the game actually "broke" on when I've made the code (memory breakpoint to get hook address). I explained this back in post #52 https://mariokartwii.com/showthread.php?...6#pid10656

Code:

The current hook address I didn't like because registers such as r11 weren't safe for use (which is very rare). So I needed to find a better hook address nearby.

The current hook address is within what is known as a Function.

When you get more advanced, you will learn about Function Calls -> https://mariokartwii.com/showthread.php?tid=1052

In a nutshell, my hook address was in a small small function, one without a prologue or epilogue. So its easy to know mostly what is going on in this function (form a higher level programming standpoint).

Anyway, if you scroll down a bit, the final instructions of the function are....

Address | Instruction
815b5268 | li r3, 0
815b526C | blr

Basically the function places a zero in r3 and uses the blr to return to its Parent function. It's telling the Parent function, "hey everything is good to go, keep doing what we need to do"

So anyway, this is a good hook address. At the end of functions (epilogues), registers r4 thru r12 are safe.

Same exact issue with your hook address, it's not ideal because scratch registers that are usually safe are not safe (i.e. r11)

Reason 2: Because of reason 1, r11 isn't safe (along with r10) so the code is gonna botch anyway even if its "coded right" because the source uses r11 and r10

Reason 3: You're using my default instruction for your address which won't work since the two default instructions are completely different. This also leads to you *not* including YOUR default instruction (stb r5, 0x498 (r3))

---

r27 at your hook address does appear to be the same type of constant pointer that we can use to reference the slot 0's packet (and the other slot packets)

r27 + 0x496 = slot 0's character "packet"
r27 + 0x498 = slot 0's character byte within packet
Each packet in memory separated by 0x28 bytes
r27 + 0x496 + 0x28 = slot 1's packet
r27 + 0x496 + 0x28 + 0x28 = slot 2's packet
etc etc...

Whatever game function you are currently hooked to (default instruction) appears to be a similar function to my default instruction. I can see that at 0x815B59e8 on you screenshot is li r3,0 then the instruction afterwards is blr (even though I can't see it).

Most of what I've explained won't make sense to you. It will once you become more advanced in PPC, and learn about Functions. Plus with just general experience, you will learn/know certain "tricks" and what not.


With all that being said, we simply change the Hook address to 0x815B59e8, and it should work as long as those character values you filled in are valid.

C35B59E8 00000008
7D8802A6 4800000D
030E0F03 0E0F0000
7D6802A6 396BFFFF
38600006 395B0470
7C6903A6 8C0B0001
9C0A0028 4200FFF8
7D8803A6 38600000
60000000 00000000