Include Wiimmfi patch v1 in hacks_hash.ini

[Leseratte10]

Here are the necessary changes to the hacks_hash.ini for Wiimmfi patcher support.

This includes patches for 4.1, 4.2 and 4.3, in all four regions (PAL, USA, JAP, KOR) each, plus patches for the PAL and NTSC versions of the Wii Mini 4.3. I didn't bother porting it to the four vWii versions because Priiloader doesn't run on there anyways; if Priiloader will ever run on vWii in the future I'll add these ports. Also I didn't bother porting it to 4.0 or below. If people still have a 4.0 or lower Wii in 2020, they should just update to 4.1 or newer.

This has been tested for PAL and USA discs, still needs some testers with JAP and KOR discs / consoles.

A couple things:

• This patch patches all games for Wiimmfi that use the nintendowifi.net URLs. That probably includes the few Wii games that use their own online servers that are still up, these games probably won't be able to connect to their servers with this hack enabled.
• The patch should work with Mario Kart Wii and the special patches required for that game, but it should also work with any other game supported by Wiimmfi.
• ~This patch requires the code changes from the Hacks_rework branch to be merged into master first before this will work.~ (already merged)

~Also, with that patch added the layout of the "Hacks" screen looks pretty bad, the "confirm" button overlays the last two hacks. I'd recommend either adding a way to scroll through that list, or to drop two of the rarely-used hacks from the hacks_hash.ini for the next release.~ (already fixed in master)

[Fullmetal5]

I just got the blackscreen when booting issue again. Here's what is in the log. 3:16:41 : BootState:255 3:16:41 : Bootstate 255 detected. DiscState 2 ,ReturnTo 0 & Flags 0 & checksum 16712192 3:16:41 : Input_Init():1

Shit, that's probably because of r |= KEYBOARD_Init(HandleKBDEvent); in Input_Init, it's probably better to only care about the error from KEYBOARD_Init when deciding to launch the keyboard thread. I'll make a pull request to fix.

how so? ye ok, the thread shouldn't start if KB couldn't init, but it shouldn't cause a random crash, shouldn't it? imo that sounds like a crash always or never crash scenario? (depending on hardware setup)

Yeah, it shouldn't be a random crash, it's just that I'm not sure how stable the usb+keyboard stack really is in libogc so if there's an error I'm not sure that KEYBOARD_GetEvent will handle it gracefully (although looking at the source it should). Also it actually doesn't look like KEYBOARD_Init was failing from the log because KEYBOARD_Init can only return negative numbers so the return value couldn't have been 1, it must have been from PAD_Init or WPAD_Init. That still doesn't explain why priiloader was freezing for them though.

[Fullmetal5]

Seems it only happens when I have a USB plugged in during boot.

What usb device were you plugging in to cause this freeze? If you could please post the exact model number and everything of the device.

[fancythedeveloper]

Pretty sure it's like a USB 2.0 SD-USB hub-like adapter with a SDHC card plugged into the SD card slot.

[DacoTaco]

i just remembered that that is a known issue. some USB devices (SD card readers being one of them) give libogc/the cpu a really hard time. i don't know why.

that issue can be reproduced on 0.8 as well (i just tested it)

as for the hart of this PR : are the hacks considered stable and working? can a PR be done ? (this is a draft PR)

[Leseratte10]

No, they still fail for non-PAL games, but I didn't have time yet to fix that. I'll convert the draft PR to a normal PR when the hacks all work.

[Leseratte10]

@DacoTaco I just started working on this again, and I remembered you asking in a comment somewhere if it was possible to only have one instance of the long patching code instead of one for each version. Is that still something you'd want to have?

Code-wise for the patch it wouldn't be that difficult to have one huge patch for all regions, and then multiple small patches that take care of the region-dependant stuff.

However, for the user, I'd rather have that patch in a way that doesn't require the user to do things like enabling a "Wiimmfi generic patch" plus a "Wiimmfi additonal patch for 4.3E" in order to use that hack, because that will only lead to confusion and more bug reports of people who only select one of the hacks.

One idea I had would be to add another parameter (like "master=X") to the hacks. That "master=X" with X being a numeric value would then cause this particular hack to be completely invisible in the hacks display list, but other hacks could then have a parameter like "require=X" with the same value to indicate that that master hack has to be enabled automatically.

