The power button on your wii u remote or the console itself are the only ways I know. Kind of more convenient than a menu item tbh., since its on the controller. Power button on classic controller works too, at least on my PowerA.
It's console specific, so it means absolutely nothing that it's been dumped other than that it's possible to dump it
Well sorry but this comment is just uncalled for in my opinion. I was looking at the wut project earlier and really though it was a cool thing that exjam started there and I saw your contributions on there which were also great. So the first thing I wanted to do is change HBL to use the RPX format and load RPX homebrews instead, as RPX brings a few imporntant features with it in code size (e.g. zlib compression). I also though of contributing to that project if I see something thats of use. Seeing this comment made me remember how developers are ranting down code of other developers on the wii u scene instead of working together. This makes me wonder if it is worth to invest more time into such a community. I didn't want to say anything to this point in public but well...I did look deeper into wut and several parts of it and especially the GX2 part look almost like a 1:1 copy of SDK. Even the enums, variables and also the file structure of headers look alike. Don't tell me it's "coincident". That is just hypocritical. I really wonder what gave you the impression that my stuff, which does not look this alike, is derived of the SDK and this one is not. What I liked the most was this part here though:
. Fyi this is not very "legal". I wouldn't be surprised if the devoptab code would also be derived of my devoptab code for the sd access. At least that one looks different and is a bit improved so thats great and that's what it really should be about and not ranting at each other. So if your mind is not fully set on being a "nazi like anti backup loader creator" person like some people (marca...cought), I would like to rather put those things aside, work together and preferably talk directly in a chat instead through posts (which usually are only missleading or missunderstood).Now this comment is something I agree on a lot more. People should try to target creating RPX files. Creating a HBL version as a RPX application which loads other RPX is not much of work especially as there is code available for loading RPX files on loadiine which can be adapted to load homebrews RPX. Though the old way with ELF file is not bad and you can do (almost) everything an RPX can do as well (multitasking and so on), it would be more future proof to create RPX files which can later be installed in custom channels once that's possible.
This one looks really nice. The UI does not have to be that much abstracted away from the graphics but for me its better understandable in an object oriented way and if the API changes its easier to switch if you abstracted those parts. It doesn't have to be this way for others. Using TGA is though quite inefficient in size matters and there are examples in several of my applications how to simply use one interface with a few basic libs for all image formats that matter including tga. You dont even need be a C++ programmer to be able to move it into C as it is basically all procedural in there. But yeah, its not really necessary as the WiiU got enough memory for an application usually i guess.
Yeah, basically anything that wasn't an Ancast key or Common Key
It's another case of miscommunication, I tend to agree, work way better in C than C++ even tho almost all the Wii U stuff I've poked at is in C++, both 1st party and 3rd party stuff
don't think so, they only really cared about the common and ancast stuff too cause it has the broadest use (aside from storage keys but those are console specific), it was technically public if you saved my screenie from forever ago but again, the public keys are the big ones like the common keys to decrypt NUS stuff, the rest is mostly just for research
That's a dump question to ask.
the NAND? Yeah, that's mostly what the whole 64GB minimum thing for emuNAND was about (I don't think that's the case anymore), cause 8/32GB eMMC + 512MB x2 NAND (vWii + WiiU) is just barely over the 32GB card limit, I haven't had contact with SALT in a while so I dunno how much more progress there is tho, the exploit can access it just fine tho and emuNAND's working off of an SD copy
I think I already asked, but why can't we load from USB/HDD?
I thought @WulfyStylez commented something about this but I can't find it, basically IOS-MCP keeps access to all UHS communications so any node that tries to use it will fail, no idea the reason, MN1 (rip) posted this forever ago but it's the only thing I could find
shrug, this says Teensy2.0++ and a python script can dump it, @shinyquagsire23 put it in so go poke them
yep I read through those threads, from what I saw they haven't been able to from what I surmised. I imagine smealum had to do something because he had a nand mod. I wonder if he posted how he did it.
The classes you made in HBL and Loadiine helped tremendously in getting GX2 and sound working, and it's a shame that more people haven't used any of it. It may be that C++ is too intimidating to others, IDK. As far as porting emulators, I would always run into some problem when trying to port things, very few things would port nicely. However, building things from scratch has been much more successful for me, although I haven't been doing anything Wii U related for the past month or so. You, and just a handful of other good devs, that are positive and helpful and sharing were the only thing that kept my drive going before. I just wish more devs were like you or them.
