Hacking USB Loader GX

[matt!]

It would be great if the .cfg file could contain the latest GameCube .bnr download URL

http://banner.rc24.xyz/

Thanks!

 

[Cyan]

it's already done for almost a year ..... except I never released it officially on sourceforge.
look in my signature, it's on 1268mod4
replace the boot.dol on your SD. (don't worry about other files)

 

[aussiepats]

Hi cyan I am having a problem with USB loader gx. When trying to loader USB loader gx im getting this error.

 

[jeannotte]

Hello,

@aussiepats :

Is your hack up to date?

Is your loader (usb loadergx) up to date?

What is your usb support ??

If USB key, do not use usb keys, it works poorly, prefer an external hard drive for better connectivity.

 

[Cyan]

I suppose you are using r1268, so I checked your dumped memory addresses on that version.

Spoiler

Reading symbols from F:\Homebrew\Wii\USBLoaderGX\trunk\boot.elf...done.
(gdb) info line *0x80c358dc
Line 120 of "f:/Homebrew/Wii/USBLoaderGX/trunk/source/FileOperations/File.cpp" starts at address 0x80c358d4 <_ZN5CFile4seekEli+52> and ends at 0x80c358e0 <_ZN5CFile4seekEli+64>.
(gdb) info line *0x80c3a76c
Line 85 of "f:/Homebrew/Wii/USBLoaderGX/trunk/source/SoundOperations/SoundDecoder.cpp" starts at address 0x80c3a76c <_ZN12SoundDecoder6RewindEv+40>
   and ends at 0x80c3a780 <_ZN12SoundDecoder4ReadEPhii>.
(gdb) info line *0x80b6598c
Line 180 of "f:/Homebrew/Wii/USBLoaderGX/trunk/source/menu.cpp" starts at address 0x80b6598c <_Z8MainMenui+188> and ends at 0x80b659ac <_Z8MainMenui+220>.
(gdb) info line *0x80b65588
Line 54 of "f:/Homebrew/Wii/USBLoaderGX/trunk/source/main.cpp" starts at address 0x80b65588 <main+124> and ends at 0x80b6558c <main+128>.
(gdb) info line *0x80b5f990
No line number information available for address 0x80b5f990 <__crtmain+60>
(gdb) info line *0x80d06650
Line 215 of "C:/Users/davem/projects/devkitpro/libogc/libogc/lwp_threads.c" starts at address 0x80d06640 <__lwp_thread_handler+76> and ends at 0x80d06654 <__lwp_thread_handler+96>.
(gdb) info line *0x80d065f4
Line 204 of "C:/Users/davem/projects/devkitpro/libogc/libogc/lwp_threads.c" starts at address 0x80d065f4 <__lwp_thread_handler> and ends at 0x80d065fc <__lwp_thread_handler+8>.
(gdb)

What I think : it's a sound issue !
Maybe you decided to use a theme (in the loader, or a patched non official system menu maybe?), or added new sound files to be played instead of the system menu's official sound, and these files are located on USB (instead of SD, like I always suggest).
Your USB might have issue initializing fast enough, as a result the sound file can't be played when needed.

Solution :
- put all homebrew resources on SD (covers, themes, cheats, settings, etc.)
- don't use custom sound files

- or don't use a slow to initialize drive.

immediate solution : reset your settings (delete GXGlobal.cfg file, or even the entire usbloader_gx folder)

 

[morrisonian]

Hey guys, just wanted to ask about the emunand for the wii. How does that work? I mean, I've tried to find tutorials but I'm so confused about it. USB Loader GX has an option for dumping NAND, and probably want to have an emunand, but what would the benefits of having one be? Isn't it slower to load?

 

[aussiepats]

I suppose you are using r1268, so I checked your dumped memory addresses on that version.

Spoiler

Reading symbols from F:\Homebrew\Wii\USBLoaderGX\trunk\boot.elf...done.
(gdb) info line *0x80c358dc
Line 120 of "f:/Homebrew/Wii/USBLoaderGX/trunk/source/FileOperations/File.cpp" starts at address 0x80c358d4 <_ZN5CFile4seekEli+52> and ends at 0x80c358e0 <_ZN5CFile4seekEli+64>.
(gdb) info line *0x80c3a76c
Line 85 of "f:/Homebrew/Wii/USBLoaderGX/trunk/source/SoundOperations/SoundDecoder.cpp" starts at address 0x80c3a76c <_ZN12SoundDecoder6RewindEv+40>
   and ends at 0x80c3a780 <_ZN12SoundDecoder4ReadEPhii>.
(gdb) info line *0x80b6598c
Line 180 of "f:/Homebrew/Wii/USBLoaderGX/trunk/source/menu.cpp" starts at address 0x80b6598c <_Z8MainMenui+188> and ends at 0x80b659ac <_Z8MainMenui+220>.
(gdb) info line *0x80b65588
Line 54 of "f:/Homebrew/Wii/USBLoaderGX/trunk/source/main.cpp" starts at address 0x80b65588 <main+124> and ends at 0x80b6558c <main+128>.
(gdb) info line *0x80b5f990
No line number information available for address 0x80b5f990 <__crtmain+60>
(gdb) info line *0x80d06650
Line 215 of "C:/Users/davem/projects/devkitpro/libogc/libogc/lwp_threads.c" starts at address 0x80d06640 <__lwp_thread_handler+76> and ends at 0x80d06654 <__lwp_thread_handler+96>.
(gdb) info line *0x80d065f4
Line 204 of "C:/Users/davem/projects/devkitpro/libogc/libogc/lwp_threads.c" starts at address 0x80d065f4 <__lwp_thread_handler> and ends at 0x80d065fc <__lwp_thread_handler+8>.
(gdb)

What I think : it's a sound issue !
Maybe you decided to use a theme (in the loader, or a patched non official system menu maybe?), or added new sound files to be played instead of the system menu's official sound, and these files are located on USB (instead of SD, like I always suggest).
Your USB might have issue initializing fast enough, as a result the sound file can't be played when needed.

Solution :
- put all homebrew resources on SD (covers, themes, cheats, settings, etc.)
- don't use custom sound files

- or don't use a slow to initialize drive.

immediate solution : reset your settings (delete GXGlobal.cfg file, or even the entire usbloader_gx folder)

Ok so I’ve deleted the entire USB loader gx folder from the apps folder on my sd card and I’ve replaced it with the one in your signature and it’s still doing that same thing.

 

[Cyan]

do you have the official Wii system menu, or did you replaced it when following a hacking guide (for example dark menu ?).
can you try another SD card?

If it's not caused by the audio, it's crashing while trying to load the main menu, so there's something bad (maybe a bad game? or bad cover ?). But to find the problem you'll have to move or rename some folders.
for example, rename your wbfs folder to wbfs_back, create a new empty wbfs folder, so you don't have any wii games loaded at all when launching the loader.
if it works without crashing the loader, you'll know it's a wii game issue. if it still crash, try with the games folder (if you have gamecube games), etc.

if you find the problematic element, restore it (rename it back to original folder) and move half the content to another folder. try again. if it crash, it's one of the half you kept. if it works, it's in the other half. etc.

Hey guys, just wanted to ask about the emunand for the wii. How does that work? I mean, I've tried to find tutorials but I'm so confused about it. USB Loader GX has an option for dumping NAND, and probably want to have an emunand, but what would the benefits of having one be? Isn't it slower to load?

You want to learn how it works, or you want a guide to setup and use?
here is a guide I wrote : https://gbatemp.net/posts/6592730
Hope it'll help.

 

[morrisonian]

do you have the official Wii system menu, or did you replaced it when following a hacking guide (for example dark menu ?).
can you try another SD card?

If it's not caused by the audio, it's crashing while trying to load the main menu, so there's something bad (maybe a bad game? or bad cover ?). But to find the problem you'll have to move or rename some folders.
for example, rename your wbfs folder to wbfs_back, create a new empty wbfs folder, so you don't have any wii games loaded at all when launching the loader.
if it works without crashing the loader, you'll know it's a wii game issue. if it still crash, try with the games folder (if you have gamecube games), etc.

if you find the problematic element, restore it (rename it back to original folder) and move half the content to another folder. try again. if it crash, it's one of the half you kept. if it works, it's in the other half. etc.


You want to learn how it works, or you want a guide to setup and use?
here is a guide I wrote : https://gbatemp.net/posts/6592730
Hope it'll help.

I want to install it, but I'm curious on how it works? What are the benefits of having that setup? Yeah, I saw your guide and was reading, but I'm quite confused as it seems that every loader has an emunand set up? It's just that I have also a 3DS and remember having an emunand, but that was because (I suppose) it was like a safety method for not bricking real nand (but then came a9lh and b9s)... So, it was basically obsolete, but for the wii, ti seems that people use emunand more than on 3ds. Thanks a lot for the previous help!

 

[aussiepats]

@Cyan Ok I’ll try that. But this is just when there’s no hdd inserted into the USB slot it’s just by opening up USB loader gx via the forwarder channel and within homebrew.

 

[Cyan]

to know how it works, you need to know how the console works to read a disc or the files on the internal memory.

The running application don't mount the devices and don't access the file itself. Instead, it asks the IOS (which acts as bridge between software and hardware, like a driver) the file they want to access, then the IOS mount the drive, locate the file, and give it to the application.
App/game <---> IOS <---> CD/NAND

the cIOS is a patched IOS which redirect the mounted devices.
App/game <---> cIOS <---> USB/SD/CD/NAND

when you launch a Wii game from USBLoaders, the loader use the cIOS which has access to USB. when the game request a file, the cIOS take it from USB (instead of CD) and send it to the running application. the game don't know the file is from another place, it runs as if it was the original file from served by the IOS from the game Disc. the game trusts the IOS and communicate only with it, it doesn't care where the provided file comes from.

EmuNAND is working the same way.
You create a copy of your internal Wii memory content (the files and folders in the internal file system) on an SD or USB FAT32 partition, and tell the cIOS to redirect the file access request and provide another file from the external device, instead of the original internal memory, to the asking application.
it's wrongly called "emulated NAND", but it's in fact a "redirected NAND access", it's not emulated.

Most USBLoaders have that option, because it's included in the cIOS itself. It's just an option to enable or not to load (or save) files to another location than the original place.

It's slightly different than 3DS, because the 3DS emuNAND is a full binary chipset data (8GB NAND -> 8GB 1:1 exact binary data copied on a hidden partition on SD card, it's not a FAT32 but the full copy of the chipset memory, not its file system).
the wii does not require the full NAND binary as a partition, only the files stored in a folder.
Dumping a NAND File system takes about 1 minute and is easy to recreate whenever it's needed! compared to full chipset dump which takes 30min/1hour.
You can even have multiple dumped version at the same time (PAL, NTSC, Kids, Friend, etc.) and it's not tied to a specific console which means you can take your SD card 'on the go' and continue playing your own games on your friend's console.