That way we could have one large hack with the majority of the Wiimmfi patch, with master=1, that will be completely hidden from the user and not displayed in the hacks menu, then multiple small hacks (one for each system menu version) with require=1 that are shown to the user, and whenever the user enables one of the hacks that are labelled "require=1", the Priiloader would need to go through all the hidden hacks, find the one that has "master=1", and then enable that one in the background, too.

That would allow me to write one master hack with most of the patches, multiple small ones that take care of version differences, but the user would still only need to enable one hack to enable that functionality - the small version difference hack, which would in turn automatically enable the master hack.

Would that be something you could add? Or do you prefer we keep the current solution with the whole hack being included 14 times?

[fancythedeveloper]

That sounds like a good idea!

[DacoTaco]

though the idea is good, it comes with a lot of technical difficulties and hurdles. what if the number you have in master exists for multiple hacks? which one do you keep? what about all its 'sub' hacks? what if master exists but no 'sub' hack was added? if master has a hack that needs a 'sub' hack then everything can go to shit.

and thats just functional problems, i don't even know how i would write that code & still scale well. Would it still run ok on the wii without any slowdowns with a large hacks file (cause every hack being added to the list would go over all previous hacks and verify the things i mentioned and more)?

personally i'd prefer the hacks to be split up in 2 and the user will need to figure it out but its also true that we can't fully trust an user to do that correctly ( even though 90% is following a guide ) ...

if the hack was small i'd say 1 hack per SM version is good, but having the code in there makes it huge and would increase its file size & parsing time.

heads up btw, ill be making a 0.9 Beta 1 build later and put it online. but its a beta, so there is still room to discuss and change things afterwards. we need to discuss & think of a way to make this work, cause i want to release a stable, non beta, 0.9 with this patch :)

[Leseratte10]

I'd say, given that most people will probably use the hacks_hash.ini from the repository / the release and not put together a custom one, worrying about collisions is probably not important. One could also use a text string like "wiimmfi" as identifier, instead of a number.

Also, given that there are only like 30 hacks and not 10000, performance-wise it probably wouldn't matter at all. But I agree that there might be some pitfalls to watch out for. But one could just ignore the hack and write an error to the log if there are any conflicts. I'd really like if there was just one entry for the patch, but I also agree that having the whole patch in there takes quite a bit of space.

I also thought about making the whole patch region-independant (which would increase the patch size by a bit, but still way less than 13 copies of the patch), but that would only work for the main patch, not the single branch instruction so that doesn't work.

Maybe I'll look at the hacks code in the next couple days and see if I find an easy way to implement something like that.

For the 0.9 beta 1, yeah, that's fine. Just don't include this draft pull request in the beta yet. Then we might get more people to test all the new Priiloader code, maybe even on Wii Mini, and then we can add the Wiimmfi patch (and maybe that feature for the combined hacks if I figure out a good way) in the 0.9 release when it's done.

[DacoTaco]

i just opened your patch together with the v514 boot app ( 4.3E ) and took a look at what its doing. so if i understand correctly, your code is in 0x812ff000 ( just before SM ) and it patches 0x8137c094 ( which seems to 0x4C5B4 in the file, and is a mr r5, r26 instruction?) to jump to 0x812ff000 ? also, is that piece youre patching important? if not, you could move the 812ff000 address into a register and branch to it. that way youre no longer stuck to the relative branch instruction.

EDIT : nvm, i just took a look at the EU & US binaries. thats an annoying spot to patch. it contains a few relative branches that are different per region. having a absolute branch would mean nothing changes.

what does that code in SM do anyway? why is the patch needed in that specific spot?

note for my own reference : US v513 : 8137bfec - 0x4C50C EU v514 : 8137c094 - 0x4C5B4

[Leseratte10]

Yes, that is exactly what I am doing. And yes, the code at that address is important, that's why my custom code has a "mr r5, r26" instruction at the very end, right before I branch back, so that the instruction I replaced is executed anyways.

I have no frickin clue what exactly that code in the system menu does - all I know is that that place of code runs shortly after the game DOL is loaded into memory, and shortly before the system menu starts executing the game DOL. So it's the perfect place to insert code to patch the game.

The function this patch is in is called "BS2StartGame" (and is responsible for booting disc-based games), while the function that is called right after my patch is "LaunchTitle" which then does some more cleanup and branches to the game's code.

I already started rewriting parts of my code to be more region-independant, but even if I did add a register branch, there would still be the problem - how should my code branch back to the original location + 4 to continue execution? It would need to know the fixed offset.

I started implementing the master hack / slave hacks concept in my hack itself, and that would bring the hacks size down from 88 kB to 10 kB, so that would be a significant decrease in size. Now I'd only need to find a way to tell Priiloader that each of these slave hacks require the master hack to be enabled...

