some fixes: avoid black banners / minimize one usb related dsi exceptions / get custom banners / install shared content #2
Conversation
add sharedcontent installation fix to main fixes branch
w3irDv
changed the title
|
Thanks for the contribution! I'll look over this and get it tested/merged over the next couple of days. |
| // Content does not exists | ||
| return 0; | ||
| } | ||
|
|
||
| int Wad::UpdateContentMap(const char *installpath, tmd_content *content, char *filepath) | ||
| { | ||
| int result = CheckContentMap(installpath,content,filepath); | ||
| if ( result != 0 ) | ||
| return result; // content already exists or error | ||
|
|
There was a problem hiding this comment.
Since this is breaking up the Wad::CheckContentMap function in to two separate functions (which is probably a good thing), I think you will need to update all existing invocations of CheckContentMap to use UpdateContentMap, since those old calls expect CheckContentMap to do both pieces.
Not 💯 on this yet, but I'm pretty sure. Still learning my way around here.
There was a problem hiding this comment.
Hi Jacoby6000!
No, in fact the original problem was that despite its name, checkContenMap checked and always updated the content.map file without installing the shared content. The updateContentMap process should only be called once, after the shared content has been succesfully installed. The other invocations of checkContentMap only need the check stuff. The flow is explained here with a little more of detail.
There was a problem hiding this comment.
Ahhh I see. I didn't fully understand what was going on. This makes sense! I'll test it this week and get it merged
There was a problem hiding this comment.
Do you have any examples of wads with shared content so that I can validate this?
There was a problem hiding this comment.
I think any title will do.
If you want to see the bug in action, you can prepare the following lab.
Take a working emunand and delete all but one shared content:
cd ${NAND_ROOT}
mv shared1 _shared1
mkdir shared1
cp _shared1/00000000.app shared1
dd if=_shared1/content.map of=shared1/content.map bs=28 count=1
-rw-r--r-- 1 wii wii 28 Aug 1 11:18 content.map
Install any title with the old build. Check the shared1 folder. You will find no new file. But notice that the content.map file has increased in size::
-rw-r--r-- 1 wii wii 112 Aug 1 2024 content.map
USBGLX have added the hash of the shared contents included in the wad to the content.map file. The title won't load for sure. And from now on, this emunand is doomed. Any tool that checks content.map will assume that the shared content is already installed and will skip its installation.
Recreate the minimal content.map again:
dd if=_shared1/content.map of=shared1/content.map bs=28 count=1
and install the same content with the new build. content.map will have the same size (and content) than with the old build, but now shared1 folder will contain some 0000000x.app files. If you try, the installed title will (probably) load (if not, well ... we have deleted ~ 70 files or so, some unexpected behavior can happens...).
If you have access to a (physical) Wii , the real case scenario is to create a minimal emunand using modMii and then install any title with USBGLX. You will will succeed only with the new build (with the old build, installation apparently works, but the title won't load).
Or in a wii/vWii, only if you have never installed any title in the real NAND: if you export it to create and emunand, title installation will only succeed with the new build.
It's a subtle bug, which is why it has gone unnoticed for years. And I think mainly affects to new modders.
By the way, when testing this with the previous version, the DSI exception error hit me twice :D
2 participants
This PR contains some solutions to problems I've encountered using USBLGX.
Emunand related:
Other:
This fixes are already included in this PR at wiidev/usbloadergx repo.