It's also different in the sense that you don't choose to boot either the normal NAND, or the copied partition. instead, you always boot the normal NAND which has a patched IOS (the d2x cIOS you installed in softmod guides) with the added ability to serves/redirect files in real time. It's an option you choose per launched game, and not per console boot.

But the "boot into a full redirected NAND copy" mode exists too, it's what is called "neek". although it has better compatibility, it's also slower to boot and harder to setup and manage or integrate in backup loaders.
so, you have 2 different emuNAND method :
1. real time cIOS emuNAND redirection as individual option from the real NAND (like LayeredFS),
or
2. full neek emuNAND rebooted environment (like redNAND on 3DS).


The purpose of emuNAND on Wii is to :
- prevent brick on real NAND. Useful when creating and testing a new system menu theme, or installing channels which can have bad data or can be malware, bricking only the copy.
- have a lot more space to install channels and data (VC, Wiiware, savegame, etc.), up to 2TB instead of 512MB! Unline 3DS the emuNAND is not the same size than NAND. The available space is as big as the FAT32 partition. (theoretically 16TB, but currently only 2TB)

it’s just by opening up USB loader gx via the forwarder channel and within homebrew.

You don't even have the USB connected?
so it shouldn't be related to a bad game or cover as there's nothing to loads from it.
though, if you don't have a connected USB, the loader goes in "channel mode", to display Wiiware and Virtual console you have installed on your console.
so, it's possible the problem is your console's data. Not sure how you can test that without deleting games.
Edit: Maybe by using an USB ! it will not try to load the games on the console's NAND but only the USB. if it works with usb, you could do more tests.