[DacoTaco]

it wouldn't need to know where it came from. thats what the lr register is for. it keeps track of where it came from. so if you save and restore it like i do in the loader, then you can return to the code where you came from. but ye, having an absolute branch is useless if you still need to have a separate patch to place it (i was looking into if a hash patch is possible , but its not)

i'll also be looking into a few things/options

[Leseratte10]

Oh, right, forgot about that. Yeah, I could do a bl / bctrl call to get rid of having to know where to return to, but I'd still need an offset patch to set the branch.

Just tested my split hack and it seems to work on PAL 4.3E, and I also hopefully fixed the problem with non-PAL games (not commited yet). So next step will be, I'll start looking into the Priiloader to hopefully find an easy way to make the sub hacks automatically enable the master hack, too.

[DacoTaco]

first off all, am i correct in thinking the patch only works with disc based games? its just that in dolphin, my breakpoint wouldn't hit with wiiware games, only disc i also have no idea what im doing at this point, as i have no idea what that piece of code of system menu is doing..

i also took a look at the branching and code. there seems to be a piece of code, 2 instructions further that is unique in system menu 4.3 with EU & US (didn't check the others yet). however, by that point it has set a few machine state registers, so i think its to late? you did say its just before jumping to the disc's dol

i don't know how much control you have over your code and the use of registers , but i suggest a test if you want.

in 4.3E patch 0x8137c09c to jump to your code. then you either save the content of r3, don't touch r3, or you do a mr 31,3 (and don't use r31 again) which moves the content of r3 into r31. this looked to be zeroes, but you never know. does the patch work then? it's just that im not sure what it does in the branch to 0x815be1b4 , but trying it in dolphin resulted in some crashes.

i won't be home later today, but im going to think the whole master & require through. i don't like it one bit but...

[Leseratte10]

Yes, you are correct, the current patch only works with disc-based games. I might add WiiWare support in the future, but that can be considered an issue for a future version and I don't plan on having that ready for 0.9.

I cannot use the address 0x8137c09c to install my branch, as I believe the function call above it (to 815be1b4 in 4.3E) is what actually starts the game, and all the code after it is for error cases. But even if I could, what would be the point? That still doesn't let me use a bctrl patch.

I just opened #238 which is a draft PR adding master / slave support. It's not that much additional code, maybe you can look at that and tell me what you think of it?

[Leseratte10]

