Hacking Unofficial Luma build discussion

[BETA215]

@Nutez Do you think it would be possible to include some filters like those of AGB_edit? They'd be useful to simulate GBC colors.

That would be work for someone who works on the GBC emu/VC injects. Luma doesn't has anything to do with it.

Also, agb_edit can't do any color corrections like you show on those pics. You can only remove RGB channels and mess with the gamma/brightness - besides other features that won't help in these regards.

 

[Feffe]

That would be work for someone who works on the GBC emu/VC injects. Luma doesn't has anything to do with it.

What I meant was, is a global filter simulating those colors possible? Of course, it would have little use outside a GBC game!

Thanks for educating me on AGB_Edit.

 

[BETA215]

What I meant was, is a global filter simulating those colors possible? Of course, it would have little use outside a GBC game!

Thanks for educating me on AGB_Edit.

If you want to play GBC games with the correct colors, there's the retroarch_3dsx Gambatte core. Enable color correction and it'll look like you want
That feature you're asking for, could actually help people make their console's screens show more accurate colors - 3DS screens can look pretty different from each other.

 

[Darthagnon]

Luma official has had an update to v11. I wish they could incorporate the changes from this version into the main branch; I managed to get the "No LED" function working, and it's great at night!

 

[DracoMan671]

We just have to wait for now

 

[BETA215]

Luma official has had an update to v11. I wish they could incorporate the changes from this version into the main branch; I managed to get the "No LED" function working, and it's great at night!

That, and comment out the part of the code that automatically copies your boot.firm to the CTRNAND, a new mandatory 'feature' on latest official Luma release. That would be sick uwu

 

[Darthagnon]

That, and comment out the part of the code that automatically copies your boot.firm to the CTRNAND, a new mandatory 'feature' on latest official Luma release. That would be sick uwu

Is it an anti-feature? I'm a PSP guy, only recently into 3DS hacking, and if I remember didn't 3ds.guide instructions tell us to do something to install the CFW to NAND?

 

[lone_wolf323]

Is it an anti-feature? I'm a PSP guy, only recently into 3DS hacking, and if I remember didn't 3ds.guide instructions tell us to do something to install the CFW to NAND?

No. its a feature that allows for having the console boot if there is ever a time the sd card becomes unreadable or if a sd card is not present.

 

[Darthagnon]

No. its a feature that allows for having the console boot if there is ever a time the sd card becomes unreadable or if a sd card is not present.