but, if you really use r1268, then the code dump is showing it's crashing when accessing sound files.
It crashes on loading a button_click.wav file normally included in the dol. (unless you use a theme)

if you don't use r1268 then the code dump are pointing to wrong addresses. you need to provide the exact revision you are using long the code dump screenshot.

 

[morrisonian]

to know how it works, you need to know how the console works to read a disc or the files on the internal memory.

The running application don't mount the devices and don't access the file itself. Instead, it asks the IOS (which acts as bridge between software and hardware, like a driver) the file they want to access, then the IOS mount the drive, locate the file, and give it to the application.
App/game <---> IOS <---> CD/NAND

the cIOS is a patched IOS which redirect the mounted devices.
App/game <---> cIOS <---> USB/SD/CD/NAND

when you launch a Wii game from USBLoaders, the loader use the cIOS which has access to USB. when the game request a file, the cIOS take it from USB (instead of CD) and send it to the running application. the game don't know the file is from another place, it runs as if it was the original file from served by the IOS from the game Disc. the game trusts the IOS and communicate only with it, it doesn't care where the provided file comes from.

EmuNAND is working the same way.
You create a copy of your internal Wii memory content (the files and folders in the internal file system) on an SD or USB FAT32 partition, and tell the cIOS to redirect the file access request and provide another file from the external device, instead of the original internal memory, to the asking application.
it's wrongly called "emulated NAND", but it's in fact a "redirected NAND access", it's not emulated.

