Thanks, time to explore these boundaries.Config block 0x00030001 in the config savegame (/data/id0/sysdata/00010017)
I think the raw rtc is in the i2c registers.
With all due respect, there were certainly long-standing issues created across community GitHub repositories which ended up either closed or otherwise unresolved from not being able to pinpoint a cause, or being seemingly unrelated to Luma itself (which ended up being the case on Luma3DS's issue tracker).With all due respect, there were certainly long-standing issues created across community GitHub repositories which ended up either closed or otherwise unresolved from not being able to pinpoint a cause, or being seemingly unrelated to Luma itself (which ended up being the case on Luma3DS's issue tracker).
At the time, it wasn't consensually concluded that there would be any direct ill-effect of adjusting the RTC manually, as you can see from ihaveahax's post. In this case, it was found to be a bad practice as more information about the 3DS was discovered. You're correct that TuxSH could have raised an issue with guide developers during some point in the past, but the timeline of these events makes this point somewhat dubious, as public knowledge was still in the process of being gathered and implemented. The cause of the bug was only recently discovered to be RTC manipulation, and TuxSH independently recommended against RTC manipulation based on his knowledge while not being aware that it was the catalyst of lumabug at the time of 10.3's release.
The cause of the issue was discovered within the last six months. I admit that I am not sure what issues from the Luma3DS repo you are referring to, since I do not track it; I am mildly interested.
There's nothing wrong with wanting the best out of a community. The main takeaway is that an instance of an error that flew under the radar isn't necessarily indicative of a longstanding community management error, especially given that it's often a small group of individuals with wildly varying degrees of knowledge. The community created spaces like 3dbrew to help close this gap.
To my knowledge, most users and developers had no reason to consider their action of resetting RTC "generally improper" usage. Of course, if TuxSH did explicitly recommend against it before 10.3's release, it would partially nullify that point.
Unfortunately, this is, and will almost always be, the case for reverse engineering a device that doesn't have manufacturer documentation or decades of history. It isn't necessarily a lack of passion, or else none of this would continue to exist in 2022. What happened here can be reasonably shown to be an instance of a spoken caution that wasn't necessarily caught by everyone until issues arose.
No harm done, so no need to apologise.
Seems I may have missed them, I don't check in daily but I do know multiple issues are closed in a single day quite often so I may have missed it by the sheer quantity of the amount closed. I didn't see this on ctr-no-offset either since that has no issues posted or any closed lol.
The cause of the issue was discovered within the last six months. I admit that I am not sure what issues from the Luma3DS repo you are referring to, since I do not track it; I am mildly interested.
Here:
https://github.com/LumaTeam/Luma3DS/commit/2a947b5c4201d4e6775e6685592e9142364bbd86
More specifically:
Unless this is something separate from the issue.- Timeoffset nullification kept as a separate option for compatibility. RTC is supposed to be somehwat monotonic; using this option causes issues with SpotPass. IMHO GodMode9 should parse the cfg save file and do things *properly*