Homebrew Official [Release] GodMode9 - All Access File Browser for the 3DS

[Kazuma77]

@Kazuma77 - just because I remembered just now - it's not a good idea to provide zero sized splashes. The decompression routines expect a QLZ file there, anything else may cause unexpected results.
It's best to leave the splash out instead. I'm still updating the Makefile to be as versatile as possible, in the meantime you could use the one I provided to @SirNapkin1334 .

Thanks for the warning. I'll recompile the 5 SSRs that I did that with before I conduct any more tests. Fortunately you put that Makefile up before I got around to redoing the installers.

EDIT: @windows_server_2003: I see you've redone "if" the way d0k3 wants it now. It seems to work well for the most part. However, my testing shows that using "chk" with "-u" isn't working. I get a "line 65: unrecognized flags" when I try it with my new conversion of my "One & Done" installer. I could make it work by removing the flag and using an "else" of course. But that should not be necessary.

 

[Kazuma77]

@windows_server_2003: The problem I referred to in my previous post appears to be at line 436. That is going to need a change to allow flags used by the commands following an "if" statement. As it is currently written, it only allows the flags used by the "if" command itself. Any command-specific flags in a command being evaluated by the "if" command ("-u" on a chk, "-f" on a find, etc.) will cause the "unrecognized flags" error. Anyway, I'll let you fix it, since you obviously know more about C than I do (I CAN fix it, but I don't think d0k3 would consider commenting out lines 435 and 436 a proper solution ). That one issue aside though, nice work. That was fast.

@d0k3: I don't suppose there's any way to get the old combos back. I've been using your commit from the 20th to avoid adding the longer and random sequences to my SSRs. The existing patterns were enough for me. I could use "AUTO_UNLOCK" and add an "ask" command I guess, but that seems like going too far the other way.

 

[windows_server_2003]

Thanks for the warning. I'll recompile the 5 SSRs that I did that with before I conduct any more tests. Fortunately you put that Makefile up before I got around to redoing the installers.

EDIT: @windows_server_2003: I see you've redone "if" the way d0k3 wants it now. It seems to work well for the most part. However, my testing shows that using "chk" with "-u" isn't working. I get a "line 65: unrecognized flags" when I try it with my new conversion of my "One & Done" installer. I could make it work by removing the flag and using an "else" of course. But that should not be necessary.

I forgot disabling that about "if". By the way, I can't use my PC for 2 weeks but there are some issues in my code.
I have made a bug by coding on Android(that one, forgot "[0]" after findlabel) so I'll never do so.

Also _MAX_ARGS is still 3 and error if run lines like this
if filesel "select" "0:/*" FILE # too many arguments
it should 4.

 

[d0k3]

@d0k3: I don't suppose there's any way to get the old combos back. I've been using your commit from the 20th to avoid adding the longer and random sequences to my SSRs. The existing patterns were enough for me. I could use "AUTO_UNLOCK" and add an "ask" command I guess, but that seems like going too far the other way.

