MKWii.org
Explanation of Hooktypes - Printable Version

+- MKWii.org (https://mkwii.org)
+-- Forum: Hacks/Modding (https://mkwii.org/forumdisplay.php?fid=14)
+--- Forum: Hacking General (https://mkwii.org/forumdisplay.php?fid=23)
+--- Thread: Explanation of Hooktypes (/showthread.php?tid=1008)



Explanation of Hooktypes - zak - 12-26-2018

What are Hooktypes?

I get asked this question by noobs quite a bit. For starters, if you are new to playing with Cheat Codes (GCTs), let's go over some basics.

The Basics

Every Disc/ISO Loader application for the Homebrew Channel comes with a "Cheat" setting of some sorts. This "Cheat" setting is usually referred to as the Ocarina Setting. It has two options. ON or OFF. Simple to understand. ON would be to activate your GCT file, and off would be to not activate your GCT file.

Underneath the Ocarina Setting (or nearby; depends on which HBC app you are using), there is a setting called HookType.

These are the following Hooktype Options


- None (in some modern HBC apps, setting None is the same as VI/VBI)
- VI (can also be referred to as VBI)
- KPAD Read
- Joypad
- GXDraw
- GXFlush
- OSSleepThread
- AXNextFrame



Back in the olden days (pre 2011-ish), the source code for the Gecko Code Handler (which all programs use btw) was not fully optimized yet. So depending on which HBC app you were using, you would be required to change your Hooktype.

For example, back in the olden days, if an MKW player was using Riivolution, codes would not work with the VI/VBI hooktype. Riivolution users had to use the GXDraw Hooktype. So VBI was considered unreliable back then. Obviously times have changed, the Gecko team optimized their code hander, and HBC apps were updated. For any modern HBC app today, VBI works for 99.999% of MKW Cheat Codes. CTGP uses GXDraw hooktype, fyi. 

Other Wii Games (even on modernized HBC apps) require special/different Hooktypes. For Brawl, OSSleepThread is required for most codes to function reliably.

Technical Details

Now, let's get into what a Hooktype actually is.

Mario Kart Wii was written in C++. When the game was developed there would be certain sub-routines (functions) that will be called upon depending on what state the game is in. Certain functions are always called once per frame. Thus for MKW, those certain functions would be called upon 60 times per second. Most of these certain functions actually exist in every Wii game, not just MKW.

The names of these certain functions were discovered over time. If one were to look at these functions at the lowest level (ASM), it would show a string of hex byte code. You could take that string of hex from one game, search it within a different game's RAM/memory, and find that function on the other game (it's RAM/memory location).

The Gecko Code handler (within its source code) has these 'hex byte strings' to these functions and then searches for them in the game as the game is booted. Once these functions are found, their respective RAM/memory addresses are stored and are used for certain variables (such as controller activators/deactivators). This is how the gecko type activators/deactivators work universally for any code (even if a code's address is not being read/executed by the game at that moment in time when you press an act/deact)

In regards to the list above. Some games may not call one of those specific functions every frame, which will result in that function (hooktype) being unreliable. As I mentioned before, for MKW, VBI is a reliable hooktype. Unfortunately, its reputation has been tarnished a bit from issues with HBC apps/source code in the past. The only reason I can see using something other than VBI is trying to get an F6-type code working if it isnt reliable with VBI. But in my experience, With the optimized/modern Gecko code handler, if an F6 type code doesn't work in VBI, it wont work in any hook type. If you are wondering why CTGP uses GXDraw, it would be best to ask Chadderz or MrBean.

Thanks for reading!