Hacking USB Loader GX

  • Thread starter Thread starter blackb0x
  • Start date Start date
  • Views Views 8,065,725
  • Replies Replies 30,226
  • Likes Likes 74
USB Loader GX left analog stick on the Classic Controller is fucked up:



- USB Loader GX: USBLoaderGX r1268.7z
- Letterbombed US Wii with latest firmware and with HBC
- No modchip
- Original Wiimote
- Original Wii Classic Controller (first version with analog shoulders)

When moving left analog stick to the full right, it gets rollover and cursor goes to the right.

Any clues?
 
Last edited by bootsector,
  • Like
Reactions: spielvan
I've got a USB hard drive that's being picky. I have to re-initialize it after getting in to USBLGX because it doesn't detect it upon first load. Is there a setting to do a second initialize after start? Otherwise, I have to go in to the Hard Drive menu and click the first option to get it to detect each time.
 
try to set the loader's IOS to 58 to fix the drive init.
if it doesn't help, there's no shortcut to re-init the drive, only the drive menu.

bootsector: probably a calibration issue. It's done by libogc (the homebrew library), not by the loader. I don't know if there's something I can do other than editing the SDK's sources. I'll have to try.
edit: looking at the video, it seems it's due to "last position" kept in memory, you always go back to center before pushing the other direction, so maybe it's not clearing the value when set to central position. or it's calibration issue and I can't do anything.
 
Last edited by Cyan,
try to set the loader's IOS to 58 to fix the drive init.
if it doesn't help, there's no shortcut to re-init the drive, only the drive menu.

bootsector: probably a calibration issue. It's done by libogc (the homebrew library), not by the loader. I don't know if there's something I can do other than editing the SDK's sources. I'll have to try.
edit: looking at the video, it seems it's due to "last position" kept in memory, you always go back to center before pushing the other direction, so maybe it's not clearing the value when set to central position. or it's calibration issue and I can't do anything.
Thanks for looking into that!
Just to reiterate that both wiimotes and classic controllers are official ones. That issue doesn't happen in other homebrews like Wiiflow, for example.
 
  • Like
Reactions: spielvan
would you have time to test with older version of the loader ? I changed some codes related to the controller recently (and libogc also recently changed the calibration! it might be why wiiflow is working fine if you have an old version).
try 5-10 version before, something like 1260, or 1250. you have all versions on the first post.
 
would you have time to test with older version of the loader ? I changed some codes related to the controller recently (and libogc also recently changed the calibration! it might be why wiiflow is working fine if you have an old version).
try 5-10 version before, something like 1260, or 1250. you have all versions on the first post.
Tested with 1250 and I've got the same behavior.
What repo are you using to maintain USB Loader GX? Are you using latest Wii toolchain with latest libs?
 
  • Like
Reactions: spielvan
1268 was compiled using devkitPPC r29-1, libogc ... (the one which was released at that time).
but if it's also acting this way on old version (compiled with PPC R27 and libogc 8.12?) then it's another issue. I don't have time to look at it.

repo is on first post (I think)
 
Tested with 1250 and I've got the same behavior.
What repo are you using to maintain USB Loader GX? Are you using latest Wii toolchain with latest libs?

I'm not able to reproduce this with my Classic Controller Pro, either on r1268 or my working copy that's upgraded to libogc 1.8.20. Are you sure it's an official controller and do you have another one to test? Analog value overruns like that are generally consistent with non-Nintendo controllers.
 
I'm not able to reproduce this with my Classic Controller Pro, either on r1268 or my working copy that's upgraded to libogc 1.8.20. Are you sure it's an official controller and do you have another one to test? Analog value overruns like that are generally consistent with non-Nintendo controllers.
Yes, it's definetly an official first model Classic Controller.
Looking at the source code, the issue seems to be inside the GuiTrigger::WPAD_Stick() function (inside gui_trigger.cpp), as it doesn't make sense to me to use "mag" and "ang" values for a Wii Classic Controller, as it doesn't provide those. In this case, it looks like "mag" is turning negative for some reason, screwing the direction of the cursor. I can't confirm that though, as I don't have a functional wii toolchain handy.
 
  • Like
Reactions: spielvan
Analog sticks generally use a vector and magnitude/angle to calculate speed and direction of movement. If it was the code I would assume my controllers wouldn't work right, either.
 
Analog sticks generally use a vector and magnitude/angle to calculate speed and direction of movement. If it was the code I would assume my controllers wouldn't work right, either.

The interesting thing is that the problem only occurs when moving the analog to the sides, it is giving a type of pulls in the hand of the remote to the left side of the screen, when moving the little one up and down the screen does not ocrre any type of bug . Tested with USB LOADER GX versions 1250, 1262, 1268.
 
The interesting thing is that the problem only occurs when moving the analog to the sides, it is giving a type of pulls in the hand of the remote to the left side of the screen, when moving the little one up and down the screen does not ocrre any type of bug . Tested with USB LOADER GX versions 1250, 1262, 1268.

With the same controller? It's very possible it's out of tolerance and sending bad data. As I said, I tested it with an official CC Pro and it doesn't do it. Reversing directions like that generally is a clamping error or the pots are sending values over the voltage they're supposed to and it's getting turned into a negative value.
 
