@Vague Rant I played a little bit with Excite Trucks CC Hack, because I wanted to remap some buttons, but now I have two actions on one button and I don't know how to fix it. Here is my idea: Accelerate with Y, Turbo stays at ZR and Brake on ZL. It would make the air tricks easier. So I changed the code of the europe version to this:
Now I have Brake and Turbo on ZL at the same time. I can't find the solution in the code. Is there another trick to this or should I create a new line for that? Thanks a lot
I have some good and bad news about Fluidity.
The good news: It seems more then possible to be done, the ice form and water work great! (Emulated on dolphin)
The bad news: The cloud seems the hardest one to do. I tried it but it just seems confusing, and i forgot the controls it uses, but i know one included shaking to drain the cloud.
It might use that low level motion data you were talking about (possibly) Although its not from next level games, i have a small feeling it does, I dont think it does though since the motion is used a lot, so it wouldnt be low level.
@Vague Rant Kirby Return To Dreamland already have a cc hack but needs a gameconfig.txt file stored on sd card to work. So it can't be played as inject with wii u gamepad. Do you think it's possible to make a new cc hack without the needing of this gameconfig.txt file ? Thanks.
@Vague Rant Kirby Return To Dreamland already have a cc hack but needs a gameconfig.txt file stored on sd card to work. So it can't be played as inject with wii u gamepad. Do you think it's possible to make a new cc hack without the needing of this gameconfig.txt file ? Thanks.
Nice, I'm glad you eventually got DK Returns running on the GamePad, super awesome to hear that it works. Thanks for letting me know about Wario as well. The broken controls like that are usually a symptom of the Wii game not correctly detecting the Classic Controller; the same thing happens with injections of Excite Truck unless you enable the "Force Classic Controller connected" checkbox in the injector tool. I wonder if Wario could be fixed with that? If not, it's out of my hands, it's an issue with the Classic Controller emulation in Wii VC injection where it's just not compatible with some games. Unfortunately, that's the case for New Super Mario Bros. Wii, injected versions don't recognize the Classic Controller. Silent Hill definitely sounds like it's on the more complicated end of the spectrum, since it has multiple different hand motions that have to be recognized, so that's probably on the less-likely end, sorry.
That sounds like a great idea. It seems relatively feasible. I think the major complication would be remapping the inputs on the Wii Remote itself, since you'd need a different layout (A to jump, B to shoot, etc.). To date, I haven't done any remapping of original game inputs, only adding additional mappings on the Classic Controller, so I would need to figure out how to do that, but it does sound cool. I assume you mean retaining the original IR pointer for aiming, right? So you'd move on the Nunchuk, shoot/jump on B/A, maybe Morph Ball on Nunchuk C like in Prime, lock on camera on Nunchuk Z ... Concentration could either use the original motion controls or be mapped on Wiimote Minus or something, since the game doesn't use Minus anyway as far as I can tell. This is definitely an interesting one. As always, no promises, but my curiosity is piqued.
Animal Crossing: City Folk aka Let's Go to the City is the third game in Nintendo's Animal Crossing life sim series. The main addition to this entry was Wii Speak support the titular city, expanding on the small town areas of previous entries. This perhaps falls into the "controversial Wii sequel" series, with many complaints about the lack of improvements over the earlier games and the loss of NES games, since Nintendo were now selling those on the Wii Shop Channel instead of giving them away for free. Still, though not revolutionary, City Folk has the same charming atmosphere as the rest of the franchise. And at least it's a real Animal Crossing game. Cough, Amiibo Festival.
Home
Home Menu works as normal but remember to enable the pointer with L and use the correct stick for your code
Open/Close Home Button Menu
Wiimote D-Pad
D-Pad
Up: Change Camera
Left/Right: Change Tool
Down: Put Away Tool
Wiimote A
A
Confirm
Action
Wiimote B
B
Cancel
Run
Pick Up Items
Wiimote Plus
Plus
ZR
Open/Close Map
Next Tab
Wiimote Minus
X
ZL
Open/Close Inventory
Previous Tab
Wiimote 1
Minus
Take Photo
Wiimote 2
Y
Open/Close Photos
Nunchuk Analog Stick
Left Stick
Movement
Nunchuk C
Not mapped
(use A instead)
Confirm
Action
Nunchuk Z
R
Cancel
Run
Pick Up Items
Wiimote IR Pointer
L (toggle)
Left Stick or Right Stick
(depends on code used)
Move Cursor
General Notes
Two code varieties for this one, choose whichever feels more natural to you. IR aiming is pretty important to City Folk, with all inventory manipulation being IR-based. If you choose the Left Stick code, the Left Stick toggles between movement and IR input, i.e. you can't move and point at the same time. However, there's rarely any advantage to this, as there's no real multitasking possible. If you choose the Right Stick code, all you can really do is move the stupid cursor around while you run. Whee. If you want my opinion, use the Left Stick code.
Where possible, I try to "intelligently" enable/disable the pointer mode. The player can always toggle it on/off with the L button, but some other actions (opening the Inventory, Map or Photos menus) will automatically enable pointer mode for you. Try to remember to exit these menus using the same button you used to open them: e.g. you can press X to open the inventory (pointer turns on automatically) then X again to close it (pointer turns off automatically). If you instead open the menu with X then close it with B, you'll still be in pointer mode, because you didn't close with X. In this case, you should press L to disable the pointer manually. I'm trying here.
If the IR pointer movement is too fast/slow for you, you can adjust it by editing the float 0.015 (3C75C28F) about halfway through the code. You could adjust it down to 0.01 (3C23D70A) for a slower cursor, or bump it up to 0.02 (3CA3D70A) for a faster cursor, or whatever other number feels appropriate. There's plenty of hex float converters online, I linked one in a previous post somewhere.
It's worth knowing that this game supports USB keyboards. Using an on-screen keyboard with an IR pointer is sort of acceptable, but using an on-screen keyboard with a pointer you control using an analog stick is a bad time. If you have a USB keyboard handy it will hugely improve the experience if you're looking to do any typing (e.g. writing letters or chatting with other players over network play). It doesn't have to be a special Wii keyboard or anything; I use a standard PC Logitech Unifying USB dongle in my Wii. Failing that, if you use the phone in your house you can change the keyboard settings to use an old-school mobile keyboard which you might find easier to use with an analog stick.
I got a specific request (elsewhere, not in this thread) for an option where the Right Stick pointer is always enabled, but personally I think it's kind of bad. The game changes a lot of things about how it works when you're pointing at the screen, which don't make sense when playing on a traditional controller. For example, pressing A now makes you walk toward the cursor instead of interacting with whatever is in front of you. Pointing at the screen also causes the HUD to display at all times, which means the screen is cluttered with on-screen buttons the whole time you're playing. If anybody here wants this version, I guess ask for it but I find it offers an inferior experience to either of the codes above and shouldn't really be considered an equal option against those.
Changelog
v1.1 corrects the cursor speed; thanks to @RiceKryzpi for noticing this!
Technical Notes
This game has that same Super Paper Mario issue where the Home Button Menu causes a Classic Controller re-init every 64 frames. I solved it the same way, disabling getInfoAsync() from running. Thinking about it more since last time, I suspect this probably has something to do with checking things like the battery level that displays in the HBM. I do still allow getInfoAsync() to run when you first enter the HBM in both this and Paper Mario, so it's not like the HBM is running blind but if you just leave it open it might not correctly track the battery level or something pointless like that, I don't care.
Briefly, the code is: C2 to allow Classic Controller's left stick to be read for movement, C2 to disable the bad EXT error, 04 disable getInfoAsync(), C2 and C2 actually redirect analog reads to the Classic when needed, C2 custom read_kpad_dpd() (Left Stick code has an additional feature to prevent character movement while in pointer mode) and then the button injector gets inserted into KPADRead() in the last C2.
Credits
mogchamp from the AC: Wiimmfi Folk Discord for advising on the button layout
@Vague Rant Lmao remember how you could freeze fish in the ice form? That was funny to do! (In fluidity)
(There hasnt been much jokes here, and i know these hacks can be tiring, so i want to start showing funny things to cheer you up!)
@Vague Rant
for reference, several games support the analog triggers of the original (non-pro) classic controller. This is especially superior in the case of racing sims, where the accelerator pedal is begging for an smooth change. It would be great if you could pull the code from one of the games listed in that post and apply it to your mods.
Seeing your codes above, I always wanted to try to play Mario Kart like many other racing games, with R/L as Accelerate/Brake, I should try toying with it on Dolphin.
I've just edited the Mario Kart Wii post to add a full remapping assembly hack as I mentioned in a previous post. This hack remaps every button to the button that it already is, i.e. it does absolutely nothing by default. You can edit this any way you like and plug it into CodeWrite to get a custom button mapping.
@Vague Rant I followed your tutorial and I was able to (partially) make a CC hack for Mario Super Sluggers. I picked that game to practice because it doesn't have a "Connect the nunchuk" message, and I don't have any experience with making gecko codes or working with ASM so I don't know how to make a code to skip that. I was able to make the game recognize the Classic Controller thanks to your guide, though I still haven't managed to emulate the motion controls (shake wiimote, tilt, etc). Thank you soo much! I'm still happy with what I managed to do. I will keep practicing!
I was gonna ask, could you explain how to remove or skip the "nunchuk" error message? Because I wanna try that with Project Zero 2: Wii Edition (PAL). I know that the method might vary depending on what game it is, but any explanation will be useful!
That's awesome, congrats on the progress! Especially impressive without having any prior experience, great work. I don't really have a "generic" way to trigger motion controls across different games since they all tend to have different setups for their motion controls, so I generally have to write a different hack for each game that needs accelerometer stuff. It would be hard to really write up a tutorial on that because it's different for each game. The general idea is that inside read_kpad_acc() you need to force the game to load some specific accelerometer data instead of the real data whenever a certain button is pressed.
My usual trick for doing this is to map various accelerometer functions as buttons 0x80, 0x40 and 0x20 on the Wii Remote in the button injector. These are all unused bits on the Wiimote, i.e. technically possible button values which simply don't exist on the Wiimote. Then inside read_kpad_acc(), I'll write a routine which checks if the user pressed one of those fake buttons and load fake data in before calc_acc() (the function which processes that data) can run. calc_acc() is pretty easy to find because it always runs three times in a row, once for each axis. Before each function call will be an lfs f1, 0xXXX(r30) which is reading in the real accelerometer data, so that's the ideal place to insert some code to replace the real data.
For fixing Nunchuk errors, usually I will load the game up in Dolphin and let it run until it reaches some kind of Nunchuk error screen. Then in the Memory tab I will switch the search type to ASCII and search for the text that shows up in the Nunchuk error (e.g. "Please connect the Nunchuk to the Wii Remote" type of thing). If it is able to locate the error text, I can then set a read breakpoint (check the Read only button, then right click where the error text is located in memory and Toggle Breakpoint) on that text and find the code where the text is loaded.
From there, you want to use the Callstack in the Code tab to trace your way backward through the code trying to find where the actual Nunchuk check occurred which caused the game to display the error. I mostly do this part via trial and error, I'll go back one or two calls and set an execute breakpoint there (click in the left column of the disassembler in the Code tab) then switch to the Nunchuk in Dolphin settings and see whether that code is still running.
What you want to find is the point where different code paths are taken depending on which controller is connected. The extension types important to us are 0 (none), 1 (Nunchuk) and 2 (Classic Controller). So eventually you should reach a point where there's code which only runs if a specific value is not equal to 1. The extension check will generally look something like cmpwi rX, 0x1, but it's important to note that checking if something equals 1 is very generic code that's used all over the place, so finding a cmpwi rX, 0x1 doesn't mean you've found the Nunchuk check.
If you suspect you have found the Nunchuk check, set a breakpoint on that instruction and try letting the game run with no extension, Nunchuk and Classic Controller. If the register that gets checked matches the values I mentioned above based on which controller you have connected, you can be reasonably sure that it is checking the extension type. If that check fails (is not equal to 1), it means the current connected controller is not a Nunchuk. At that point, you can change this check to also accept Classic Controller, usually looking something like this in assembly which you can paste into CodeWrite:
Code:
cmpwi r0, 0x1
beq- RETURN
cmpwi r0, 0x2
RETURN:
This isn't doing anything too complex: instead of just checking if the value is 1, this checks if it's 1, then checks if it's 2. That way, whatever behavior the game was going to run if the extension type was 1 (like skipping over running the Nunchuk error) will also run if the extension type is 2. A lot of the exact process for how the Nunchuk is checked for varies wildly from game to game, but the extension type values are part of the SDK, so they're something reliable to look for.
@Vague Rant I played a little bit with Excite Trucks CC Hack, because I wanted to remap some buttons, but now I have two actions on one button and I don't know how to fix it. Here is my idea: Accelerate with Y, Turbo stays at ZR and Brake on ZL. It would make the air tricks easier.
Now I have Brake and Turbo on ZL at the same time. I can't find the solution in the code. Is there another trick to this or should I create a new line for that? Thanks a lot
Ah, yeah, that one is a bit more difficult to edit. In a couple of my early hacks I was trying to optimize the button injector down to be as small as possible by checking multiple buttons at the same time. You can see me doing that in instructions like 70A42082. This is checking buttons 0x2000, 0x80 and 0x2 (2082) all at once, so the lines like that are where your problem is occurring, since the buttons are already mapped there. In later hacks I decided to stop optimizing the button checks just so they'd be easier to edit exactly for this reason. I should come back to Excite Truck to add IR pointer support anyway, since I made that one before I knew how to do that, so if you don't mind the wait I'll "modernize" the button injector when I do that, otherwise yeah, it will be a bit tougher to change the button values.
@Vague Rant Kirby Return To Dreamland already have a cc hack but needs a gameconfig.txt file stored on sd card to work. So it can't be played as inject with wii u gamepad. Do you think it's possible to make a new cc hack without the needing of this gameconfig.txt file ? Thanks.
Yeah, I think it should be possible to convert crediar's existing Metafortress fixes into IPS patches which can apply to the main.dol. I don't know what the format of gameconfig.txt files is like but I think it's just a list of patches to the binary, which is essentially what an IPS is as well. I'm definitely not sure of this though, that's just roughly how I think it works.
I think the easiest way to do this would be to edit the code yourself. It's somewhat complex for this game due to the different pointer modes, so I'll put my (and crediar's, this button injector is based on crediar's work) original assembly in a spoiler below:
Code:
; 803BF784 for USA
; 803BF9EC for USA (Rev 1)
; 803BF5D4 for EUR
; 803BF83C for EUR (Rev 1)
; 803BF928 for JPN (Rev 1)
; 803C8330 for KOR (Rev 1)
stw r0, 0x68(r31)
INJECTOR:
; held
lwz r8, 0x60(r31)
bl TRANSLATOR
lwz r6, 0x0(r31)
or r8, r8, r6
stw r8, 0x0(r31)
; released
not r8, r8
lwz r6, 0x8(r31)
and r8, r6, r8
stw r8, 0x8(r31)
; pressed
lwz r8, 0x64(r31)
bl TRANSLATOR
lwz r6, 0x4(r31)
or r8, r8, r6
stw r8, 0x4(r31)
; enable pointer
andi. r6, r8, 0x40 ; enable
beq- TOGGLE
li r6, 0x2
stb r6, 0x5E(r31)
b RETURN
TOGGLE:
; toggle pointer
andi. r6, r8, 0x80 ; toggle
beq- RETURN
lbz r6, 0x5E(r31)
xori r6, r6, 0x2
stb r6, 0x5E(r31)
b RETURN
TRANSLATOR:
li r7, 0x0
BTN_HOME:
andi. r6, r8, 0x800
beq- BTN_UP
ori r7, r7, 0x8000 ; Home
BTN_UP:
andi. r6, r8, 0x1
beq- BTN_DOWN
ori r7, r7, 0x8 ; up
BTN_DOWN:
andi. r6, r8, 0x4000
beq- BTN_LEFT
ori r7, r7, 0x4 ; down
BTN_LEFT:
andi. r6, r8, 0x2
beq- BTN_RIGHT
ori r7, r7, 0x1 ; left
BTN_RIGHT:
andi. r6, r8, 0x8000
beq- BTN_A
ori r7, r7, 0x2 ; right
BTN_A:
andi. r6, r8, 0x10
beq- BTN_B
ori r7, r7, 0x800 ; A
BTN_B:
andi. r6, r8, 0x40
beq- BTN_X
ori r7, r7, 0x400 ; B
BTN_X:
andi. r6, r8, 0x8
beq- BTN_Y
ori r7, r7, 0x1080 ; - and toggle pointer
BTN_Y:
andi. r6, r8, 0x20
beq- BTN_L
ori r7, r7, 0x180 ; 2 and toggle pointer
BTN_L:
andi. r6, r8, 0x2000
beq- BTN_R
ori r7, r7, 0x80 ; toggle pointer
BTN_R:
andi. r6, r8, 0x200
beq- BTN_ZL
ori r7, r7, 0x2000 ; Z
BTN_ZL:
andi. r6, r8, 0x80
beq- BTN_ZR
ori r7, r7, 0x1040 ; - and enable pointer
BTN_ZR:
andi. r6, r8, 0x4
beq- BTN_PLUS
ori r7, r7, 0x50 ; + and enable pointer
b BTN_PLUS
BTN_PLUS:
andi. r6, r8, 0x400
beq- BTN_MINUS
ori r7, r7, 0x90 ; + and toggle pointer
BTN_MINUS:
andi. r6, r8, 0x1000
beq- DONE
ori r7, r7, 0x200 ; 1
DONE:
mr r8, r7
blr
RETURN:
The ; comments at the start are the addresses to insert the code which you can paste into CodeWrite along with the assembly to get a Gecko code of the same, and from there you can adjust it however you see fit. I know it's pretty daunting to look at, but the parts you want to change are the lines that go ori r7, r7, 0xXXXX. They have comments after them like ; 1 to indicate what button that number means. Some of them are pressing multiple buttons simultaneously, like 0x90 means 0x80 (toggle pointer) plus 0x10 (the Wiimote Plus button).
Yeah, Fluidity does seem like a bit of a complicated one overall. I still haven't looked into it yet, but it's a game I really like, so definitely one I'll make an attempt at. Whether that will be fruitful, who knows; there's plenty of games I've looked into but haven't been successful in hacking, with those games falling onto kind of a spectrum from "I want to keep trying on that one" to "I'll die if I look at that game for one more second."
@Vague Rant
for reference, several games support the analog triggers of the original (non-pro) classic controller. This is especially superior in the case of racing sims, where the accelerator pedal is begging for an smooth change. It would be great if you could pull the code from one of the games listed in that post and apply it to your mods.
That is definitely a cool feature, but sorry, not likely to be something I can do. That would require an understanding of how each individual game handles acceleration and braking, since that's all game-specific code. Finding how it works in a one game wouldn't really help me to understand how/where vehicle movement is handled in a different game entirely. I think the case where it would be most likely to be achievable by me would be if there's games that support using the right analog stick to accelerate/brake. It would probably be possible to reconfigure the analog shoulder input to handle existing right stick accelerating/braking, and it would have to be truly analog already--unlike Mario Kart Wii where the right stick behaves like two buttons rather than the analog values being meaningful.
I'll die if I look at this game for one more second.
Epic Mickey is somehow another paint-based 3D platformer developed by a third-party which broke through Nintendo's stranglehold on the Wii. Developed exclusively for the console by Warren Spector's Junction Point Studios, Epic Mickey features the gameplay hook of an interactive world that Mickey can change at will using paint or thinner. With an RPG-influenced quest system, the player's choices also affect Mickey's appearance and skill growth. Lauded for its creative design and reimagining of Disney history, the game was also derided for its poor camera and complex controls. A recent HD remake saw much improved review scores, but ... here's this one!
There is one motion input which I did not solve here: when you simultaneously shake both the Wii Remote and Nunchuk, Mickey fires off all three Guardians (Tint/Turp spirits) at once. You won't be able to do that move with this hack; instead, you'll have to fire off all three individually using separate Nunchuk shakes (R button). It would be nice, but it's entirely playable without it.
The accelerometer in the Nunchuk is probably the single part of KPAD that I understand the least. I started looking at this game about seven weeks ago. This is the closest I've gotten to understanding how the Nunchuk works, which was just barely enough to get a generic Nunchuk waggle working.
The total number of different inputs in this game is more than the number of buttons on a Classic Controller. Epic Mickey uses 8 buttons and four motion inputs, plus the infra-red pointer. The Classic Controller has 10 buttons and a Right Stick to cover all of that. I had to sacrifice the D-Pad to get some extra inputs, hence having L+Right Stick emulate the D-Pad.
Epic Mickey already has an infamously difficult camera; losing direct camera control here would not be great, so D-Pad Left/Right are intact for lateral camera movements in addition to the L+Right Stick method. However, for looking up/down, only the L+Right Stick method is available here. This can occasionally be awkward because L is also your lock-on button when near enemies. This does mean you may have trouble moving the camera up/down when enemies are nearby, but you'll usually only need to do this during platforming segments, not combat.
Controls here are a mix of the remake and just mapping button-for-button. As mentioned, this game has a lot of inputs and mapping everything like the remake would make things like the menus completely incomprehensible (e.g. I can't really move the Plus and Minus buttons because when the game shows a button prompt in the menu it will be completely wrong and confusing). This is also why the A (confirm/jump) button is double-mapped on both A and B, so that menu and interaction prompts which want you to press A will work normally, but you still jump with B like a normal game. The one thing to be careful of is that when a prompt wants you to press B to cancel, that's ZR.
Technical Notes
Codes:
C2: bypass Nunchuk check
C2, C2 and C2 in read_kpad_acc(): Wiimote shakes and tilts; forcing the Nunchuk accelerometer to be "read" even when the extension controller type is Classic Controller; injecting fake Nunchuk accelerometer data before processing
these changes will overwrite memory where actual Classic Controller input is normally stored, so this needs to be backed up
C2 in calc_dpd_variable(): infra-red pointer emulation
04, 04 and C2 in read_kpad_ext(): redirect left stick into Nunchuk analog stick; redirect right stick into (hopefully) free memory so it isn't erased by accelerometer; right stick D-pad emulation
I've just edited the Mario Kart Wii post to add a full remapping assembly hack as I mentioned in a previous post. This hack remaps every button to the button that it already is, i.e. it does absolutely nothing by default. You can edit this any way you like and plug it into CodeWrite to get a custom button mapping.
That's awesome, congrats on the progress! Especially impressive without having any prior experience, great work. I don't really have a "generic" way to trigger motion controls across different games since they all tend to have different setups for their motion controls, so I generally have to write a different hack for each game that needs accelerometer stuff. It would be hard to really write up a tutorial on that because it's different for each game. The general idea is that inside read_kpad_acc() you need to force the game to load some specific accelerometer data instead of the real data whenever a certain button is pressed.
My usual trick for doing this is to map various accelerometer functions as buttons 0x80, 0x40 and 0x20 on the Wii Remote in the button injector. These are all unused bits on the Wiimote, i.e. technically possible button values which simply don't exist on the Wiimote. Then inside read_kpad_acc(), I'll write a routine which checks if the user pressed one of those fake buttons and load fake data in before calc_acc() (the function which processes that data) can run. calc_acc() is pretty easy to find because it always runs three times in a row, once for each axis. Before each function call will be an lfs f1, 0xXXX(r30) which is reading in the real accelerometer data, so that's the ideal place to insert some code to replace the real data.
For fixing Nunchuk errors, usually I will load the game up in Dolphin and let it run until it reaches some kind of Nunchuk error screen. Then in the Memory tab I will switch the search type to ASCII and search for the text that shows up in the Nunchuk error (e.g. "Please connect the Nunchuk to the Wii Remote" type of thing). If it is able to locate the error text, I can then set a read breakpoint (check the Read only button, then right click where the error text is located in memory and Toggle Breakpoint) on that text and find the code where the text is loaded.
From there, you want to use the Callstack in the Code tab to trace your way backward through the code trying to find where the actual Nunchuk check occurred which caused the game to display the error. I mostly do this part via trial and error, I'll go back one or two calls and set an execute breakpoint there (click in the left column of the disassembler in the Code tab) then switch to the Nunchuk in Dolphin settings and see whether that code is still running.
What you want to find is the point where different code paths are taken depending on which controller is connected. The extension types important to us are 0 (none), 1 (Nunchuk) and 2 (Classic Controller). So eventually you should reach a point where there's code which only runs if a specific value is not equal to 1. The extension check will generally look something like cmpwi rX, 0x1, but it's important to note that checking if something equals 1 is very generic code that's used all over the place, so finding a cmpwi rX, 0x1 doesn't mean you've found the Nunchuk check.
If you suspect you have found the Nunchuk check, set a breakpoint on that instruction and try letting the game run with no extension, Nunchuk and Classic Controller. If the register that gets checked matches the values I mentioned above based on which controller you have connected, you can be reasonably sure that it is checking the extension type. If that check fails (is not equal to 1), it means the current connected controller is not a Nunchuk. At that point, you can change this check to also accept Classic Controller, usually looking something like this in assembly which you can paste into CodeWrite:
Code:
cmpwi r0, 0x1
beq- RETURN
cmpwi r0, 0x2
RETURN:
This isn't doing anything too complex: instead of just checking if the value is 1, this checks if it's 1, then checks if it's 2. That way, whatever behavior the game was going to run if the extension type was 1 (like skipping over running the Nunchuk error) will also run if the extension type is 2. A lot of the exact process for how the Nunchuk is checked for varies wildly from game to game, but the extension type values are part of the SDK, so they're something reliable to look for.
Ah, yeah, that one is a bit more difficult to edit. In a couple of my early hacks I was trying to optimize the button injector down to be as small as possible by checking multiple buttons at the same time. You can see me doing that in instructions like 70A42082. This is checking buttons 0x2000, 0x80 and 0x2 (2082) all at once, so the lines like that are where your problem is occurring, since the buttons are already mapped there. In later hacks I decided to stop optimizing the button checks just so they'd be easier to edit exactly for this reason. I should come back to Excite Truck to add IR pointer support anyway, since I made that one before I knew how to do that, so if you don't mind the wait I'll "modernize" the button injector when I do that, otherwise yeah, it will be a bit tougher to change the button values.
Yeah, I think it should be possible to convert crediar's existing Metafortress fixes into IPS patches which can apply to the main.dol. I don't know what the format of gameconfig.txt files is like but I think it's just a list of patches to the binary, which is essentially what an IPS is as well. I'm definitely not sure of this though, that's just roughly how I think it works.
I think the easiest way to do this would be to edit the code yourself. It's somewhat complex for this game due to the different pointer modes, so I'll put my (and crediar's, this button injector is based on crediar's work) original assembly in a spoiler below:
Code:
; 803BF784 for USA
; 803BF9EC for USA (Rev 1)
; 803BF5D4 for EUR
; 803BF83C for EUR (Rev 1)
; 803BF928 for JPN (Rev 1)
; 803C8330 for KOR (Rev 1)
stw r0, 0x68(r31)
INJECTOR:
; held
lwz r8, 0x60(r31)
bl TRANSLATOR
lwz r6, 0x0(r31)
or r8, r8, r6
stw r8, 0x0(r31)
; released
not r8, r8
lwz r6, 0x8(r31)
and r8, r6, r8
stw r8, 0x8(r31)
; pressed
lwz r8, 0x64(r31)
bl TRANSLATOR
lwz r6, 0x4(r31)
or r8, r8, r6
stw r8, 0x4(r31)
; enable pointer
andi. r6, r8, 0x40 ; enable
beq- TOGGLE
li r6, 0x2
stb r6, 0x5E(r31)
b RETURN
TOGGLE:
; toggle pointer
andi. r6, r8, 0x80 ; toggle
beq- RETURN
lbz r6, 0x5E(r31)
xori r6, r6, 0x2
stb r6, 0x5E(r31)
b RETURN
TRANSLATOR:
li r7, 0x0
BTN_HOME:
andi. r6, r8, 0x800
beq- BTN_UP
ori r7, r7, 0x8000 ; Home
BTN_UP:
andi. r6, r8, 0x1
beq- BTN_DOWN
ori r7, r7, 0x8 ; up
BTN_DOWN:
andi. r6, r8, 0x4000
beq- BTN_LEFT
ori r7, r7, 0x4 ; down
BTN_LEFT:
andi. r6, r8, 0x2
beq- BTN_RIGHT
ori r7, r7, 0x1 ; left
BTN_RIGHT:
andi. r6, r8, 0x8000
beq- BTN_A
ori r7, r7, 0x2 ; right
BTN_A:
andi. r6, r8, 0x10
beq- BTN_B
ori r7, r7, 0x800 ; A
BTN_B:
andi. r6, r8, 0x40
beq- BTN_X
ori r7, r7, 0x400 ; B
BTN_X:
andi. r6, r8, 0x8
beq- BTN_Y
ori r7, r7, 0x1080 ; - and toggle pointer
BTN_Y:
andi. r6, r8, 0x20
beq- BTN_L
ori r7, r7, 0x180 ; 2 and toggle pointer
BTN_L:
andi. r6, r8, 0x2000
beq- BTN_R
ori r7, r7, 0x80 ; toggle pointer
BTN_R:
andi. r6, r8, 0x200
beq- BTN_ZL
ori r7, r7, 0x2000 ; Z
BTN_ZL:
andi. r6, r8, 0x80
beq- BTN_ZR
ori r7, r7, 0x1040 ; - and enable pointer
BTN_ZR:
andi. r6, r8, 0x4
beq- BTN_PLUS
ori r7, r7, 0x50 ; + and enable pointer
b BTN_PLUS
BTN_PLUS:
andi. r6, r8, 0x400
beq- BTN_MINUS
ori r7, r7, 0x90 ; + and toggle pointer
BTN_MINUS:
andi. r6, r8, 0x1000
beq- DONE
ori r7, r7, 0x200 ; 1
DONE:
mr r8, r7
blr
RETURN:
The ; comments at the start are the addresses to insert the code which you can paste into CodeWrite along with the assembly to get a Gecko code of the same, and from there you can adjust it however you see fit. I know it's pretty daunting to look at, but the parts you want to change are the lines that go ori r7, r7, 0xXXXX. They have comments after them like ; 1 to indicate what button that number means. Some of them are pressing multiple buttons simultaneously, like 0x90 means 0x80 (toggle pointer) plus 0x10 (the Wiimote Plus button).
Yeah, Fluidity does seem like a bit of a complicated one overall. I still haven't looked into it yet, but it's a game I really like, so definitely one I'll make an attempt at. Whether that will be fruitful, who knows; there's plenty of games I've looked into but haven't been successful in hacking, with those games falling onto kind of a spectrum from "I want to keep trying on that one" to "I'll die if I look at that game for one more second."
That is definitely a cool feature, but sorry, not likely to be something I can do. That would require an understanding of how each individual game handles acceleration and braking, since that's all game-specific code. Finding how it works in a one game wouldn't really help me to understand how/where vehicle movement is handled in a different game entirely. I think the case where it would be most likely to be achievable by me would be if there's games that support using the right analog stick to accelerate/brake. It would probably be possible to reconfigure the analog shoulder input to handle existing right stick accelerating/braking, and it would have to be truly analog already--unlike Mario Kart Wii where the right stick behaves like two buttons rather than the analog values being meaningful.
I'll die if I look at this game for one more second.
Epic Mickey is somehow another paint-based 3D platformer developed by a third-party which broke through Nintendo's stranglehold on the Wii. Developed exclusively for the console by Warren Spector's Junction Point Studios, Epic Mickey features the gameplay hook of an interactive world that Mickey can change at will using paint or thinner. With an RPG-influenced quest system, the player's choices also affect Mickey's appearance and skill growth. Lauded for its creative design and reimagining of Disney history, the game was also derided for its poor camera and complex controls. A recent HD remake saw much improved review scores, but ... here's this one!
There is one motion input which I did not solve here: when you simultaneously shake both the Wii Remote and Nunchuk, Mickey fires off all three Guardians (Tint/Turp spirits) at once. You won't be able to do that move with this hack; instead, you'll have to fire off all three individually using separate Nunchuk shakes (R button). It would be nice, but it's entirely playable without it.
The accelerometer in the Nunchuk is probably the single part of KPAD that I understand the least. I started looking at this game about seven weeks ago. This is the closest I've gotten to understanding how the Nunchuk works, which was just barely enough to get a generic Nunchuk waggle working.
The total number of different inputs in this game is more than the number of buttons on a Classic Controller. Epic Mickey uses 8 buttons and four motion inputs, plus the infra-red pointer. The Classic Controller has 10 buttons and a Right Stick to cover all of that. I had to sacrifice the D-Pad to get some extra inputs, hence having L+Right Stick emulate the D-Pad.
Epic Mickey already has an infamously difficult camera; losing direct camera control here would not be great, so D-Pad Left/Right are intact for lateral camera movements in addition to the L+Right Stick method. However, for looking up/down, only the L+Right Stick method is available here. This can occasionally be awkward because L is also your lock-on button when near enemies. This does mean you may have trouble moving the camera up/down when enemies are nearby, but you'll usually only need to do this during platforming segments, not combat.
Controls here are a mix of the remake and just mapping button-for-button. As mentioned, this game has a lot of inputs and mapping everything like the remake would make things like the menus completely incomprehensible (e.g. I can't really move the Plus and Minus buttons because when the game shows a button prompt in the menu it will be completely wrong and confusing). This is also why the A (confirm/jump) button is double-mapped on both A and B, so that menu and interaction prompts which want you to press A will work normally, but you still jump with B like a normal game. The one thing to be careful of is that when a prompt wants you to press B to cancel, that's ZR.
Technical Notes
Codes:
C2: bypass Nunchuk check
C2, C2 and C2 in read_kpad_acc(): Wiimote shakes and tilts; forcing the Nunchuk accelerometer to be "read" even when the extension controller type is Classic Controller; injecting fake Nunchuk accelerometer data before processing
these changes will overwrite memory where actual Classic Controller input is normally stored, so this needs to be backed up
C2 in calc_dpd_variable(): infra-red pointer emulation
04, 04 and C2 in read_kpad_ext(): redirect left stick into Nunchuk analog stick; redirect right stick into (hopefully) free memory so it isn't erased by accelerometer; right stick D-pad emulation
@Vague Rant FORCE Classic controller mode in UWUVCI / Teconmoons injector uses GetExtTypePatcher. Thats the tool that somehow allows Super sluggers to work with the gamepad. It patches wiivc titles to work with classic controller for more info, but thats more details
It patches to the main.dol
There is one motion input which I did not solve here: when you simultaneously shake both the Wii Remote and Nunchuk, Mickey fires off all three Guardians (Tint/Turp spirits) at once. You won't be able to do that move with this hack
Nice, I'm glad you eventually got DK Returns running on the GamePad, super awesome to hear that it works. Thanks for letting me know about Wario as well. The broken controls like that are usually a symptom of the Wii game not correctly detecting the Classic Controller; the same thing happens with injections of Excite Truck unless you enable the "Force Classic Controller connected" checkbox in the injector tool. I wonder if Wario could be fixed with that? If not, it's out of my hands, it's an issue with the Classic Controller emulation in Wii VC injection where it's just not compatible with some games. Unfortunately, that's the case for New Super Mario Bros. Wii, injected versions don't recognize the Classic Controller. Silent Hill definitely sounds like it's on the more complicated end of the spectrum, since it has multiple different hand motions that have to be recognized, so that's probably on the less-likely end, sorry.
That sounds like a great idea. It seems relatively feasible. I think the major complication would be remapping the inputs on the Wii Remote itself, since you'd need a different layout (A to jump, B to shoot, etc.). To date, I haven't done any remapping of original game inputs, only adding additional mappings on the Classic Controller, so I would need to figure out how to do that, but it does sound cool. I assume you mean retaining the original IR pointer for aiming, right? So you'd move on the Nunchuk, shoot/jump on B/A, maybe Morph Ball on Nunchuk C like in Prime, lock on camera on Nunchuk Z ... Concentration could either use the original motion controls or be mapped on Wiimote Minus or something, since the game doesn't use Minus anyway as far as I can tell. This is definitely an interesting one. As always, no promises, but my curiosity is piqued.
Animal Crossing: City Folk aka Let's Go to the City is the third game in Nintendo's Animal Crossing life sim series. The main addition to this entry was Wii Speak support the titular city, expanding on the small town areas of previous entries. This perhaps falls into the "controversial Wii sequel" series, with many complaints about the lack of improvements over the earlier games and the loss of NES games, since Nintendo were now selling those on the Wii Shop Channel instead of giving them away for free. Still, though not revolutionary, City Folk has the same charming atmosphere as the rest of the franchise. And at least it's a real Animal Crossing game. Cough, Amiibo Festival.
Home
Home Menu works as normal but remember to enable the pointer with L and use the correct stick for your code
Open/Close Home Button Menu
Wiimote D-Pad
D-Pad
Up: Change Camera
Left/Right: Change Tool
Down: Put Away Tool
Wiimote A
A
Confirm
Action
Wiimote B
B
Cancel
Run
Pick Up Items
Wiimote Plus
Plus
ZR
Open/Close Map
Next Tab
Wiimote Minus
X
ZL
Open/Close Inventory
Previous Tab
Wiimote 1
Minus
Take Photo
Wiimote 2
Y
Open/Close Photos
Nunchuk Analog Stick
Left Stick
Movement
Nunchuk C
Not mapped
(use A instead)
Confirm
Action
Nunchuk Z
R
Cancel
Run
Pick Up Items
Wiimote IR Pointer
L (toggle)
Left Stick or Right Stick
(depends on code used)
Move Cursor
General Notes
Two code varieties for this one, choose whichever feels more natural to you. IR aiming is pretty important to City Folk, with all inventory manipulation being IR-based. If you choose the Left Stick code, the Left Stick toggles between movement and IR input, i.e. you can't move and point at the same time. However, there's rarely any advantage to this, as there's no real multitasking possible. If you choose the Right Stick code, all you can really do is move the stupid cursor around while you run. Whee. If you want my opinion, use the Left Stick code.
Where possible, I try to "intelligently" enable/disable the pointer mode. The player can always toggle it on/off with the L button, but some other actions (opening the Inventory, Map or Photos menus) will automatically enable pointer mode for you. Try to remember to exit these menus using the same button you used to open them: e.g. you can press X to open the inventory (pointer turns on automatically) then X again to close it (pointer turns off automatically). If you instead open the menu with X then close it with B, you'll still be in pointer mode, because you didn't close with X. In this case, you should press L to disable the pointer manually. I'm trying here.
If the IR pointer movement is too fast/slow for you, you can adjust it by editing the float 0.015 (3C75C28F) about halfway through the code. You could adjust it down to 0.01 (3C23D70A) for a slower cursor, or bump it up to 0.02 (3CA3D70A) for a faster cursor, or whatever other number feels appropriate. There's plenty of hex float converters online, I linked one in a previous post somewhere.
It's worth knowing that this game supports USB keyboards. Using an on-screen keyboard with an IR pointer is sort of acceptable, but using an on-screen keyboard with a pointer you control using an analog stick is a bad time. If you have a USB keyboard handy it will hugely improve the experience if you're looking to do any typing (e.g. writing letters or chatting with other players over network play). It doesn't have to be a special Wii keyboard or anything; I use a standard PC Logitech Unifying USB dongle in my Wii. Failing that, if you use the phone in your house you can change the keyboard settings to use an old-school mobile keyboard which you might find easier to use with an analog stick.
I got a specific request (elsewhere, not in this thread) for an option where the Right Stick pointer is always enabled, but personally I think it's kind of bad. The game changes a lot of things about how it works when you're pointing at the screen, which don't make sense when playing on a traditional controller. For example, pressing A now makes you walk toward the cursor instead of interacting with whatever is in front of you. Pointing at the screen also causes the HUD to display at all times, which means the screen is cluttered with on-screen buttons the whole time you're playing. If anybody here wants this version, I guess ask for it but I find it offers an inferior experience to either of the codes above and shouldn't really be considered an equal option against those.
Changelog
v1.1 corrects the cursor speed; thanks to @RiceKryzpi for noticing this!
Technical Notes
This game has that same Super Paper Mario issue where the Home Button Menu causes a Classic Controller re-init every 64 frames. I solved it the same way, disabling getInfoAsync() from running. Thinking about it more since last time, I suspect this probably has something to do with checking things like the battery level that displays in the HBM. I do still allow getInfoAsync() to run when you first enter the HBM in both this and Paper Mario, so it's not like the HBM is running blind but if you just leave it open it might not correctly track the battery level or something pointless like that, I don't care.
Briefly, the code is: C2 to allow Classic Controller's left stick to be read for movement, C2 to disable the bad EXT error, 04 disable getInfoAsync(), C2 and C2 actually redirect analog reads to the Classic when needed, C2 custom read_kpad_dpd() (Left Stick code has an additional feature to prevent character movement while in pointer mode) and then the button injector gets inserted into KPADRead() in the last C2.
Credits
mogchamp from the AC: Wiimmfi Folk Discord for advising on the button layout
Hi! I noticed an issue: after a while of inactivity, City Folk will idle and ask you to press a button to resume. I'm unable to bypass this using this code, soft locking!
Thanks for the code! Having a wonderful time playing AC on controller!!
I've just edited the Mario Kart Wii post to add a full remapping assembly hack as I mentioned in a previous post. This hack remaps every button to the button that it already is, i.e. it does absolutely nothing by default. You can edit this any way you like and plug it into CodeWrite to get a custom button mapping.
That's awesome, congrats on the progress! Especially impressive without having any prior experience, great work. I don't really have a "generic" way to trigger motion controls across different games since they all tend to have different setups for their motion controls, so I generally have to write a different hack for each game that needs accelerometer stuff. It would be hard to really write up a tutorial on that because it's different for each game. The general idea is that inside read_kpad_acc() you need to force the game to load some specific accelerometer data instead of the real data whenever a certain button is pressed.
My usual trick for doing this is to map various accelerometer functions as buttons 0x80, 0x40 and 0x20 on the Wii Remote in the button injector. These are all unused bits on the Wiimote, i.e. technically possible button values which simply don't exist on the Wiimote. Then inside read_kpad_acc(), I'll write a routine which checks if the user pressed one of those fake buttons and load fake data in before calc_acc() (the function which processes that data) can run. calc_acc() is pretty easy to find because it always runs three times in a row, once for each axis. Before each function call will be an lfs f1, 0xXXX(r30) which is reading in the real accelerometer data, so that's the ideal place to insert some code to replace the real data.
For fixing Nunchuk errors, usually I will load the game up in Dolphin and let it run until it reaches some kind of Nunchuk error screen. Then in the Memory tab I will switch the search type to ASCII and search for the text that shows up in the Nunchuk error (e.g. "Please connect the Nunchuk to the Wii Remote" type of thing). If it is able to locate the error text, I can then set a read breakpoint (check the Read only button, then right click where the error text is located in memory and Toggle Breakpoint) on that text and find the code where the text is loaded.
From there, you want to use the Callstack in the Code tab to trace your way backward through the code trying to find where the actual Nunchuk check occurred which caused the game to display the error. I mostly do this part via trial and error, I'll go back one or two calls and set an execute breakpoint there (click in the left column of the disassembler in the Code tab) then switch to the Nunchuk in Dolphin settings and see whether that code is still running.
What you want to find is the point where different code paths are taken depending on which controller is connected. The extension types important to us are 0 (none), 1 (Nunchuk) and 2 (Classic Controller). So eventually you should reach a point where there's code which only runs if a specific value is not equal to 1. The extension check will generally look something like cmpwi rX, 0x1, but it's important to note that checking if something equals 1 is very generic code that's used all over the place, so finding a cmpwi rX, 0x1 doesn't mean you've found the Nunchuk check.
If you suspect you have found the Nunchuk check, set a breakpoint on that instruction and try letting the game run with no extension, Nunchuk and Classic Controller. If the register that gets checked matches the values I mentioned above based on which controller you have connected, you can be reasonably sure that it is checking the extension type. If that check fails (is not equal to 1), it means the current connected controller is not a Nunchuk. At that point, you can change this check to also accept Classic Controller, usually looking something like this in assembly which you can paste into CodeWrite:
Code:
cmpwi r0, 0x1
beq- RETURN
cmpwi r0, 0x2
RETURN:
This isn't doing anything too complex: instead of just checking if the value is 1, this checks if it's 1, then checks if it's 2. That way, whatever behavior the game was going to run if the extension type was 1 (like skipping over running the Nunchuk error) will also run if the extension type is 2. A lot of the exact process for how the Nunchuk is checked for varies wildly from game to game, but the extension type values are part of the SDK, so they're something reliable to look for.
Ah, yeah, that one is a bit more difficult to edit. In a couple of my early hacks I was trying to optimize the button injector down to be as small as possible by checking multiple buttons at the same time. You can see me doing that in instructions like 70A42082. This is checking buttons 0x2000, 0x80 and 0x2 (2082) all at once, so the lines like that are where your problem is occurring, since the buttons are already mapped there. In later hacks I decided to stop optimizing the button checks just so they'd be easier to edit exactly for this reason. I should come back to Excite Truck to add IR pointer support anyway, since I made that one before I knew how to do that, so if you don't mind the wait I'll "modernize" the button injector when I do that, otherwise yeah, it will be a bit tougher to change the button values.
Yeah, I think it should be possible to convert crediar's existing Metafortress fixes into IPS patches which can apply to the main.dol. I don't know what the format of gameconfig.txt files is like but I think it's just a list of patches to the binary, which is essentially what an IPS is as well. I'm definitely not sure of this though, that's just roughly how I think it works.
I think the easiest way to do this would be to edit the code yourself. It's somewhat complex for this game due to the different pointer modes, so I'll put my (and crediar's, this button injector is based on crediar's work) original assembly in a spoiler below:
Code:
; 803BF784 for USA
; 803BF9EC for USA (Rev 1)
; 803BF5D4 for EUR
; 803BF83C for EUR (Rev 1)
; 803BF928 for JPN (Rev 1)
; 803C8330 for KOR (Rev 1)
stw r0, 0x68(r31)
INJECTOR:
; held
lwz r8, 0x60(r31)
bl TRANSLATOR
lwz r6, 0x0(r31)
or r8, r8, r6
stw r8, 0x0(r31)
; released
not r8, r8
lwz r6, 0x8(r31)
and r8, r6, r8
stw r8, 0x8(r31)
; pressed
lwz r8, 0x64(r31)
bl TRANSLATOR
lwz r6, 0x4(r31)
or r8, r8, r6
stw r8, 0x4(r31)
; enable pointer
andi. r6, r8, 0x40 ; enable
beq- TOGGLE
li r6, 0x2
stb r6, 0x5E(r31)
b RETURN
TOGGLE:
; toggle pointer
andi. r6, r8, 0x80 ; toggle
beq- RETURN
lbz r6, 0x5E(r31)
xori r6, r6, 0x2
stb r6, 0x5E(r31)
b RETURN
TRANSLATOR:
li r7, 0x0
BTN_HOME:
andi. r6, r8, 0x800
beq- BTN_UP
ori r7, r7, 0x8000 ; Home
BTN_UP:
andi. r6, r8, 0x1
beq- BTN_DOWN
ori r7, r7, 0x8 ; up
BTN_DOWN:
andi. r6, r8, 0x4000
beq- BTN_LEFT
ori r7, r7, 0x4 ; down
BTN_LEFT:
andi. r6, r8, 0x2
beq- BTN_RIGHT
ori r7, r7, 0x1 ; left
BTN_RIGHT:
andi. r6, r8, 0x8000
beq- BTN_A
ori r7, r7, 0x2 ; right
BTN_A:
andi. r6, r8, 0x10
beq- BTN_B
ori r7, r7, 0x800 ; A
BTN_B:
andi. r6, r8, 0x40
beq- BTN_X
ori r7, r7, 0x400 ; B
BTN_X:
andi. r6, r8, 0x8
beq- BTN_Y
ori r7, r7, 0x1080 ; - and toggle pointer
BTN_Y:
andi. r6, r8, 0x20
beq- BTN_L
ori r7, r7, 0x180 ; 2 and toggle pointer
BTN_L:
andi. r6, r8, 0x2000
beq- BTN_R
ori r7, r7, 0x80 ; toggle pointer
BTN_R:
andi. r6, r8, 0x200
beq- BTN_ZL
ori r7, r7, 0x2000 ; Z
BTN_ZL:
andi. r6, r8, 0x80
beq- BTN_ZR
ori r7, r7, 0x1040 ; - and enable pointer
BTN_ZR:
andi. r6, r8, 0x4
beq- BTN_PLUS
ori r7, r7, 0x50 ; + and enable pointer
b BTN_PLUS
BTN_PLUS:
andi. r6, r8, 0x400
beq- BTN_MINUS
ori r7, r7, 0x90 ; + and toggle pointer
BTN_MINUS:
andi. r6, r8, 0x1000
beq- DONE
ori r7, r7, 0x200 ; 1
DONE:
mr r8, r7
blr
RETURN:
The ; comments at the start are the addresses to insert the code which you can paste into CodeWrite along with the assembly to get a Gecko code of the same, and from there you can adjust it however you see fit. I know it's pretty daunting to look at, but the parts you want to change are the lines that go ori r7, r7, 0xXXXX. They have comments after them like ; 1 to indicate what button that number means. Some of them are pressing multiple buttons simultaneously, like 0x90 means 0x80 (toggle pointer) plus 0x10 (the Wiimote Plus button).
Yeah, Fluidity does seem like a bit of a complicated one overall. I still haven't looked into it yet, but it's a game I really like, so definitely one I'll make an attempt at. Whether that will be fruitful, who knows; there's plenty of games I've looked into but haven't been successful in hacking, with those games falling onto kind of a spectrum from "I want to keep trying on that one" to "I'll die if I look at that game for one more second."
That is definitely a cool feature, but sorry, not likely to be something I can do. That would require an understanding of how each individual game handles acceleration and braking, since that's all game-specific code. Finding how it works in a one game wouldn't really help me to understand how/where vehicle movement is handled in a different game entirely. I think the case where it would be most likely to be achievable by me would be if there's games that support using the right analog stick to accelerate/brake. It would probably be possible to reconfigure the analog shoulder input to handle existing right stick accelerating/braking, and it would have to be truly analog already--unlike Mario Kart Wii where the right stick behaves like two buttons rather than the analog values being meaningful.
I'll die if I look at this game for one more second.
Epic Mickey is somehow another paint-based 3D platformer developed by a third-party which broke through Nintendo's stranglehold on the Wii. Developed exclusively for the console by Warren Spector's Junction Point Studios, Epic Mickey features the gameplay hook of an interactive world that Mickey can change at will using paint or thinner. With an RPG-influenced quest system, the player's choices also affect Mickey's appearance and skill growth. Lauded for its creative design and reimagining of Disney history, the game was also derided for its poor camera and complex controls. A recent HD remake saw much improved review scores, but ... here's this one!
There is one motion input which I did not solve here: when you simultaneously shake both the Wii Remote and Nunchuk, Mickey fires off all three Guardians (Tint/Turp spirits) at once. You won't be able to do that move with this hack; instead, you'll have to fire off all three individually using separate Nunchuk shakes (R button). It would be nice, but it's entirely playable without it.
The accelerometer in the Nunchuk is probably the single part of KPAD that I understand the least. I started looking at this game about seven weeks ago. This is the closest I've gotten to understanding how the Nunchuk works, which was just barely enough to get a generic Nunchuk waggle working.
The total number of different inputs in this game is more than the number of buttons on a Classic Controller. Epic Mickey uses 8 buttons and four motion inputs, plus the infra-red pointer. The Classic Controller has 10 buttons and a Right Stick to cover all of that. I had to sacrifice the D-Pad to get some extra inputs, hence having L+Right Stick emulate the D-Pad.
Epic Mickey already has an infamously difficult camera; losing direct camera control here would not be great, so D-Pad Left/Right are intact for lateral camera movements in addition to the L+Right Stick method. However, for looking up/down, only the L+Right Stick method is available here. This can occasionally be awkward because L is also your lock-on button when near enemies. This does mean you may have trouble moving the camera up/down when enemies are nearby, but you'll usually only need to do this during platforming segments, not combat.
Controls here are a mix of the remake and just mapping button-for-button. As mentioned, this game has a lot of inputs and mapping everything like the remake would make things like the menus completely incomprehensible (e.g. I can't really move the Plus and Minus buttons because when the game shows a button prompt in the menu it will be completely wrong and confusing). This is also why the A (confirm/jump) button is double-mapped on both A and B, so that menu and interaction prompts which want you to press A will work normally, but you still jump with B like a normal game. The one thing to be careful of is that when a prompt wants you to press B to cancel, that's ZR.
Technical Notes
Codes:
C2: bypass Nunchuk check
C2, C2 and C2 in read_kpad_acc(): Wiimote shakes and tilts; forcing the Nunchuk accelerometer to be "read" even when the extension controller type is Classic Controller; injecting fake Nunchuk accelerometer data before processing
these changes will overwrite memory where actual Classic Controller input is normally stored, so this needs to be backed up
C2 in calc_dpd_variable(): infra-red pointer emulation
04, 04 and C2 in read_kpad_ext(): redirect left stick into Nunchuk analog stick; redirect right stick into (hopefully) free memory so it isn't erased by accelerometer; right stick D-pad emulation
In what could possibly be the worst way to start October for emulation enthusiasts, as of just a few minutes ago the Ryujinx repository appears to be down, with the...
A brand new system software update has been released. Nintendo has just put out a milestone firmware release for the Nintendo Switch, bringing the OFW to 19.0.0...
It appears another "gigaleak" has gone down, involving Nintendo. According to sources online, it appears that Game Freak has been hacked, resulting in internal data...
We recently reported that Game Freak suffered a security breach which led to a huge amount of confidential data being leaked such as game source codes and internal...
The Legend of Zelda: Breath of the Wild marked a huge step for the Zelda series, taking the beloved franchise and throwing it into a new and untested open world...
As is the case for most Nintendo Switch first-party releases, Super Mario Party Jamboree has been leaked, with an XCI version of the game being spread across the...
Last week, NIntendo released a major update to their Switch firmware, with the latest now being version 19.0.0. This update brought a significant amount of changes...
A little under four years after its PC port, and PlayStation has delisted Horizon Zero Dawn. That's because Horizon Zero Dawn Remastered will soon take its place...
Mario & Luigi: Brothership has leaked online 2 weeks ahead of its 7th November street date.
Brothership is the sixth mainline installment in the Mario & Luigi...
Doom 64 has surely being one of the most underrated games from the Doom franchise, and its setting, atmosphere, cacophonies and overall foreboding and dreaded tone is...
In what could possibly be the worst way to start October for emulation enthusiasts, as of just a few minutes ago the Ryujinx repository appears to be down, with the...
A brand new system software update has been released. Nintendo has just put out a milestone firmware release for the Nintendo Switch, bringing the OFW to 19.0.0...
It appears another "gigaleak" has gone down, involving Nintendo. According to sources online, it appears that Game Freak has been hacked, resulting in internal data...
We recently reported that Game Freak suffered a security breach which led to a huge amount of confidential data being leaked such as game source codes and internal...
A little under four years after its PC port, and PlayStation has delisted Horizon Zero Dawn. That's because Horizon Zero Dawn Remastered will soon take its place...
As is the case for most Nintendo Switch first-party releases, Super Mario Party Jamboree has been leaked, with an XCI version of the game being spread across the...
Back in 2023, Analogue briefly teased their work on an upcoming "Analogue 3D" console, which was an FPGA-based reimaigining of the original Nintendo 64. Today, after...
If you have a Nintendo Switch Online subscription, Nintendo has just released a new benefit for its users. Nintendo Music is a new mobile app that allows you to...
Mario & Luigi: Brothership has leaked online 2 weeks ahead of its 7th November street date.
Brothership is the sixth mainline installment in the Mario & Luigi...
One of the few remaining games that was still trapped on the Wii U console is now escaping its entrapment and making its way to the Nintendo Switch in 2025.
Out of...
