Okay, great! And thanks for the find! I gotta add this to the readme right away.It worked! I have yet to actually run the firm, but it made it successfully.
Okay, great! And thanks for the find! I gotta add this to the readme right away.It worked! I have yet to actually run the firm, but it made it successfully.
It works. I can immediately tell there are random write locks because I totally failed to enter it twice xDOkay, great! And thanks for the find! I gotta add this to the readme right away.
Yes, that's correct. Keep in mind SALTMODE is only different from default when installed to FIRM, otherwise it's exactly the same. Random write locks? Can you explain?It works. I can immediately tell there are random write locks because I totally failed to enter it twice xD
I'm not sure if I build SaltMode9 correctly though.
Is it make firm SALTMODE=1?
I see. Guess it's time to install!Yes, that's correct. Keep in mind SALTMODE is only different from default when installed to FIRM, otherwise it's exactly the same. Random write locks? Can you explain?
Just put anything you want there into the data folder. The total size of the tar file must not exceed 3MB, but it's rather unlikely that happens.I see. Guess it's time to install!
Sorry, that was my quick way of saying Random Input Sequences.
Also, can you hardcode anything into VRAM? If so, I think I'll make a nice TXT with some reminders in case I forget how to do something.
Cool! How can I stop it from hardcoding the GodMode9_splash.qlz?Just put anything you want there into the data folder. The total size of the tar file must not exceed 3MB, but it's rather unlikely that happens.
Try this Makefile:Cool! How can I stop it from hardcoding the GodMode9_splash.qlz?
Okay! I'll try it.Try this Makefile:
https://f.secretalgorithm.com/tscaL/makefile
... then, just delete the file from the resources dir - I think that should work.
What do you mean by GM9 payloads? If you mean Luma payloads you can do this by copying the luma folder to CTR-NAND/rwOkay. I have a new feature request.
I would like to have the ability to use GM9 payloads without the SD card, i.e. by copying them into CTRNAND, like Luma. Can this be done? It'd be nice.
GM9 Payloads. Using the GM9 Bootloader.What do you mean by GM9 payloads? If you mean Luma payloads you can do this by copying the luma folder to CTR-NAND/rw
Sounds exciting, maybe I should read more of this threadGM9 Payloads. Using the GM9 Bootloader.
https://github.com/d0k3/GodMode9/blob/master/README.md look under Bootloader ModeSounds exciting, maybe I should read more of this thread
I'll look into that, not a bad idea.Okay. I have a new feature request.
I would like to have the ability to use GM9 payloads without the SD card, i.e. by copying them into CTRNAND, like Luma. Can this be done? It'd be nice.
if $[HOTKEY] "V:/zeroes/HKB/(All)"
if (HOTKEY == "V:/zeroes/HKB/(All)")
if ask "Do you want to continue?"
echo "Continuing here..."
end
if $[HOTKEY] "V:/zeroes/HKB/(All)"
if equal $[HOTKEY] "V:/zeroes/HKB/(All)"
Try this Makefile:
https://f.secretalgorithm.com/tscaL/makefile
... then, just delete the file from the resources dir - I think that should work.
I'll look into that, not a bad idea.
@Kazuma77 / @windows_server_2003 - I looked into how ifs work, and I get it now. However, the way they work is very limiting. An example:
You may have...
... which, translated to pseudo-C means...Code:if $[HOTKEY] "V:/zeroes/HKB/(All)"
Code:if (HOTKEY == "V:/zeroes/HKB/(All)")
All you can do is compare strings, nothing else, meaning you can't check the result of a lot of operations and use it as an if condition.
I had something else in mind:
Code:if ask "Do you want to continue?" echo "Continuing here..." end
You see that this would open up a whole slew of new possibilities? As for this:
... you could provide this functionality by providing an equal command, like this:Code:if $[HOTKEY] "V:/zeroes/HKB/(All)"
Code:if equal $[HOTKEY] "V:/zeroes/HKB/(All)"
The equal command would even allow for specific comparisons, like case insensitive ones via flags. Also, @windows_server_2003 - don't worry too much about putting this on hold. I want a new major release of GM9 this year, and I want that stuff in, but we still got time. I can do some of the stuff I suggested myself, too, if you want me to.
@Kazuma77 - I'd use indentations on ifs - that would make the code a lot better readable.
kcombo -c [background color] -l [length] “Message to be displayed.”
I had been using a zero-byte file for my new SSR compiles to make them smaller, so, thanks for a more proper solution.
That's why I suggested at least adding the -u flag to it. So we could check for a negative at least. I realize it's somewhat limited. But you know how the saying goes, about a good solution today being better than a perfect solution tomorrow. I mean, I'd love to have equals, inequals, contains (you could look for key words like "backup" in a choice, for example), greater than, less than, boolean operators like and, or, xor, etc. ("or" would be especially handy, because as it is, if you want two options to run the same subroutine, you have to use an "if" subroutine to set a matching variable), but how complicated would that be to pull off?
It's not really that bad thanks to shaget, find, and filesel though. But more commands setting variables might help. One thing that would be good is if we could parse "find" results into the path, filename, and extension parts. My "switch_chainloader" section would not need as much branching if it could just take the filename and use it. For example, the part that moves around files between the "switch chainloader" and "active chainloader" folders, so that it both knows which options to present, and won't display the current one as an option. That could use much fewer lines if I could just use the "filename" directly.
Also, I'm sorry about the script not being more reader-friendly. I was just trying to throw together a working solution. I wasn't planning on submitting it for analysis at the time
Would that help you, @Kazuma77? Can't implement like @SirNapkin1334 asked, but similarily.@d0k3 I have a small feature request. It wouldn't be very useful for me, but I'm sure Kazuma would appreciate it.
Prompting for unlock combos without actually unlocking. So, it lets you ask, for for example if you were going to overwrite boot.firm, which would not normally prompt for an unlock combo. The command should be like this:
It should default to length of five and background color of black.Code:kcombo -c [background color] -l [length] “Message to be displayed.”
Well... what I suggested, the more versatile usage of the 'if' command wouldn't actually be more work. Pretty easy to implement, actually, mainly because I had that possibility in mind when I started writing the scripting code. The hardest part would be preventing shenanigans like "if goto somewhere" or "if else". But we'd have to move @windows_server_2003's code partially to external functions first.
One other problem with the current implementation is that it will be pretty hard to build on it. All of what you mentioned above (greater than, etc) would not be too hard to do once we got the universal if command. With the current implementation? Almost impossible without making the code very hard to read (thus, making messups on my side more probable). Add in more ambitious stuff like 'for', and you see a desaster in the making. I want to do a big GM9 release this year, and I don't want to introduce script incompatibilies between versions. We also want a 'for' command and stuff. Go figure, we have no choice other than to change how 'if' works before we merge it. No offense meant, @windows_server_2003 - I hope it's clear this is a big change, and it absolutely needs to be perfect, and I need to be nitpicking before it goes into master.
Anyways... If you want a way to extract filename / extension / base directory from a path in variable, just ask. That's pretty easy to do.
Would that help you, @Kazuma77? Can't implement like @SirNapkin1334 asked, but similarily.
Also, @Kazuma77 - can you point out an example of if nesting in your code? I want to see how you are using it.
https://github.com/windows-server-2003/RedUnlockerWhat are side effects of editing memory? What would you have to edit (besides headers) to brick your 3DS?
If you want it, I'll attach a list of strong combos soon.
Okay, I created a random combo generator that ensures that the combo doesn't have the same direction twice in a row.
I'm cleaning my code first.I'll look into that, not a bad idea.
@Kazuma77 / @windows_server_2003 - I looked into how ifs work, and I get it now. However, the way they work is very limiting. An example:
You may have...
... which, translated to pseudo-C means...Code:if $[HOTKEY] "V:/zeroes/HKB/(All)"
Code:if (HOTKEY == "V:/zeroes/HKB/(All)")
All you can do is compare strings, nothing else, meaning you can't check the result of a lot of operations and use it as an if condition.
I had something else in mind:
Code:if ask "Do you want to continue?" echo "Continuing here..." end
You see that this would open up a whole slew of new possibilities? As for this:
... you could provide this functionality by providing an equal command, like this:Code:if $[HOTKEY] "V:/zeroes/HKB/(All)"
Code:if equal $[HOTKEY] "V:/zeroes/HKB/(All)"
The equal command would even allow for specific comparisons, like case insensitive ones via flags. Also, @windows_server_2003 - don't worry too much about putting this on hold. I want a new major release of GM9 this year, and I want that stuff in, but we still got time. I can do some of the stuff I suggested myself, too, if you want me to.
@Kazuma77 - I'd use indentations on ifs - that would make the code a lot better readable.
We have "chk -s [-u]" to check equal or unequal if "if" can handle other commands' result.I had been using a zero-byte file for my new SSR compiles to make them smaller, so, thanks for a more proper solution.
That's why I suggested at least adding the -u flag to it. So we could check for a negative at least. I realize it's somewhat limited. But you know how the saying goes, about a good solution today being better than a perfect solution tomorrow. I mean, I'd love to have equals, inequals, contains (you could look for key words like "backup" in a choice, for example), greater than, less than, boolean operators like and, or, xor, etc. ("or" would be especially handy, because as it is, if you want two options to run the same subroutine, you have to use an "if" subroutine to set a matching variable), but how complicated would that be to pull off?
It's not really that bad thanks to shaget, find, and filesel though. But more commands setting variables might help. One thing that would be good is if we could parse "find" results into the path, filename, and extension parts. My "switch_chainloader" section would not need as much branching if it could just take the filename and use it. For example, the part that moves around files between the "switch chainloader" and "active chainloader" folders, so that it both knows which options to present, and won't display the current one as an option. That could use much fewer lines if I could just use the "filename" directly.
Also, I'm sorry about the script not being more reader-friendly. I was just trying to throw together a working solution. I wasn't planning on submitting it for analysis at the time