Most USBLoaders have that option, because it's included in the cIOS itself. It's just an option to enable or not to load (or save) files to another location than the original place.

It's slightly different than 3DS, because the 3DS emuNAND is a full binary chipset data (8GB NAND -> 8GB 1:1 exact binary data copied on a hidden partition on SD card, it's not a FAT32 but the full copy of the chipset memory, not its file system).
the wii does not require the full NAND binary as a partition, only the files stored in a folder.
Dumping a NAND File system takes about 1 minute and is easy to recreate whenever it's needed! compared to full chipset dump which takes 30min/1hour.
You can even have multiple dumped version at the same time (PAL, NTSC, Kids, Friend, etc.) and it's not tied to a specific console which means you can take your SD card 'on the go' and continue playing your own games on your friend's console.

It's also different in the sense that you don't choose to boot either the normal NAND, or the copied partition. instead, you always boot the normal NAND which has a patched IOS (the d2x cIOS you installed in softmod guides) with the added ability to serves/redirect files in real time. It's an option you choose per launched game, and not per console boot.

But the "boot into a full redirected NAND copy" mode exists too, it's what is called "neek". although it has better compatibility, it's also slower to boot and harder to setup and manage or integrate in backup loaders.
so, you have 2 different emuNAND method :
1. real time cIOS emuNAND redirection as individual option from the real NAND (like LayeredFS),
or
2. full neek emuNAND rebooted environment (like redNAND on 3DS).


The purpose of emuNAND on Wii is to :
- prevent brick on real NAND. Useful when creating and testing a new system menu theme, or installing channels which can have bad data or can be malware, bricking only the copy.
- have a lot more space to install channels and data (VC, Wiiware, savegame, etc.), up to 2TB instead of 512MB! Unline 3DS the emuNAND is not the same size than NAND. The available space is as big as the FAT32 partition. (theoretically 16TB, but currently only 2TB)

Hey thanks for the info man, I wanna install it, yeah I didn't know how people got all those channels and I was like moving them to the SD card everytime... meh. Ima give it a try, but is there like a support topic/forum/discord for this? Or just your temporary guide? I'm asking this because it's not on a separate topic? Or can I post my doubts here if I come up with a a problem? Thanks!

EDIT: Hey man, I've been reading your tutorial on how to set up emunand via usb loader gx, and managed to load emunand via usb loader by enabling the option for emunand channels just as you described on your guide. I was able also to load the emunand channels and stuff. The part where idk where to go is when I compiled the UNEEK+DI with modmii, I was able to copy the files to the USB and SD just as you said, loaded nswitch and then it stays on the screen "Reloading bootmii IOS" and the Wii starts blinking blue light on and off and tht's it. I have to force off my console to re-enter system menu. https://imgur.com/gallery/6N9kojS

What am I doing wrong?

 

[Cyan]

loaded nswitch and then it stays on the screen "Reloading bootmii IOS" and the Wii starts blinking blue light on and off and tht's it.
What am I doing wrong?

what you did wrong? you didn't follow the guide.
Where in my guide did it tell to launch neek using nswitch? (I listed it as possible method only, but told that USBLoaderGX does things differently)