Hmmm.... why don't you want the random ones? Shouldn't be much harder on the user then the hardcoded ones were (except you can now no more use your muscle memory... but that's a bad idea anyways). AUTO_UNLOCK still asks, btw. It just allows confirming with simply the A button.

EDIT: besides, only the more dangerous ones are longer.

 

[d0k3]

Okay, @windows_server_2003 / @Kazuma77 - I thought this through, and I need to have this as a hard requirement - no handling of gotos into conditional blocks. Continuing from what I wrote on the pr comments yesterday...

Example:

if ask "Enter conditional block?"
    echo "Inside conditional block"
    @inside
    echo "After label"
end

goto inside

Doing this...

• ... makes the GM9 scripting code hard to read, hard to extend on and thus also error prone
• ... encourages a bad coding style in script developers, a bad coding style we'd have to support in all versions to come
• ... opens up the door for script code obfuscation, which is just plain dangerous

On top of that, you will be hard pressed to find even one example of a scripting or programming language that would handle goto inside conditional blocks like the pr does. For the example above, on goto and succesful label find, we'd set the if nesting level to zero, then jump to the label. We will encounter an "end" which will trigger an error (cause, starting from the label we saw no "if" before). It's okay to discuss this, but we really can't support it. I can offer call and return commands later on - if something like pseudo functions is wanted.

In general, the pull requests additions must be kept a lot simpler and the number of global vars reduced. If not even I understand what it does anymore, no one will.

Code that is skipped via either goto or an "if false" is not required to be checked on the way. As I wrote, we just need a very simple function for searching a label, and one very simple function for skipping a conditional block. The whole if nesting thing can be handled by *one* global variable which stores the current nesting level.

If you want to check for duplicate elses (in fact, you don't have to, evertyhing "else" has to do is switch between execute and skip, everything else is in the responsibility of script authors), you may do so by storing the else states, that's still okay, but it should be done in as little code as possible. Also keep in mind that only because of the duplicate else checking you have to impose a limit on if nesting and waste 1kiB (1 bool -> 4 byte) of memory, both of which are not worth the small advantage (which is, in essence, telling the script author verbosely he f...d up there).

An offer maybe? @windows_server_2003 - we can work on finishing the if support together once you cleaned up the code a bit, especially the goto / find_label() handling I criticised above.

 

[Kazuma77]

Hmmm.... why don't you want the random ones? Shouldn't be much harder on the user then the hardcoded ones were (except you can now no more use your muscle memory... but that's a bad idea anyways). AUTO_UNLOCK still asks, btw. It just allows confirming with simply the A button.

EDIT: besides, only the more dangerous ones are longer.

You practically answered my question for me. So that it won't screw with my muscle memory. I like knowing exactly what I'm doing next. I'm having a difficult enough time trying to retrain my muscles to use an X-Arcade instead of an SNES controller when playing Street Fighter and Mortal Kombat

Okay, @windows_server_2003 / @Kazuma77 - I thought this through, and I need to have this as a hard requirement - no handling of gotos into conditional blocks. Continuing from what I wrote on the pr comments yesterday...

Example:

if ask "Enter conditional block?"
    echo "Inside conditional block"
    @inside
    echo "After label"
end

goto inside

Doing this...

• ... makes the GM9 scripting code hard to read, hard to extend on and thus also error prone
• ... encourages a bad coding style in script developers, a bad coding style we'd have to support in all versions to come
• ... opens up the door for script code obfuscation, which is just plain dangerous

On top of that, you will be hard pressed to find even one example of a scripting or programming language that would handle goto inside conditional blocks like the pr does. For the example above, on goto and succesful label find, we'd set the if nesting level to zero, then jump to the label. We will encounter an "end" which will trigger an error (cause, starting from the label we saw no "if" before). It's okay to discuss this, but we really can't support it. I can offer call and return commands later on - if something like pseudo functions is wanted.

In general, the pull requests additions must be kept a lot simpler and the number of global vars reduced. If not even I understand what it does anymore, no one will.

Code that is skipped via either goto or an "if false" is not required to be checked on the way. As I wrote, we just need a very simple function for searching a label, and one very simple function for skipping a conditional block. The whole if nesting thing can be handled by *one* global variable which stores the current nesting level.

If you want to check for duplicate elses (in fact, you don't have to, evertyhing "else" has to do is switch between execute and skip, everything else is in the responsibility of script authors), you may do so by storing the else states, that's still okay, but it should be done in as little code as possible. Also keep in mind that only because of the duplicate else checking you have to impose a limit on if nesting and waste 1kiB (1 bool -> 4 byte) of memory, both of which are not worth the small advantage (which is, in essence, telling the script author verbosely he f...d up there).

An offer maybe? @windows_server_2003 - we can work on finishing the if support together once you cleaned up the code a bit, especially the goto / find_label() handling I criticised above.

Well, you'll get no argument from me there. I may not be a coder, but even I can see that shouldn't fly. Maybe windows_server_2003 can have it throw an error if there's a label and the nest count is anything but zero. Regardless, I need a release sooner than he'll be back. R10's new SSRs will be using the old "if" from the 24th. However, I intend to keep "Shove & Shuffle" script-based. so that will use the new "if" to avoid including improper source code (and AUTO_UNLOCK to avoid that random stuff -- it's meant for experts anyway).

 

[windows_server_2003]

Okay, @windows_server_2003 / @Kazuma77 - I thought this through, and I need to have this as a hard requirement - no handling of gotos into conditional blocks. Continuing from what I wrote on the pr comments yesterday...

Example:

if ask "Enter conditional block?"
    echo "Inside conditional block"
    @inside
    echo "After label"
end

goto inside

Doing this...

• ... makes the GM9 scripting code hard to read, hard to extend on and thus also error prone
• ... encourages a bad coding style in script developers, a bad coding style we'd have to support in all versions to come
• ... opens up the door for script code obfuscation, which is just plain dangerous

On top of that, you will be hard pressed to find even one example of a scripting or programming language that would handle goto inside conditional blocks like the pr does. For the example above, on goto and succesful label find, we'd set the if nesting level to zero, then jump to the label. We will encounter an "end" which will trigger an error (cause, starting from the label we saw no "if" before). It's okay to discuss this, but we really can't support it. I can offer call and return commands later on - if something like pseudo functions is wanted.

In general, the pull requests additions must be kept a lot simpler and the number of global vars reduced. If not even I understand what it does anymore, no one will.

Code that is skipped via either goto or an "if false" is not required to be checked on the way. As I wrote, we just need a very simple function for searching a label, and one very simple function for skipping a conditional block. The whole if nesting thing can be handled by *one* global variable which stores the current nesting level.

If you want to check for duplicate elses (in fact, you don't have to, evertyhing "else" has to do is switch between execute and skip, everything else is in the responsibility of script authors), you may do so by storing the else states, that's still okay, but it should be done in as little code as possible. Also keep in mind that only because of the duplicate else checking you have to impose a limit on if nesting and waste 1kiB (1 bool -> 4 byte) of memory, both of which are not worth the small advantage (which is, in essence, telling the script author verbosely he f...d up there).

An offer maybe? @windows_server_2003 - we can work on finishing the if support together once you cleaned up the code a bit, especially the goto / find_label() handling I criticised above.

Okay. I understood that even a popular language, "goto"s into conditional blocks lead to unexpected results so it's not strange.

I'll make it as small and simple as possible.

I think search_command() is not a good name. I wanted to mean "processes while searching/jumping to certain commands" but it is called once per line so "jump_command" is not good. Any good name for this ?

 

[SirNapkin1334]

A good solution to the unlock combo problem is to add a SIMPLE_CLMBO flag to the naked old.

 

[d0k3]

You practically answered my question for me. So that it won't screw with my muscle memory. I like knowing exactly what I'm doing next. I'm having a difficult enough time trying to retrain my muscles to use an X-Arcade instead of an SNES controller when playing Street Fighter and Mortal Kombat

You know, stuff that you got in your muscle memory is semi-automatic? The more often you do it, the less it means for safety. And, that write permission stuff is actually in there so the user has to stop and think for a bit... So, the non random button sequences were only ever a workaround - random is the right way to do it. I'm open for ideas, though.

 

[d0k3]

I think search_command() is not a good name. I wanted to mean "processes while searching/jumping to certain commands" but it is called once per line so "jump_command" is not good. Any good name for this ?

Is this for when you're skipping conditional blocks? I think that should be done in a self contained function, too. Just count up when an 'if' is encountered and count down when an 'end' is encountered. You're finished once you encounter the 'end' or 'else' that marks the end of the skipped condtional block. I might be getting something wrong, of course.

 

[SirNapkin1334]

@d0k3 what are the GodMode9_dev.firm files when I compile?

 

[windows_server_2003]

Is this for when you're skipping conditional blocks? I think that should be done in a self contained function, too. Just count up when an 'if' is encountered and count down when an 'end' is encountered. You're finished once you encounter the 'end' or 'else' that marks the end of the skipped condtional block. I might be getting something wrong, of course.

Yes. I'll do so.

 

[Zidapi]

FIRM installer: Allow Nintendo style entrypoints

d0k3 committed Dec 2, 2017

Hmmm what's this then?

 

[Wolfvak]

Hmmm what's this then?

It's just the removal of a useless check, it prevented some perfectly valid FIRMs from being launched/installed.

 

[Kazuma77]

You know, stuff that you got in your muscle memory is semi-automatic? The more often you do it, the less it means for safety. And, that write permission stuff is actually in there so the user has to stop and think for a bit... So, the non random button sequences were only ever a workaround - random is the right way to do it. I'm open for ideas, though.

Such is the natural order of things. The more you do something, the less you have to think about it. Call me strange, but I have no desire to disrupt that natural order. All I need is something to prevent an accidental double-tap from starting the process. A simple "hold X for 2 seconds" option would be great, IMHO. It could even be argued that not having to enter a combo would keep the focus on the decision for the entire two seconds.

 

[d0k3]

@d0k3 what are the GodMode9_dev.firm files when I compile?

GodMode9 with the devkit sighax signature... that's relevant for installation methods other than GM9 on devkits.

Such is the natural order of things. The more you do something, the less you have to think about it. Call me strange, but I have no desire to disrupt that natural order. All I need is something to prevent an accidental double-tap from starting the process. A simple "hold X for 2 seconds" option would be great, IMHO. It could even be argued that not having to enter a combo would keep the focus on the decision for the entire two seconds.

I'm pretty sure you will like the most recent commits.

 

[Kazuma77]

I'm pretty sure you will like the most recent commits.

Well, I definitely like the looks of the TIMER_UNLOCK build option, but the multi-script thing kind-of looks like a bail-out for my competitors at first glance I've already merged everything into 3 apps using conditionals and the "filesel" command (especially via "Options" -- which uses a header file and labels to merge scripts in a relatively open way that is easy to expand upon). Besides, unless V: is writable, there are several things in both "Settings" and "Options" that just wouldn't work if I tried to do it that way. Then again, I have been wishing there was something more flexible to replace my CBM9 Extras menu with (if you've seen the hoops I jumped through just to create fake submenus, it should be obvious why). I could place my SSR source scripts into the "scripts" folder straight, and just write one-liners to run the CFWs and apps. I'll think about it for R11. And some splash images for that matter, since it's using .pcx now. But R10 is practically ready to release, so, I don't want to hold it up further. I'll just re-compile the SSRs with TIMER_UNLOCK and release it, I think. Thanks again.

EDIT: Well, the new versions of Cakes Launcher and Settings were significantly larger in size (and they get copied to the card 6 times each). Those really don't perform heavy NAND access though (Settings offers to install GM9 if you try to use the "Switch Boot Firm" option without it installed, but aside from that, it never touches it). So, I'll stick with the copies of those I already had built (the configuration does have to fit on a RAM drive, along with some extra apps). But I think the timer unlock is worth taking a 70K hit to Options, Nand Manager, Sighax Updater, and especially the One & Done installer. I think it strikes the right balance -- reasonably protective without being overbearing or obnoxious.

EDIT2: @d0k3: Well, there's a problem. I conducted my initial tests with Shove & Shift (which is the only thing that isn't using SSRs exclusively at this point). The build of GM9 I used for that worked alright. But no SSR I have built is running "autorun.gm9" for some reason. I'm aware that the build option has changed to "SCRIPT_RUNNER=1" and I'm using that, but it's just not working for some reason. Maybe TIMER_UNLOCK is interfering with it somehow.

EDIT3: Found it! Have a look at "Makefile.common" line 37. Changing it to "-DSCRIPT_RUNNER" seems to fix it. So, apparently it just wasn't setting the "SCRIPT_RUNNER" option. This also seems to have been what was causing the much larger file sizes (but that makes sense -- it was building a full GM9).

 

[d0k3]

Well, I definitely like the looks of the TIMER_UNLOCK build option, but the multi-script thing kind-of looks like a bail-out for my competitors at first glance I've already merged everything into 3 apps using conditionals and the "filesel" command (especially via "Options" -- which uses a header file and labels to merge scripts in a relatively open way that is easy to expand upon). Besides, unless V: is writable, there are several things in both "Settings" and "Options" that just wouldn't work if I tried to do it that way. Then again, I have been wishing there was something more flexible to replace my CBM9 Extras menu with (if you've seen the hoops I jumped through just to create fake submenus, it should be obvious why). I could place my SSR source scripts into the "scripts" folder straight, and just write one-liners to run the CFWs and apps. I'll think about it for R11. And some splash images for that matter, since it's using .pcx now. But R10 is practically ready to release, so, I don't want to hold it up further. I'll just re-compile the SSRs with TIMER_UNLOCK and release it, I think. Thanks again.

EDIT: Well, the new versions of Cakes Launcher and Settings were significantly larger in size (and they get copied to the card 6 times each). Those really don't perform heavy NAND access though (Settings offers to install GM9 if you try to use the "Switch Boot Firm" option without it installed, but aside from that, it never touches it). So, I'll stick with the copies of those I already had built (the configuration does have to fit on a RAM drive, along with some extra apps). But I think the timer unlock is worth taking a 70K hit to Options, Nand Manager, Sighax Updater, and especially the One & Done installer. I think it strikes the right balance -- reasonably protective without being overbearing or obnoxious.

EDIT2: @d0k3: Well, there's a problem. I conducted my initial tests with Shove & Shift (which is the only thing that isn't using SSRs exclusively at this point). The build of GM9 I used for that worked alright. But no SSR I have built is running "autorun.gm9" for some reason. I'm aware that the build option has changed to "SCRIPT_RUNNER=1" and I'm using that, but it's just not working for some reason. Maybe TIMER_UNLOCK is interfering with it somehow.

EDIT3: Found it! Have a look at "Makefile.common" line 37. Changing it to "-DSCRIPT_RUNNER" seems to fix it. So, apparently it just wasn't setting the "SCRIPT_RUNNER" option. This also seems to have been what was causing the much larger file sizes (but that makes sense -- it was building a full GM9).

Thanks for pointing that messup out .

Anyways - you'd be better served with a way to run a script from inside a script, correct? Or, some way you could have a menu that jumps to a label. I can think about ways to support this.

@windows_server_2003 - I know you're busy, but any ETA on the changes to the pull request?

 

[windows_server_2003]

@windows_server_2003 - I know you're busy, but any ETA on the changes to the pull request?

I'm sorry for taking long.
I can probably use my PC from about 12/9 12:00 in Japan, 12/9 3:00 in UK.
I can use it a little even until that time.

 

[d0k3]

I'm sorry for taking long.
I can probably use my PC from about 12/9 12:00 in Japan, 12/9 3:00 in UK.
I can use it a little even until that time.

That's perfectly okay, there's a lot else to do, too, in the meantime .