Hacking Disabling Buttons On Controller

[StarMiner]

Hey all,

I've been recently coding with Dolphin Memory Engine trying to find some codes to create with. I'm wondering if anyone knows the codes for disabling buttons on a wii remote when a certain action happens. It would benefit me greatly.

Thanks!

(Also @FAST6191 I'd love your help too if you're able to!)

- StarMiner

 

[FAST6191]

Curious. Did not get a notification.

Few really do this, though it is well within the realm of ROM hacking at least (cheats is harder, saving the using a cheat to edit the binary which is still basically ROM hacking).

Activating a thing when you press a button is boring and basic cheat making really. Disabling actions/buttons is harder; cheat engines basically do their own thing in addition to the game, this would be changing how the game behaves.

It would work on the same principle as control changing, for which there are three schools of thought (outside of playing with a soldering iron and scalpel on a given controller of course).

1) Many years ago it was realised that taking an external switch and putting it inside memory was prone to all sorts of issues; switch bounce*, latency, stray voltages...
To that end on most games on anything vaguely modern the state of the switches is usually copied once per frame (can be more if doing the decoupled thing), in an act called debouncing. This will then be what the game references rather than whatever the hardware documentation says is where the control state lands in memory (though that area will obviously be read once a frame or whatever and thus you can find the debounced location trivially with a debugger).
For simple switches this will tend to be a line of 1 and 0, usually 1 being pressed and 0 not.
For analogues (which would include motion sensors) this will be some range of values corresponding to which direction and what angle.

*if say within the same frame the switch was still flicking between states then the button will appear to be pressed for one action and then might not be the for the next despite it being pressed and earlier in the frame acting.

Many simple control swaps will take this debounced area, say "if this is set then set this other and reset this" and thus you have a probably game wide control swap.

2) The game's own code will do something like if this button is pressed then do it. You change the look for this button to a look for that button and you have your control swap.
This has the benefit of only being for one action, this is also a downside if you are doing something like changing controls to work around a bad/dead controller as you possibly have to repeat for many actions.

3) In the event of the game having user changeable controls, even if just a bunch of premade choices, then 2 is kind of done for you and you have to find the thing by which is decodes the value and change that. Might still be code but might also be something else.


You would then be able to use any of those methods to do something.
In the event of a certain game state (presumably you would use a cheat to find it) you can either disable the apparent press of a button (IF [event] then set button to 0), disable the read during that event/make the read check for the event and do nothing, or change the button it looks for to an impossible combo or something.


Possible alternative. Depending upon the action then there might be ways around that.
For instance if I say wanted to disable jumping while invincibility happens I could do the above by finding something only a given value while invincibility is active and then having an IF ELSE type deal on a controller tweak. However if there is gravity in the game that changes jump height I might slam that to maximum (presumably then only tiny jumps) while the other event is happening, or if you have to press and hold things to jump then find what is noting the controller is held and disable that such that the user appears to have let go immediately. You could also make for extreme negative consequences via the same method to train your player not to; I am sure you could make a makes the user die/fail cheat (run out of time, cost a life, set life to 0/minimum...) and have that activate in your desired state (back to the earlier thing IF invincible AND IF jump happened then set time to 0 such that they die next frame).
Not so good for making something little kid friendly but if doing a challenge run type cheat then different matter entirely.

 

[StarMiner]

Thanks for the response!

But I'm sadly still having issues

I've gone ahead and scanned for the A button press in the game and it appears there are multiple addresses that show when the A button is pressed (usually the value of the byte being '08'). There have to be more than 10 addresses. Would I have to change them all?

Also I've gone ahead and scanned for when a player bubbles and I found quite a few values corresponding when it happens, but when I change those values or put them in a nop, they still happen. Is there a way to find an instruction on this? I remember you telling me in my previous post I could find the address of when the player's bubble is popped, but it happens in a single frame and I don't think I can use Dolphin's memory engine's scanning feature for such. Also, your last suggestion is great, I would be able to do that if all else fails, but I'd love to give this all I've got before hand!

Also I’m not sure what you mean by using a debugger or what it is and finding the debounced code I need ‘trivially’. If you would be able to send me sources or any sort I would appreciate it!

@FAST6191

Thanks again for the help!

- StarMiner

 

[FAST6191]

I am less familiar with gamecube/wii debugging than I might like to be giving specific advice. At one point dolphin was quite reasonable as a debugger, and there are some hardware options (see USB gecko), but it variously gains and loses them in the general builds so you might end up having to find an old version, and I don't know if it is still in house or you will need to set up something like GDB ( https://wrongbaud.github.io/posts/ghidra-debugger/ is for the GBA but the general idea applies, there are other things that speak to GDB, including the main gnu debugger that something like devkitpro/devkitppc might come with). You may also benefit from poking around tool assisted speedrun forums as manipulating code/understanding code is kind of a big deal there and they tend to make/fork emulators to play to that.
My general intro to debugging is from an old GBA emulator that was more command line based than the graphical stuff people go in for today (for the GBA I would suggest the link above or no$gba debug) but https://www.romhacking.net/documents/361/ covers the general mindset.

Generally though debugging works by things called breakpoints, though you will also tend to have watchpoints/logpoints that note things in a big list.
In standard computer security models there are three things you can do
Read
Write
Execute code (some more security minded setups caring a lot about this to stop people say opening a document and having code in memory from that to run).

This gives you break on read, break on write, break on execute. BPR, BPW and BOE/BPE/some variations depending being the short form of those that many emulators will use.

As controllers tend to be in fixed locations in hardware (tends to make life easier after all) then you will be able to find something that reads it quickly enough, might be different in game. As the read or commands immediately after will also have to include a destination for the debounced section to go to then you have the second part of the equation. All far easier than a lot of more general debugging sessions where things are unknown until you make a cheat or something to source the location. Forgot to also note you might have to do it for multiple controllers for a multiplayer.

As far as using cheats to find it (I hope you are holding the button/forcing it on after you search) then I can't say I have really have gone that way and if I want to alter controls then I have other means. Still it could work in theory as it is a memory changing event and that is cheat searching. I don't know that there will be multiple debounced locations, makes little sense for there to be but I can't rule it out. For the sake of stating the obvious though then great you have a bunch of locations active when A is pressed. What happens to those when you press (and hold) B, 1,2, start, up, down, left, right and other buttons? If they do nothing then the change is related to what happens maybe but not the buttons, if the buttons change whatever remains you have the debounced section.
For GC stuff then chapter 9 of http://hitmen.c02.at/files/yagcd/yagcd/frames.html For Wii then probably somewhere on wiibrew, or the dolphin source code.

For the bubble thing in the other thread then I figured there would be a timer. Your cheat search should have a thing for "value changed" in it (get a better one if it does not). Get into a bubble, start the search, advance a frame if your emulator allows that (many do, including those nice ones) or just go back into the game to have it run fractionally (60 frames per second, chances are your clicks/button presses will be slow enough) and search again for changed values. Repeat until you have it. I would do changed at first -- timers can be rising and falling ones and different games do different things here. Force the timers to be basically zero if above a certain value and you have your cheat. If you get better at debugging then you have an address right at the heart of it all and then you can work on changing it such that nothing happens.