I now have versions of the Wiimmfi patch hacks that should fix the non-PAL issues, making it work with all regions, but I was unable to test that yet (I don't have non-PAL discs). Depending on if #238 gets merged or not, I'll either commit the full version to this PR (88 kb) or the new master/slave version (10 kb).

[Leseratte10]

Now that #238 has been merged, I will add the latest version of the Wiimmfi patches to this PR later today or tomorrow, so that they can be tested in the different regions again.

[Leseratte10]

I just pushed the updated Wiimmfi patcher hack. This requires the recently merged #238, so it doesn't work with the released beta yet. This should make the Wiimmfi patch work in other regions, too.

Also, I re-ordered the hacks in the ini file a bit, making it so that most-used hacks like "Block disc updates" are at the top, and rarely-used hacks like "No delete HAXX, DVDX, ..." are at the bottom.

Also, I changed the maxversion on a couple of hacks (block disc update, auto-press A on health screen, move Disc channel) that should work on Wii Mini, too.

[fancythedeveloper]

Also, since we're talking about hacks, can the No Copy hack be effective in forward and back copying, no just copying to the SD card?

[Leseratte10]

Doesn't that already work? It just requires you to already have a savegame for that game on your Wii. Anyways, that's probably not something I'll be looking into, I would need to look into how exactly that hack works, and that's not going to be easy.

Also, looks like the wiimmfi patch (again) is broken for non-MKWii. stupid compiler didn't warn me about an undefined jump target ...

[DacoTaco]

give me heads up when its patched, then i can update the hacks file in the pre-release

[Leseratte10]

@DacoTaco here's the new patch. Works with other games now, still needs to be tested in regions other than PAL

[DacoTaco]

ive updated the hacks in the pre-release

[fancythedeveloper]

What does SUB FOR 513 mean? Does it mean it doesn't work on v513, which iirc is 4.3U?

[Leseratte10]

No, it means that the hack (you are seeing) is the sub hack for 513, meaning it is the hack that works on v513 (and all the other hacks for the other versions have been hiddden). I agree that the naming is confusing, and I'll rename the hacks prior to releasing.

But as of now there apparently still is a bug with non-PAL MKWii games (but at least other non-PAL games seem to work now) which I need to find and fix.

[Leseratte10]

Tested this version on Dolphin with 4.1U and an NTSC image; can't test online play in Dolphin but it no longer freezes on the strap screen so at least it works better than before.

Also I renamed the hacks to remove the confusing "sub" term.

[fancythedeveloper]

Ok, I'll test soon!

[Leseratte10]

Aaaand yet another fix. I was able to test this in Dolphin with 4.1U and an USA disc and that now gets online as well.

[Leseratte10]

USA has been confirmed working by other people, too. I'll try to test JAP and KOR in Dolphin on the weekend.

[fancythedeveloper]

I'm assuming you fixed MKWii crashing while connecting?

[Leseratte10]

Yeah, at least for PAL and USA. I wasn't able to test JAP and KOR yet.

[DacoTaco]

@Leseratte10 : how extensive has the patch been tested? are you waiting for something before making the PR not a draft?

[Leseratte10]

This still hasn't been tested with japanese and korean versions. PokeAcer wanted to send me NANDs from his japanese and korean wiis so I can at least test it in Dolphin, but he hasn't done that yet.

[Leseratte10]

Finally some progress, a test with a japanese NAND and game was also successful. Just waiting for the Korean NAND, I'm hoping that I'll be able to test that today or tomorrow, too; and once that's confirmed working as well this can finally be merged and released.

[Leseratte10]

Korea seems to work as well. Didn't test JAP and KOR extensively, but they all get online. Worst case, if these is some bug left in the patch, we can always bring an update.

I'd say this is now ready to be merged (finally) -> converting from Draft PR to real PR.

[Leseratte10]

Just rebased this on the recent master so that the merge conflict is gone.

[Leseratte10]

Is there anything that's still needed to get this merged, or can this be merged now and put into 0.9? From my side this patch should be finished and it has been tested in all four regions.

[Leseratte10]

Thanks for merging. Looking forward to seeing this in Priiloader 0.9 when it's released.

[Debs305]

Hi, I recently got Priiloader's latest beta and whenever i enable the wiimmfi patch, It gets stuck on the screen where it tells me to put on the Wii remote strap, which I believe isn't normal and Leseratte even said that that's not supposed to happen. Im on version 4.3U, disc region USA and have offset 0x812ff030, It says Wiimmfi patch sub for 513.

[DacoTaco]

and with the exact same setup, but the hack disabled it doesn't show this? does it show the message in the game or system menu?

[Debs305]

It doesn't give me a message, it just simply gets stuck on that screen, disabling the patch starts the game normally, but obviously tries to connect to the actual Nintendo WFC.

[DacoTaco]

this is an issue in the patch then, and not priiloader itself. @Leseratte10 , do you have time to look into this issue?

[Debs305]

Alright, I also told Leseratte in the MrBean35000vr Discord server and i sent him information such as the offset, system version, etc, but i don't think he's seen it yet.

[Leseratte10]

I saw that, and I will look into that. Could take a while though as I am currently working on other stuff. I'll let both of you know when I find the issue.

[Debs305]

No worries, take your time.

[Leseratte10]

@Debs305 when the game crashes, can you trigger the exception handler (by pressing Up, 1, Down, 2, Right, -, Left, +, B, A on the first Wiimote in that order) or does the Wiimote disconnect?

If you can see the exception handler can you take a photo of that, please?

[Debs305]

Nothing happens, the remote doesn't disconnect nor it shows anything on the screen. It's a regular Wii remote, not the one that has motion plus built in,

[Leseratte10]

Okay, I just took a 4.3U NAND with the new Priiloader installed, with the Wiimmfi 513 hack enabled and threw that into Dolphin, and I was able to load an NTSC-U image of the game through the system menu and then go online, so the patch itself must be working.

Do you have any other hacks enabled that could cause the patch to fail? Does the disc itself work normally, meaning, does it work when you start the game without the Priiloader patch?

[Debs305]

The only things I have set to ON in the "System Menu Hacks" setting is to block disc updates, block online updates, and the Wiimmfi patch. The game starts normally with the setting OFF, however, Super Smash Brawl with the setting to ON, starts normally and can connect to Wiimmfi. But Mario Kart Wii is freezing on the screen where it asks to put on the wrist strap.

[Debs305]

UPDATE: I turned off the setting to block disc updates and block online updates and the issue still persists.