here is the launch part in the guide:

USBLoaderGX is fast booting into neek, it doesn't rely on bootmii files or nswitch.

to launch neek, use USBLoaderGX.
unless you don't want to use that loader and really want to launch neek independently from any loaders, then you need to install bootmii as IOS to use nswitch, as it relies on it.
if it freezes on "reloading bootmii IOS" and you don't have bootmii IOS installed, then it can't load it...

verify you have IOS254 not stub (using syscheck), try launching bootmii from HBC (with bootmii files on the SD card).


If you have bootmii IOS, and nswitch still freeze, I don't remember what the problem is. but I know it can happen. just try launching neek from usbgx's features menu.

 

[leseratte]

Hi everyone,

I am trying to mod USB-Loader GX so that its "custom server" patch supports the new Wiimmfi patch for Mario Kart Wii which you were discussing a few posts above. I figured it would be easier for me to develop the fix for the USB-Loader when I exactly know what our patchers are doing, than for Cyan to have to analyze DOLs and figure out what we did.

Cloning the repo and trying with both devkitPPC v27 and v29-1 (which I was told by Cyan should work) I had to change a few code parts cause it didn't recognize "constexpr" in GUI/GuiBannerGrid.h, but even then, at the end, the linker failed. I am compiling (well, trying to compile) under Linux and I downloaded the relevant devkitPPC from here: https://sourceforge.net/projects/usbloadergx/files/Libraries/

linking ... boot.elf
/home/florian/devkitPro/v27-usb/portlibs/ppc/lib/libvorbisidec.a(info.o): In function `tagcompare':
info.c:(.text+0x40): undefined reference to `__locale_ctype_ptr'
info.c:(.text+0x70): undefined reference to `__locale_ctype_ptr'
info.c:(.text+0x90): undefined reference to `__locale_ctype_ptr'
/home/florian/mkw-patch/usbloadergx-code/source/libs/libfat//libcustomfat.a(directory.o): In function `_FAT_directory_entryGetAlias':
f:\Homebrew\Wii\USBLoaderGX\branches_sourceforge_svn\libs\libcustomfat\libogc\wii_release/f:/Homebrew/Wii/USBLoaderGX/branches_sourceforge_svn/libs/libcustomfat/libogc/../source/directory.c:225: undefined reference to `__locale_ctype_ptr'
f:\Homebrew\Wii\USBLoaderGX\branches_sourceforge_svn\libs\libcustomfat\libogc\wii_release/f:/Homebrew/Wii/USBLoaderGX/branches_sourceforge_svn/libs/libcustomfat/libogc/../source/directory.c:233: undefined reference to `__locale_ctype_ptr'
collect2: error: ld returned 1 exit status

Would anyone be able to help me fix this so I can start fixing the Wiimmfi patch thing in the USB-Loader?

 

[eyeliner]

Question about EmuNand:
I have made a UNEEK+DI EmuNand through ModMii, the channels I have installed appear in USBLoaderGX (paths setup ok, everything apparently correct). The region of the EmuNand is US, if that matters.

When launching a channel, the loader silently reboots to the loader. Is this a known issue, or is a matter of configuration?
I must be fair, it's my first real messing with EmuNand. The drive is formatted as FAT32, because I have GameCube games there and they load. Like Wii wbfs.

I'll possibly redo the EmuNand in ModMii again.

 

[Cyan]

@leseratte,
sorry, the link to ppc 29-1 I gave you is for windows. I don't have the linux version, and I don't think a lot of users kept old linux version of devkit toolchains.

maybe @GreyWolf would know how to fix the ctype error you get with r27. But now that I think about it, the loader used to compile fine on that version.
Maybe you could try to checkout an old revision, the wiimmfi patch was already present in previous versions. all the other dol patching sources should be the same. if you can compile an old revision you can work on it and I'll include it to the new revision later.

the loader started using ppcr29-1 on November 2017. so you can get revision 1263 and these libogc/portlib for r27.

Is this a known issue, or is a matter of configuration?

when something is wrong, it usually reboot the console.
do you have your console set to launch USBLoaderGX at boot? in that case, rebooting the loader means the console rebooted.

