if the project owners really care about open source, portability and readability, why don't they comment their code? the patches in particular contain hardcoded addresses and such, and there's no way in finding out about their purpose without having to acquire and reverse engineer memory dumps or firmware images from a 3ds model that you do not happen to have yourself. if the code was commented and explained, there could be n3ds compatibility in no time.
That will come, slowly.
Slowly. We have features to implement, and bugs to fix. If you need something answered quickly come join us in the IRC channel.uh huh

Something not totally related. Please checkout what i said in your repo. You should use pull requests instead of just pushing commits. The repo is for more than one.--Snips--
Might I ask what the difference between collaborators pushing code directly and using a pull request is?Please checkout what i said in your repo. You should use pull requests instead of just pushing commits. The repo is for more than one.

Yes it would take an extras step, and with one additional commit. I admit that. I have several reasons:Might I ask what the difference between collaborators pushing code directly and using a pull request is?
The only discernible changes would be:
Thus, I ask you: Wherefore?
- Pushing a commit now takes an extra step.
- Every commit now would be accompanied by an additional commit stating it originated from a pull request.
Wait, so it's possible to downgrade the system settings on the original 3DS? :o
Since when was this possible?
Also, do I need a different file from the one for the new 3ds?
GitHub uses the same merge conflict detection feature as git itself does. If a pull request can get merged, it'll get merged the same way git would merge it in. No one in their right mind would force push conflicting commits. A PR would conflict just as much; the same people would have to resolve the conflict during a PR as they would during a regular push.1. If the repo isn't owned by only one, modifications done to the same file, may cause conflicts (for pulls) or overriden (pushing). if conflicts are solved, commits could be merged.
Valid point, though it's exceedingly unlikely that mid-kid cares to introduce formal code reviews in a scene product hacked on for fun rather than out of obligation to corporations.2. It gives other an opportunity for reviewing it. At the time you may get some suggestions, which helps you develop better.
If anything, that's a missing feature in github's code, though that's a kind of valid point for people who really want to live on the bleeding edge, I guess? There's a bot in #cakey that reports commits if you need to be informed of them in real time.3. Simply Github would not generates notifications for just commits, and it does generate for those pull requests. Even i'm Watching it, since they just push, i don't get any news.
That's already being done on the IRC channel. I can't really blame you for not wanting to sit on the shithole that is Freenode, but with a small team, real-time collaboration like that is arguably preferable.4. We may discuss about if something should be done in that way.
citra iterates considerably more slowly, however, and has a more professional goal, though that's debatable.It doesn't matter if the repo keeps having just several ones who are always in contact, really. Still i would like the way citra on github.
Yes it would take an extras step, and with one additional commit. I admit that. I have several reasons:
1. If the repo isn't owned by only one, modifications done to the same file, may cause conflicts (for pulls) or overriden (pushing). if conflicts are solved, commits could be merged.
2. It gives other an opportunity for reviewing it. At the time you may get some suggestions, which helps you develop better.
3. Simply Github would not generates notifications for just commits, and it does generate for those pull requests. Even i'm Watching it, since they just push, i don't get any news.
4. We may discuss about if something should be done in that way.
It doesn't matter if the repo keeps having just several ones who are always in contact, really. Still i would like the way citra on github.
Juste change the name of "launcher.dat" in "cake.dat" in setting !Is it possible to have the necessary files to launch CakesCFW using an android phone like gateway or rxtools?
I have got a 2DS and i already use it for gateway and rxtools.
Thanks
I compiled the latest sources and it's the same as previous versions: with Spider all I get is a bottom screen with garbled graphics on a 2DS v7.2.0-17E (the firmkey.bin has the correct MD5).

Downgrading the system settings app to re-enable the MSET exploit was first discovered and demonstrated (at least publicly) earlier this year by the SALT team (by either @shinyquagsire23 or @WulfyStylez). Some time later Gateway used the discovery to re-enable MSET launching on new3DSes with their 2.3 update.Wait, so it's possible to downgrade the system settings on the original 3DS? :o
Since when was this possible?
Also, do I need a different file from the one for the new 3ds?
That one was found by Wulfy and worked on by her and Daz. I think I was busy with school at the time. But yeah, we did the ROP for that, got our stuff working through it and showed a video. Gateway's release doing the same thing followed.Downgrading the system settings app to re-enable the MSET exploit was first discovered and demonstrated (at least publicly) earlier this year by the SALT team (by either @shinyquagsire23 or @WulfyStylez). Some time later Gateway used the discovery to re-enable MSET launching on new3DSes with their 2.3 update.