It locks itself when there is not a "proper" B9S environment on the target payload (ex. Gateway).
Luma just clears caches and jumps to the payload, exact same as B9S (and GM9!) do. It's the payload's fault if it makes unsafe assumptions about its environment.
OK. It's not that big of a deal making a separate copy, I guess. If it had to be done, better sooner than later. I'm glad you did it before I released R6. "One & Done" does use OldLoader after all.
I didn't actually test it to see if it ran. I just noticed the .bin was bigger and assumed something got truncated by mistake. It was one of my "One & Done" installers so that 313K really stood out against the other 335K SSRs.
Try running Cakes. Observe how it crashes. Then try launching Cakes from GodMode9 launched from Luma. Observer how it still crashes. Then try launching Cakes from BootCTR9. Observe that it works. Switch back to Luma and run Cakes again. Now it works. And it doesn't matter if the firmware is already decrypted or not. It still does it the first time you run Cakes on a new card. Sometimes it will start crashing again if you switch firmwares, and sometimes you can switch firmwares and it will be fine. I'm no developer, but that definitely seems like good evidence of instability to me. GM9 doesn't setup it's own environment (when chainloaded anyway). For testing to be accurate, it is important to eliminate outside factors. If you're not using GM9 as a firm for your tests, you should at least be running it from BootCTR9, since it provides a known good environment. Otherwise, you can't rule out the possibility that it is Luma's chainloader causing the problem.
Don't get me wrong. Luma's CFW is great. It's just that it's chainloader is bug-infested unstable garbage that should be discontinued (much like how Windows 7 is good, but the Internet Explorer bundled with it is garbage). And far be it from me to report these bugs. It's a waste of their time as far as I'm concerned, since I'm never going to use it anyway. We have dedicated chainloaders like BootCTR9 and CBM9 that do their one thing well (and GM9 already has it soundly beat in the "installed as a firm" department -- Luma offers nothing over running it from B9S). The "store brand" just needs to die already. It's only a distraction for the Luma devs. I'd much rather see them focus on useful new innovations than reinvent the wheel.
Last edited by Kazuma77,
Or, you could have it give an error message at the end, pointing to the broken file, so you'd still know if something went wrong.
@jaspern seriously needs to find out what's wrong, and for that we got the verify function, with verbose output. Better he finds out this way than, well, just showing a summary that may be ignored.
Good point, someone might miss it. I hadn't thought of that.
A cool new feature would be an image viewer and maybe even basic editor (photo images, not nand/fat/disc images). Although, I suppose it wouldn't be that useful.
Maybe what you're asking is something different, but I think what he means it's just quite buggy. I've never experienced any problems with it, but that may just be because I'm not a dev.
Any world bigger than Luma and GodMode9. It can't run Cakes right. It can't run Gateway, Puma33DS, AGBSave9, or any other payload you want to convert. It's the rxTools of chainloaders. I explained in great detail how wonky it is in the paragraph previous to the one you quoted. Maybe you should read it. I admit though, I'm no developer. Whether one developer royally screwed up, or 3 went the extra mile, isn't something I could easily discern. If you're the only one not going that extra mile, it makes you look just as bad, regardless.
But let's get back on topic. The point was running GM9 in a clean manner so you can tell if a problem is actually with GM9 or not. I guess if you want to be completely scientific about it, I should say, try it in two different chainloaders just to make sure. It's not like any of them are immune to bugs. It's just that the others seem to have far less.
Last edited by Kazuma77,
I'm sorry that you are stuck in early-mid 2016 and wish to use a dead cfw, a meme, another meme (from what I understand), and an ancient tool. These """bugs""" are likely not lumas fault as it is not designed to correctly load bootleg a9lh converted firms. If you still believe that this is a bug and that I am wrong, stop bitching in the gm9 thread and make a proper issue on github.
Cakes is not a "bootleg a9lh converted firm" as you call it. Version 200 just came out in August and it is a proper .firm file. Furthermore, this is not the Luma3DS thread, so, please stop derailing the GM9 thread with your zealotry and go worship it in the proper place. And as I said, I don't use the chainloader. It's not in my interest to have them fix something I will never use for anything but testing purposes (unless they add a "default" setting, and we both know that's not happening).
P.S. Shall I report you for that clone account? I'd recognize your typing style anywhere... astronautlevel. How many do you have?
Last edited by Kazuma77,
I'm just eating popcorn from the sidelines here - I'm sorry that sn0w and I have similar typing styles. But sn0w has been around on Temp longer than I have, and you can check on the nintendo homebrew discord yourself - we are very much seperate people. Since you called me into this, I might as well respond...
As far as I know, the version of Cakes released (200) is a Brahma payload converted with firmtool. I could be entirely, 100% wrong - but that's just what I remember. Does it work as boot.firm on b9s?
@Shadowhand: Thanks for that commit. I like this new mode. It's good to see you actively involved in the scene again. @d0k3: I actually liked the green text. It kind-of had that "Matrix" vibe. Though I guess white on black is easier to read. Oh well, I don't really use the text viewer that much anyway. Though if I forgot to mention it before, thanks for the quick fix for the "shaget" command. That was fast. The script works great now.
I would send this via PM to avoid further derailment, but it won't let me PM you for some reason. Maybe you had the sn0w account first, then you decided to create this one so you could win arguments and give yourself likes. Look, I have no reason to trust you, nor any desire to discuss anything with you after what happened in the Luma thread. Please, just don't reply to me ever again.
I will answer this one last question from you, and that is it. Yes, Cakes does work as boot.firm. Unfortunately, booting is not proof that something isn't an "-e 0" build (aka conversion) though. CBM9 is "converted" after all. OperationNT414C straight up told me as much when I asked him how to build it. When I tried it, not only did it boot, but Luma had no problems running it, either (that shocked me). I'll check the make file. Well, looks like it is an "-e 0" conversion. Though it's built from the .elf file, not the .bin, so, you were half right.
Here's the thing though. There's three chainloaders that run most "converted" payloads, and one that crashes with most of them. Ironically, that one is co-developed by the very person who gave us firmtool in the first place, and should therefore arguably be leading the pack in backward compatibility. And yet most of them crash? And you expect people to think what? That your chainloader is superior because it crashes when you run an "improper" conversion? No, they're going to think it sucks because it crashes, and everything else doesn't. Regardless, since TuxSH made firmtool, if a conversion is improper, it's still on you guys. If you don't want to fix it, just drop it. We've got 3 good ones. Why waste your time?
I would send this via PM to avoid further derailment, but it won't let me PM you for some reason. Maybe you had the sn0w account first, then you decided to create this one so you could win arguments and give yourself likes. Look, I have no reason to trust you, nor any desire to discuss anything with you after what happened in the Luma thread. Please, just don't reply to me ever again.
I will answer this one last question from you, and that is it. Yes, Cakes does work as boot.firm. Unfortunately, booting is not proof that something isn't an "-e 0" build (aka conversion) though. CBM9 is "converted" after all. OperationNT414C straight up told me as much when I asked him how to build it. When I tried it, not only did it boot, but Luma had no problems running it, either (that shocked me). I'll check the make file. Well, looks like it is an "-e 0" conversion. Though it's built from the .elf file, not the .bin, so, you were half right.
Here's the thing though. There's three chainloaders that run most "converted" payloads, and one that crashes with most of them. Ironically, that one is co-developed by the very person who gave us firmtool in the first place, and should therefore arguably be leading the pack in backward compatibility. And yet most of them crash? And you expect people to think what? That your chainloader is superior because it crashes when you run an "improper" conversion? No, they're going to think it sucks because it crashes, and everything else doesn't. Regardless, since TuxSH made firmtool, if a conversion is improper, it's still on you guys. If you don't want to fix it, just drop it. We've got 3 good ones. Why waste your time?
Last edited by Kazuma77,
I added "unzip" command to extract non-compressed zip file.but it may have some bugs so before make pullreq, released as beta.
USE THIS AT YOUR OWN RISK
RELEASE:
https://github.com/windows-server-2003/GodMode9/releases/tag/1.4.2-unzip
This release has some issues so please wait for pullreq and the official release
1) archive is extractable from script but cannot via the file handle menu yet
2) currentry, if content already exists, auto skip but should ask like copying or moving files
3) most important : source code is very dirty. cannot read !
USE THIS AT YOUR OWN RISK
RELEASE:
https://github.com/windows-server-2003/GodMode9/releases/tag/1.4.2-unzip
This release has some issues so please wait for pullreq and the official release
1) archive is extractable from script but cannot via the file handle menu yet
2) currentry, if content already exists, auto skip but should ask like copying or moving files
3) most important : source code is very dirty. cannot read !
Backwards compatibility? They're not nintendo lol
adapt or go die, don't keep on using outdated stuff. If you really want to, update it yourself to be proper
Next you'll say they should still support a9lh payloads directly
Last edited by LiquidFenrir,
True. And it's a feature I make much more use of. At least while I'm developing the script. I do tend to disable previews on the final release, though. The way I see it, seeing and reading error and success messages that don't apply and aren't being triggered could potentially confuse users as to what is going on. Though it makes adding more error messages key, so you know where a script messed up when someone reports a problem.
Interesting. I can see this speeding up NTRBootHax swap card installs significantly, since everything can be copied to RAM as one big file. Though it would complicate the initial setup of the card, since the configurations would have to be archived. Still, I can implement it both ways, and just let the end user decide which way they want to do it. I'd actually like to see this WITH compression. Though I guess it's not like I'm going to fit all the Doom wads and Quake paks into the RAM drive no matter what (well, maybe all of the Doom wads, but, there wouldn't be much room left for apps).
Oh noes, it's not proper! People are going to be bringing their 3DSes back to me left and right now demanding a refund!
No one cares. They just want things to work. With BootCTR9, everything does. Enough said.Let's see. A Luma dev provides a conversion tool that does "improper" conversions, then refuses to run them because they're improper, but no one can make "proper" ones because the tool won't do it. That's a catch 22.
If you think I need to adapt, check out my InScripted AIO. It will completely redefine the word for you. You can switch hotkeys, default payload, chainloader, Sighax firm, boot firm, or even your exploit via scripts.
This "not our problem" attitude will ultimately lead to another fork replacing Luma, just as they replaced ReiNAND because the developer decided the O3DS wasn't their problem. Well, enjoy your reply. I won't feed you again.
True. And it's a feature I make much more use of. At least while I'm developing the script. I do tend to disable previews on the final release, though. The way I see it, seeing and reading error and success messages that don't apply and aren't being triggered could potentially confuse users as to what is going on. Though it makes adding more error messages key, so you know where a script messed up when someone reports a problem.
Interesting. I can see this speeding up NTRBootHax swap card installs significantly, since everything can be copied to RAM as one big file. Though it would complicate the initial setup of the card, since the configurations would have to be archived. Still, I can implement it both ways, and just let the end user decide which way they want to do it. I'd actually like to see this WITH compression. Though I guess it's not like I'm going to fit all the Doom wads and Quake paks into the RAM drive no matter what (well, maybe all of the Doom wads, but, there wouldn't be much room left for apps).
Oh noes, it's not proper! People are going to be bringing their 3DSes back to me left and right now demanding a refund!
Let's see. A Luma dev provides a conversion tool that does "improper" conversions, then refuses to run them because they're improper, but no one can make "proper" ones because the tool won't do it. That's a catch 22.
If you think I need to adapt, check out my InScripted AIO. It will completely redefine the word for you. You can switch hotkeys, default payload, chainloader, Sighax firm, boot firm, or even your exploit via scripts.
This "not our problem" attitude will ultimately lead to another fork replacing Luma, just as they replaced ReiNAND because the developer decided the O3DS wasn't their problem. Well, enjoy your reply. I won't feed you again.
Heh I wouldn't say Luma replaced ReiNAND, at least not for me.
But... actually, I think setup won't be so fast because extraction also takes time.
I'm thinking about self extractable archive, but there is a problem.
The script must be an text file!
If there is no limitation about that, we can use "inject" (for making zip file from script file) and "unzip" to self extract. It will need just one file to setup. It is useful.
Similar threads
-
@
Sicklyboy:
@SylverReZ, Oh yeah, arguably doing better than ever. They're releasing new sets constantly for it+1 -
-
-
@
SylverReZ:
Nice. I wish they bought back collectable figurines in blind bags, which I had as a kid. -
@
Sicklyboy:
I like buying the Halo Megablox blind bags every once in a while when I see them. Scratches that itch
-
-
-
@
hitorikuroi:
i have a question currently my atmos switch isnt picked up by pc on HOS but the cable and port do work with apx and tegra so i know the hardware is good, any clue? -
-
-
-
-
-
-
@
Psionic Roshambo:
Well on a good day life does suck... lol on a bad day it just sucks differently lol+3 -
-
-
-
-
-
@
BakerMan:
it's just in an empty open space, like outside at night or the backrooms, depending on the branch of the hypothetical you either feel unsafe, but you actually are safe, or you feel safe, but are unsafe, also you don't actually know the truth about your safety either way -
-
-
-