Is the only way to get USB Loader GX to show and play Triforce games from the list through Quadforce, or is Nintendont supported now?

The reason I ask is because my Triforce games show up fine and play under Nintendont, but under UBS Loader GX, all I can see are my Gamecube and Wii games (as per my settings).

EDIT: I just rescanned for game covers and now my games show up in the list...

F-Zero is now Strikers 2002 and both Mario Karts are known as Sample Game Name.

How do I resolve this?


EDIT 2: Different ISO's worked fine. Paradise!
 
Last edited by XDel,
I have found another issue and this one does not seem to be a fault of my own.

In the loader I have it set to store all box art on the USB drive. In fact I do not have anything related to USB Loader GX on the SD. Yet if I load it with the SD in the slot, it will not display all the box art I downloaded, and if I try to re-download it, it comes up with a ton of art that it can not find, specifically for the Gamecube, which it suddenly thinks are Wii games (according to the generic box art it auto provides).

Oh, and if the SD is in the Wii, then USB Loader GX also presumes that Nintendont is only to be found on the SD.

If I start USB Loader Gx without an SD in the slot, all my art work shows up as it should, and most download as they should.

EDIT: I just noticed that USB Loader GX creates it's own directory in the apps folder on the SD card during all of this.

EDIT 2: Discovered the "config" folder on the SD. Deleted it and all is well.
 
Last edited by XDel,
I am having the strangest problem on my physical Wii. I got everything setup and had Gamecube, Wii and WiiWare from Emunand loading perfectly in USB Loader GX. I found some WiiWare games that wouldn't with the "Full" emunand and so I installed neek2o via MiiMod. So everything was working great, most WiiWare games launched with plain old Emunand and few booted up from neek2o. Then all of a sudden, and I mean I can't think of one thing I changed, no WiiWare games would boot with "Full" emunand. You would launch them and you would immediately be back in the loader (I had return to USB Loader GX set). I was 100% perplexed. I even went as far as deleting my emunand and started from scratch (redump and reinstall of all my wads), but the problem still persists. Any ideas?
 
I have found another issue and this one does not seem to be a fault of my own.
it's still your fault. you are not using the loader the way it should.

the loader uses SD card in priority.
if you set any path to USB while not having an SD inserted, and insert an SD card, it will re-create/use the config file located on SD card (priority, remember?).
if you want to have USB Path when both SD is inserted and not inserted, you'll have to have 2 copy of the config, one on SD when SD is inserted, one of USB when SD is not inserted.

anyway.... You shouldn't use resources on USB. It's a fast way to corrupt your partition, especially if you use 2 USB at the same time. even more dangerous if you insert/eject a device (usb or sd) while the loader is running.
having resources on USB is a very bad idea, USB should be only for ISO or ROMs, not homebrew's data.
you should dedicate an SD card for every console you use, SD are cheap, and it's working better.

I even went as far as deleting my emunand and started from scratch (redump and reinstall of all my wads), but the problem still persists. Any ideas?
that's what I was about to suggest.
it was possible using neek2o corrupted the file system used by emuNAND cIOS mode, because both modes are not using and affecting the system files the same way.
but recreating a clean new emuNAND dump should have fix the issue.

if the problem persist, it looks like the problem is the cIOS, not the NAND dump's file system.
did you verify you are using proper cIOS base/version and loader's options?
 
Last edited by Cyan,
I changed game ios from 249 to 250 and that seemed to fix the problem. When I installed them I installed
  • cIOS 249 base 56 v10 beta52
  • cIOS 250 base 57 v10 beta52
Maybe something got messed up with 249?

--------------------- MERGED ---------------------------

reinstalling 249 fixed the problem. Thanks for making think to even check that possibility!
 
it's still your fault. you are not using the loader the way it should.

the loader uses SD card in priority.
if you set any path to USB while not having an SD inserted, and insert an SD card, it will re-create/use the config file located on SD card (priority, remember?).
if you want to have USB Path when both SD is inserted and not inserted, you'll have to have 2 copy of the config, one on SD when SD is inserted, one of USB when SD is not inserted.

anyway.... You shouldn't use resources on USB. It's a fast way to corrupt your partition, especially if you use 2 USB at the same time. even more dangerous if you insert/eject a device (usb or sd) while the loader is running.
having resources on USB is a very bad idea, USB should be only for ISO or ROMs, not homebrew's data.
you should dedicate an SD card for every console you use, SD are cheap, and it's working better.


that's what I was about to suggest.
it was possible using neek2o corrupted the file system used by emuNAND cIOS mode, because both modes are not using and affecting the system files the same way.
but recreating a clean new emuNAND dump should have fix the issue.

if the problem persist, it looks like the problem is the cIOS, not the NAND dump's file system.
did you verify you are using proper cIOS base/version and loader's options?


Yes, finish reading, I worked it all out in the end, though thanks for the heads up about the SD priority.
 
If I don't have partitions on my HDD does it mind to have the app in the HDD? Or it is still recommended to have it in the SD?
Some apps checks for the stuff in the same place the app is (SD or USB), that's why I have all my apps and games in the same HDD.
 

Site & Scene News

Popular threads in this forum