3 approaches people normally go in for
1) Throw wires and cut traces inside a controller. Has the perk of being able to rock up to any old console and any game and use it.
1a) There are some devices that sit between controllers and the device and are smart enough to interact and inject their own code there. Not sure anything like this exists for the Wii/GC at this point in time. Could make one I guess (this is what things like the arduinos and teensy family of chips are basically made for, though might need something a bit faster lest you introduce your own lag). Can also do fun macros, turbos and more with this sort of thing.
2) On newer systems there is a hypervisor that handles interactions between systems and the software running on it. Fiddle with this to change the signals it gets in/sends on and yeah. Don't know if Wii IOS/CIOS is quite capable of this or you are inclined to go there as you will probably be modding it yourself (some things like the 360 and 3ds have options to do this from within their mods).
3) You modify what the game looks for to trigger certain actions or do some kind of what might be a 2a) approach seen on older devices.
Modification is often tedious as there are likely dozens of separate actions used at various points in the game (menus, credits, in game, other menus, minigames...). At the same time dozens of separate actions might not be your goal and instead just one is all you really want.
Here things diverge depending upon how the game is coded (and you might want to read the section after this as it also applies here).
Said divergences happen when the game allows some measure of control customisation, even just prebaked control schemes, vs none at all. Control schemes and customisation (even if it is limited and you can't have something like I guess it would be accelerate mapped to stick down left just because) then already have code that varies what it does depending upon input and you can fiddle with that. If it is hardcoded then you either do the 2a) thing below or change what it looks for to do the action.
The 2a) thing above involves debouncing. Buttons are not just magically on or off/pressed and not pressed and for a few milliseconds it might read as pressed one bit and then not and then pressed. If you have ever had an old mouse start to double click when you only clicked once you have met this in its failure form. This can be quite troublesome if two separate things are supposed to happen from a single press and one function sees pressed but because of bounce the one the game handles right after sees unpressed because it was the wrong millisecond (which over the course of a few thousand button presses in a game is almost an inevitability).
To that end once a frame or so the game will grab the state of the buttons (a process called debouncing) and everything will operate on that for the next frame.
The would be hacker can then take this debounced data, do something like if A is pressed then set A to not pressed and set B to pressed (and any amount more of that you like to remap it) and thus have a game wide change.
Newer systems/many modern PC games will do something different and decouple the input from the framerate and thus not have it be as unresponsive during low frame rate but that is a different discussion.
Other than soldering things and 1a) then this all necessarily involves some hacking that is usually attempted by the more experienced hackers rather than those coming in cold. That said it makes for a reasonable first major hacking project.
For instance if I wanted to change the accelerate button I would likely start off in a boring time trial. Now find the speed with a cheat search (easy enough as you can control your speed). Somewhere along the code leading there (which your tracing debugger will be displaying at the last however much for, might have to repeat a few times to properly work your way back up. https://www.romhacking.net/documents/361/ covers tracing on the GBA but works the same on any good debugger really -- break on read and break on write being kind of the same thing regardless of what system you are playing with) will be something that reads the original accelerate button and says if pressed add speed until you reach maximum. You would change it to instead read the I guess it would be B button press (which is very likely nearby http://hitmen.c02.at/files/yagcd/yagcd/frames.html , you want section 9.2) in either the original controller location or better yet the debounced one. As you are not being forced to construct new code and instead redirecting a bit, or maybe only adding a few lines to something that is already reading it every frame to give to the rest of the system then it can make for a reasonable starter project vs something where you are tangling with the internals in a big way, adding masses of new functionality or the like.
1) Throw wires and cut traces inside a controller. Has the perk of being able to rock up to any old console and any game and use it.
1a) There are some devices that sit between controllers and the device and are smart enough to interact and inject their own code there. Not sure anything like this exists for the Wii/GC at this point in time. Could make one I guess (this is what things like the arduinos and teensy family of chips are basically made for, though might need something a bit faster lest you introduce your own lag). Can also do fun macros, turbos and more with this sort of thing.
2) On newer systems there is a hypervisor that handles interactions between systems and the software running on it. Fiddle with this to change the signals it gets in/sends on and yeah. Don't know if Wii IOS/CIOS is quite capable of this or you are inclined to go there as you will probably be modding it yourself (some things like the 360 and 3ds have options to do this from within their mods).
3) You modify what the game looks for to trigger certain actions or do some kind of what might be a 2a) approach seen on older devices.
Modification is often tedious as there are likely dozens of separate actions used at various points in the game (menus, credits, in game, other menus, minigames...). At the same time dozens of separate actions might not be your goal and instead just one is all you really want.
Here things diverge depending upon how the game is coded (and you might want to read the section after this as it also applies here).
Said divergences happen when the game allows some measure of control customisation, even just prebaked control schemes, vs none at all. Control schemes and customisation (even if it is limited and you can't have something like I guess it would be accelerate mapped to stick down left just because) then already have code that varies what it does depending upon input and you can fiddle with that. If it is hardcoded then you either do the 2a) thing below or change what it looks for to do the action.
The 2a) thing above involves debouncing. Buttons are not just magically on or off/pressed and not pressed and for a few milliseconds it might read as pressed one bit and then not and then pressed. If you have ever had an old mouse start to double click when you only clicked once you have met this in its failure form. This can be quite troublesome if two separate things are supposed to happen from a single press and one function sees pressed but because of bounce the one the game handles right after sees unpressed because it was the wrong millisecond (which over the course of a few thousand button presses in a game is almost an inevitability).
To that end once a frame or so the game will grab the state of the buttons (a process called debouncing) and everything will operate on that for the next frame.
The would be hacker can then take this debounced data, do something like if A is pressed then set A to not pressed and set B to pressed (and any amount more of that you like to remap it) and thus have a game wide change.
Newer systems/many modern PC games will do something different and decouple the input from the framerate and thus not have it be as unresponsive during low frame rate but that is a different discussion.
Other than soldering things and 1a) then this all necessarily involves some hacking that is usually attempted by the more experienced hackers rather than those coming in cold. That said it makes for a reasonable first major hacking project.
For instance if I wanted to change the accelerate button I would likely start off in a boring time trial. Now find the speed with a cheat search (easy enough as you can control your speed). Somewhere along the code leading there (which your tracing debugger will be displaying at the last however much for, might have to repeat a few times to properly work your way back up. https://www.romhacking.net/documents/361/ covers tracing on the GBA but works the same on any good debugger really -- break on read and break on write being kind of the same thing regardless of what system you are playing with) will be something that reads the original accelerate button and says if pressed add speed until you reach maximum. You would change it to instead read the I guess it would be B button press (which is very likely nearby http://hitmen.c02.at/files/yagcd/yagcd/frames.html , you want section 9.2) in either the original controller location or better yet the debounced one. As you are not being forced to construct new code and instead redirecting a bit, or maybe only adding a few lines to something that is already reading it every frame to give to the rest of the system then it can make for a reasonable starter project vs something where you are tangling with the internals in a big way, adding masses of new functionality or the like.
This actually all sounds interesting, but CTGP-R tends to ban you for modifying the code at all while attempting to play online unfortunately, even if its non-malicious, so I'll probably have to avoid that. Fiddling with the wii itself might be a decent alternative to that, and if the solution I found doesn't work, I might look into that. I'm also not exactly in a position to sauter anything myself yet, but I've been considering doing that in the future so I might attempt that at a later date for fun. However, after looking around for a bit I found a series of controler adapters that when paired together SHOULD theoretically make it possible. If it ends up working I'll prob. toss a guide out there since its $80 of stuff that took me way too long to figure out otherwise. Either way, thanks for the help and a pretty interesting read.
Similar threads
- Question