Isn't it the step normally done via Godmode9 >> >> gm9megascript >> Plailect's guide >> setup Luma3DS to sysnand? (https://3ds.hacks.guide/finalizing-setup#section-vi---ctrnand-luma3ds)

 

[lone_wolf323]

Isn't it the step normally done via Godmode9 >> >> gm9megascript >> Plailect's guide >> setup Luma3DS to sysnand? (https://3ds.hacks.guide/finalizing-setup#section-vi---ctrnand-luma3ds)

Before this. it was a fully manaul step. and a lot of times it was overlooked or just outright skipped. Ive seen a lot of people here whining their consoles no longer work when the sd card faults or is removed for a different electronics device.

 

[BETA215]

Before this. it was a fully manaul step. and a lot of times it was overlooked or just outright skipped. Ive seen a lot of people here whining their consoles no longer work when the sd card faults or is removed for a different electronics device.

I think the feature would be amazing if implemented in a better way, like:
Asking if you want to copy it to CTRNAND or not, before doing it.
Checking if boot.firm is actually a Luma firm and not something else, or checking how the firm that's being booted is actually called in case it has a different name. fastboot3DS exists, and not acknowledging it will only bring more issues - why ignoring that there are different bootloaders out there.

In the actual implementation, it's just more of an issue than a solution to lots of us. That's why its removal in this fork would be pretty useful

 

[lilyuwuu]

I think the feature would be amazing if implemented in a better way, like:
Asking if you want to copy it to CTRNAND or not, before doing it.
Checking if boot.firm is actually a Luma firm and not something else, or checking how the firm that's being booted is actually called in case it has a different name. fastboot3DS exists, and not acknowledging it will only bring more issues - why ignoring that there are different bootloaders out there.

In the actual implementation, it's just more of an issue than a solution to lots of us. That's why its removal in this fork would be pretty useful

An opt-in prompt would be good in a perfect world, but unfortunately we live in a society where people will:
- ask whether they should enable this option or not even if the guide very explicitly says to say yes to the prompt
- accidentally say no to the prompt and ask how to enable the prompt
- accidentally say no to the prompt and not ask how to enable the prompt
- purposely say no to the prompt even when the guide says otherwise

...All of which would defeat the purpose of the feature, which is to ensure that each and every user has Luma on CTRNAND so that they can boot without an SD card.

Ultimately, power users (including basically every fastboot3DS user) know how to swap boot.firm on CTRNAND on their own (also note that Luma will only make itself CTRNAND boot.firm *once* per Luma version—any further swaps will be unimpeded). Obviously a fork is free to do whatever it wants (and it may actually be a good idea since the fork may be more frequently updated with new features than base Luma). But hopefully you do understand why it's a feature.

Based on this comment it's logistically difficult to add it to config because config is often reset.

 

[Hark0n]

I think the feature would be amazing if implemented in a better way, like:
Asking if you want to copy it to CTRNAND or not, before doing it.
Checking if boot.firm is actually a Luma firm and not something else, or checking how the firm that's being booted is actually called in case it has a different name. fastboot3DS exists, and not acknowledging it will only bring more issues - why ignoring that there are different bootloaders out there.

In the actual implementation, it's just more of an issue than a solution to lots of us. That's why its removal in this fork would be pretty useful

Could you elaborate on that? I am using Fastboot3Ds and Luma v11.0 together without any issue whatsoever... am I missing something here?

 

[pistonfish]

Could you elaborate on that? I am using Fastboot3Ds and Luma v11.0 together without any issue whatsoever... am I missing something here?

Imagine having different Luma versions on your SD and having fastboot set up to use them. Now Luma could install itself to the CTRNAND everytime you boot into another version

 

[Hark0n]

Imagine having different Luma versions on your SD and having fastboot set up to use them. Now Luma could install itself to the CTRNAND everytime you boot into another version

So you suggest that in the future one could have Luma v.11.1, v11.2 and v11.3 and Luma 11.3 with Night/Light and Quick-Switchers (for example) on his/her SD card and every time he/she boots one of them it would write itself into CTRNAND (after recognizing a different version in the NAND) thus wearing it out? But why would I have different Luma versions on my SD? That seems like a very niche scenario to me.

 

[pistonfish]

So you suggest that in the future one could have Luma v.11.1, v11.2 and v11.3 and Luma 11.3 with Night/Light and Quick-Switchers (for example) on his/her SD card and every time he/she boots one of them it would write itself into CTRNAND (after recognizing a different version in the NAND) thus wearing it out? But why would I have different Luma versions on my SD? That seems like a very niche scenario to me.

There are unofficial builds with other features. What if you want to use a feature that is only implemented by a build based of an outdated version. In that case it might be viable for you to change between the official/newest version and the other one.

The problem not only lies in unnecessary writes to the sd card but also in the control over which version is installed on your CTRNAND

 

[Hark0n]

There are unofficial builds with other features. What if you want to use a feature that is only implemented by a build based of an outdated version. In that case it might be viable for you to change between the official/newest version and the other one.

The problem not only lies in unnecessary writes to the sd card but also in the control over which version is installed on your CTRNAND

I see... but to be honest, this one seems to me the most feature complete one out there. I don't see a reason why you would need another one, what feature could possibly be missing?

 

[ghjfdtg]

Luma is not even checking what it copies to nand let alone verifying the file is bootable. Imagine your boot.firm is not Luma but something else or it's corrupt and you didn't notice. Luma will now copy this file without asking you and without any checks which will eventually cause issues. The fact Luma knows which file path it has been booted from but still insisting on the "boot.firm" file name makes this even worse of a design choice.

 

[lilyuwuu]

Luma is not even checking what it copies to nand let alone verifying the file is bootable. Imagine your boot.firm is not Luma but something else or it's corrupt and you didn't notice. Luma will now copy this file without asking you and without any checks which will eventually cause issues. The fact Luma knows which file path it has been booted from but still insisting on the "boot.firm" file name makes this even worse of a design choice.

I can't think of a scenario where this would happen to someone who doesn't know what they're doing. Everyone with a "standard" guide-based setup won't ever have anything other than Luma as boot.firm (except maybe SafeB9SInstaller if updating B9S, which doesn't chainload anywhere anyway). If you are in a scenario where you're booting Luma from SD from a location other than as boot.firm, you're probably more likely to not have boot.firm in the first place, but more importantly you would be able to recognize if something is going weird (not to mention booting without SD with fastboot3DS would bring up its configuration IIRC rather than power off (now with notification LED colour) like B9S does).

There are unofficial builds with other features. What if you want to use a feature that is only implemented by a build based of an outdated version. In that case it might be viable for you to change between the official/newest version and the other one.

The problem not only lies in unnecessary writes to the sd card but also in the control over which version is installed on your CTRNAND

SD writes aren't really relevant here. Luma is already known to sometimes have conflicting config if you're switching between old and new versions (maybe even forks if they have different config?), which has nothing to do with the CTRNAND copy feature. The CTRNAND writes are IMO negligible compared to both what the 3DS writes and to what a power user would be writing.

As far as I can tell, Luma will only attempt to write itself once per version (not entirely sure in what way forks are implicated this, but it seems to be implied here that if you run base Luma first then forks will not attempt to write boot.firm to CTRNAND).

---

The feature is ultimately to ensure that each and every person is able to boot on CTRNAND. If you're a casual fork user, you probably don't care what CTRNAND boot.firm is - the critical factor is whether your 3DS can boot if your SD failed for some reason, and whether you use a fork or not doesn't really matter in that case.

I don't personally take issue with a fork like this one removing this feature because 99% of the time the people that the feature targets (people that don't really know what they're doing) will only ever run and use base Luma (or maybe 3GX Luma, but either way they'd have a working Luma as boot.firm on CTRNAND). But the portrayal of the feature as generally anti-user bugs me a bit. An inconvenience to very specific types of power users, maybe (if the forks end up fighting each other to make themselves CTRNAND boot.firm).

 

[Hark0n]

I can't think of a scenario where this would happen to someone who doesn't know what they're doing. Everyone with a "standard" guide-based setup won't ever have anything other than Luma as boot.firm (except maybe SafeB9SInstaller if updating B9S, which doesn't chainload anywhere anyway). If you are in a scenario where you're booting Luma from SD from a location other than as boot.firm, you're probably more likely to not have boot.firm in the first place, but more importantly you would be able to recognize if something is going weird (not to mention booting without SD with fastboot3DS would bring up its configuration IIRC rather than power off (now with notification LED colour) like B9S does).


SD writes aren't really relevant here. Luma is already known to sometimes have conflicting config if you're switching between old and new versions (maybe even forks if they have different config?), which has nothing to do with the CTRNAND copy feature. The CTRNAND writes are IMO negligible compared to both what the 3DS writes and to what a power user would be writing.

As far as I can tell, Luma will only attempt to write itself once per version (not entirely sure in what way forks are implicated this, but it seems to be implied here that if you run base Luma first then forks will not attempt to write boot.firm to CTRNAND).

---

The feature is ultimately to ensure that each and every person is able to boot on CTRNAND. If you're a casual fork user, you probably don't care what CTRNAND boot.firm is - the critical factor is whether your 3DS can boot if your SD failed for some reason, and whether you use a fork or not doesn't really matter in that case.

I don't personally take issue with a fork like this one removing this feature because 99% of the time the people that the feature targets (people that don't really know what they're doing) will only ever run and use base Luma (or maybe 3GX Luma, but either way they'd have a working Luma as boot.firm on CTRNAND). But the portrayal of the feature as generally anti-user bugs me a bit. An inconvenience to very specific types of power users, maybe (if the forks end up fighting each other to make themselves CTRNAND boot.firm).

My thoughts exactly... the vaaast majority of normal users does benefit from this change. I consider myself a somewhat average user (I mainly use fastboot3ds because it makes open_agb more usable for me) and I can't come up with a scenario where I would have more than one boot.firm on my SD, and if said boot.firm were corrupted, would it even be able to boot? Wouldn't in that case the boot.firm on the CTRNAND be booted instead?