if it reboots, it's usually when something is missing (missing cIOS, IOS, or path to the file to load not found, device not initialized, etc.)
I can't tell what's wrong with the information you provided. try again, try to launch neek from other method (nswitch, or boot2).
is your cIOS emuNAND mode (not neek) working fine to launch installed channels ?

The drive is formatted as FAT32

which size is your drive? if it's bigger than 2TB that's your issue. GPT table format is not supported with emuNAND or Neek, you need MBR.
Drive bigger than 2TB could use MBR but not always, it will depend on its sector size.

Is the drive hidden with UStealth ? that's another reason it would reboot as it can't find it.

if Uneek is a problem due to your partition table type (GPT instead of MBR) I recommend you set the path to SD and use Sneek instead. SD are big enough to install all existing WADs at the same time so it's not a problem.

at least, even for the test, trying SD card would be a good way to know if your setup is good and working. To be sure modmii generated a proper bootable nand, etc.
Don't forget you need to generate a "Sneek" instead of "Uneek" if you place the path on SD.
note that USBLoaderGX can work with both at the same time (generate Uneek, copy to SD. Generate Sneek, copy to SD, now the loader will use the corresponding sneek folder based on emuNAND path)
if you generate Uneek with modmii, you'll have a "copy_to_SD" folder. this SD content is required for Uneek only if you don't use USBLoaderGX. (bootmii always boot SD first. nswitch > bootmii > sd > Uneek or Sneek). If you use USBLoaderGX, don't bother copying that folder to SD.

 

[eyeliner]

if it reboots, it's usually when something is missing (missing cIOS, IOS, or path to the file to load not found, device not initialized, etc.)
I can't tell what's wrong with the information you provided. try again, try to launch neek from other method (nswitch, or boot2).
is your cIOS emuNAND mode (not neek) working fine to launch installed channels ?

I am not wise to answer if something is correctly setup, because I used ModMii, and wanted to use USBLoaderGX. All I can tell you for a fact is that USBLoaderGX seems to be doing it's job perfectly, because the EmuNand channels appear.

I've used everything at default settings.

But now that you mention it, there seems to be a borked something along the way. At one point, through ModMii, I see a warning box telling that it can't find armboot.bin (if I remember correctly).

I have had some issues running the channels I had to install in my System Menu (not EmuNand).

Will have to try again with a fresh install. Thank you.

 

[Cyan]

armboot.bin is the file loaded by bootmii.
if it says it had issues creating this file when you create Uneek(2o), then you are missing a file.

But, USBLoaderGX doesn't rely on this file to boot neek, it's only used if you launch neek from nswitch channel, or nswitch homebrew.
USBloaderGX loads neek kernel directly in memory instead of asking armboot.bin file to do it.

I edited my post above, not sure if you saw it. I added possible issues.

 

[eyeliner]

Ah, I missed the edits. I'm using a 1TB drive that has given me no issues anywhere, so I'd doubt it would come from that.

But, either way, let me clarify something: this very helpful post of yours makes a copy of the system's Nand, and I used it with good results, but as everyone knows, there's that/those odd incompatible game(s).

But I'd like to install a few out-of-my-region-WADS.So I used ModMii to make a clean US NAND, with a few bells and whistles. On top of that, I installed all VC SNES titles. Every single one of those installed games on my EmuNand exists to USBLoaderGX.

That's the only problem. But, like I wrote, I'll try it all again later. I believe I've something wrong.

Also, the biggest SD available I have is 8GB. Besides, I have plenty of USB drive to share. But if all else fails, I'll stick to SD.

ModMii spits this:

==================================================
4.3U Emulated NAND created by ModMii on 13/11/2018
==================================================
setting.txt built using this serial: CUECASROTAS
Priiloader v0.7 [mod for neek2o] Installed
WiiFlow Forwarder Channel Installed
nSwitch Channel Installed
Post Loader Forwarder Channel Installed
cIOS249 rev14 Installed
NMM (No More Memory-Cards) Installed
------
Errors
------
Multi-Mod Manager (MMM) v13.4: Invalid
WiiFlow: Invalid
nSwitch: Invalid
Postloader: Invalid

 

[Cyan]

most wads work fine with the simple "cIOS Full emuNAND" mode, you don't need neek.
neek is required for very few games, mostly N64VC and rebirth games series.

did you try to set the emuNAND Channel mode to full ?
I recommend using Full as global setting in the loader, and only set neek individually to incompatible games.