Separate names with a comma.
Discussion in '3DS - Homebrew Development and Emulators' started by d0k3, Mar 22, 2016.
Why does the screen get so dark when using GM9? Is there a way to disable that?
Well, the brightness is controlled by the volume slider by default, so, make sure that's all the way up. This feature can be disabled when compiling. Just place "FIXED_BRIGHTNESS=15" on the make line and it will always be at maximum brightness (i.e. "make SALTMODE=1 FIXED_BRIGHTNESS=15"). If you find that setting too bright, try again with a lower number like 10 or 12.
Sorry for my poor ability to understand English.
To prevent misunderstanding, asking.
What did you mean on Github?
Alright, just a quick note, regarding radio silence. Once you have looked it over, get back, and I'll have another thorough look through the changes.
What means "it"?
What should I do at "get back"?
Did you mean you are thinking to limit my acceses to your repo?
I just meant, tell me once you think the pull request is ready (which includes you having tested it yourself). I'll keep an eye on the pull request, but I may miss it otherwise.
I think the PR has no more bugs.
For changing label format to @label, see here. is it ok?
This allows whitespaces between '@' and the label name.
If there are some whitespaces there, handle it by standard command(I changed "label" as command name to "@")
If not, handle it in parse_line().
It will show "Invalid label format" error with like "@label something".
So, you actually did test yourself? I need to check the pull request when I have an hour or two free, so I'll still need a bit tiem until I do so.
I found a bug (fixed), sorry. Please wait more.
This is an amazing file browser. I used it to install FBI when I forgot to put it on my o3DS. Love your work man. Keep it up!
You're confusing me with all these branches. Is the label command going to be "label" or ":" or "@" now? I kind of like the ":" idea being used to DOS and Windows more than Linux. But if "@" is the Linux standard, then that's probably what it should use, I guess, with most of the rest of the commands being Linux-based. Also, that latest fix is only on the original "if-goto" branch atm.
sh and bash have no "goto" commands. csh and tcsh have them and the format is ":"
But must be going to "@"
1) @d0k3 is thinking to change the format to "@"
2) I don't think GM9 will have many more control commands, so we must use "goto" a lot and "@" is easier to know it's a label than ":" at the end.
3) "@" allows whitespaces between "@" and the label name.(see below) but allowing that with ":" makes source code dirty, because ":" will be at the end of a label name and we can't handle ":" as a standard command so must handle both in "parse_line()".
If there are some whitespaces there, handle it by standard command(I changed "label" as a command name to "@")
If not, handle it in parse_line() specially.
I finished testing it. Please look at my PR.
I been pulling off asking this but is possible to remap the buttons (my 3ds has a broken r button)
If I want to install the godmode9 bootlader I install it using Safeb9sinstaller right?
@d0k3: Is the latest commit supposed to give an error and not build if you leave the data folder empty? It did that when I removed the key databse to create a "no keys" build. Nothing a zero byte file can't fix, though. Also, "README.md" still gets included in the vfat0.tar when "AUTORUN_SCRIPT=1" is specified, even though obviously no one can read it. Though that's also nothing a zero byte file can't fix, naturally. Also, you forgot to mention the key file's name has changed to "aeskey.db" in the "README.md" file. Or is that a typo in the "vram0.h" file? You also didn't add "V:" to the portion of the "README.md" file that lists all of the drives.
Also, what is the correct method for specifying a different output filename? I'm getting the distinct impression you don't want people to change the FLAVOR variable in Makefile.common, based on the number of errors that generates. Total Commander has a mass renamer, but it would be nice if my SSRs had the right name when built.
Those issues aside, I like the new TAR method you're using to handle external data files. The VRAM0 image file getting generated and mounted automatically? Awesome. Less work for me, now that I've actually found a use for it (creating menus with zero byte files). And the SSRs generated by this new restructuring are much smaller. Thanks for these great new features.
Nope. Safe B9S Installer can't install GM9. You can either install it to the FIRM partitions manually using GM9, or use the "Sighax Updater" SSR I provide with InScripted (iso site, CFW Discussions section, or max site, A9LH & Custom Firmware Discussion section). I've also provided a lite version in the ReiNAND thread, since it benefits people using that the most (they can have ReiNAND as "boot.firm" and still have a chainloader now, after all).
First of all: Sorry that took so long. I have now taken (and squashed) your commits in my ifelse branch. I'm still doing the reviewing and I may make some minor edits, but things are looking good. I may also get back about some stuff I can't figure out.
Edit the hid.h file and recompile - no way around this.
Install it with GodMode9 itself - that's the easiest way to do it.
Ooops about the aeskey.db thing - I need to fix that. No rename intended. An empty data folder is also not intended to stop the build - will look into that, too. You're not entirely correct about the README.md not being readable. You just can't show it as textfile, but it sits there, in the V:/ drive. Guess I'll have to look into that, too, though. Thanks for pointing all that stuff out!
I'm not against changing the FLAVOR. The name of the splash screen file depends on it, though. That's the only possible issue I can name of the top of my head.
It was a pretty big change to the Makefile, so the remaining issues don't come fully unexpected. Most of it will get sorted out, though. And yes, this should make providing additional files a lot easier than the previous bin2o method.
Okay, @Kazuma77 - the latest commit should fix most, if not all of the annoyances you just pointed out.
I have a request. An undo combo. You should be able to undo actions, probably up to about 5 actions ago. I could especially use it after I accidentally deleted my title folder in SysNand SD. I'd be fine if the action undo cache is cleared on reboot, as long as you can undo. Preferably also a redo.
Also, a question. Where does GM9 get the System Info (in Home...More...System Info) from?
Undo cache is completely out of question. Operations in GM9 are much too complex to allow something like that. Even if we'd only do it for base operations like delete, copy, move, etc... you know that would require recycle bin management? Don't delete stuff you don't want to delete is the answer. GM9 even asks you if you really want to continue.
Also, that info... well, it comes from various places. Have a look at the source code to learn more, I guess.
Hmm, I see. That's too bad.
Well, deleting the titles folder was an accident. I was trying to delete a different folder, but I must have not payed attention and entered the unlock combo.
(FEATURE REQUEST) You should make the unlock combos randomized, but if the randomly generated combo doesn't have 3 or more buttons, retry, etc., or randomly select from a list of premade, secure unlock combos.
Finally, longer combos. At least, for more dangerous operations.
I can't remember the current number of inputs for a combo, so I'll just say it's 4 (not including A at end)
Yellow: 4 inputs + A
Orange: 5 inputs + A
Red: 6 inputs + X + A
Blue: 5 inputs + X + A
SD: same as yellow
This would be nice.
If you implement it, devs can always use EixMode9.
Or, add a NOFAILSAFE = 1 in Makefile to use older, 4-input combos.
Just an idea.
If you don't want to spend time creating safe combos, I'd be happy to make a list, divided into Yellow/Orange/Red/Blue sections.
Random combos I agree with, but increasing the length - that will not achieve what you think it will. Unlock combos are there so you have to pause for a moment and perhaps overthink what you're about to do. Randomly entering an unlock sequence is already impossible, and there already is the color coding of permission levels. If you decided what you're doing is alright, an 8 button sequence will not stop you anymore than a 5 button sequence will. Random unlock sequences help in that they force you to actually pay attention and not just use your muscle memory - thus I'll add that to my list.
Besides, GM9's handling of write permissions is already pretty smart, and you see those unlock combination really only when there is no choice. In typical user's usage: basically never.
Also, a quick note. The blue permission level can be more dangerous than the red one, given you do the right modifications, so don't underestimate it. Red -> easy to do something stupid, medium bad consequences, Blue -> hard to do something stupid, very bad consequences.