Okay, great! And thanks for the find! I gotta add this to the readme right away.
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?
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?
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.
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:
https://f.secretalgorithm.com/tscaL/makefile
... then, just delete the file from the resources dir - I think that should work.
Okay! I'll try it.
Cool! It worked! On boot it does say GodMode9_splash.qlz not found for a moment, but that won't matter since it's SaltMode9.
@d0k3 what is GodMode9_dev?
Last edited by SirNapkin1334,
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.
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.
- Joined
- Nov 23, 2014
- Messages
- 15,144
- Trophies
- 0
- Location
- Canberra, Australia
- Website
- boot9strap.com
- XP
- 11,094
- Country
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
- Joined
- Nov 23, 2014
- Messages
- 15,144
- Trophies
- 0
- Location
- Canberra, Australia
- Website
- boot9strap.com
- XP
- 11,094
- Country
https://github.com/d0k3/GodMode9/blob/master/README.md look under Bootloader Mode
If you want it Eix made a short guide
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...
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..."
endYou see that this would open up a whole slew of new possibilities? As for 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.
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
Last edited by Kazuma77,
@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.
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:
Code:
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
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.
Last edited by d0k3,
Well, if it's all the same then, by all means, I'd love to see a more versatile implementation. It's no big deal if my scripts will require some changes, after all. Notepad++ has a very good S&R feature.
It sounds like we both have plans. You want to get proper branching in GM9. I want to eliminate uncompiled scripts from InScripted. Since we both want a big release this year, that's great. We're on the same page then.
And yes, if I could retrieve the "filename" with the "find" and "filesel" commands, that would be extremely useful (it might even have some uses with "findnot" for that matter). As it is, using the choice made via "filesel" to determine subsequent actions either requires including the full path name in said subsequent action, or checking for each file the user could possibly pick with a separate "if" command. It's not like I named folders "boot9strap.firm.config" and "Godmode9.firm.config" because I wanted to. It was just the only way I could come up with to include matching configurations my "Sighax Updater" script could find and use. Also, if you could provide a text formatting option to replace spaces with underscores... "Options" currently works by using the full path from "filesel" as a label. It has you pick an included app, then performs a "goto" on the chosen filename. It works. However, those underscores in the menu are ugly (but labels can't contain spaces).
Frankly, I'm not sure where SirNapkin1334 got that idea. I probably use "ask" the least of anyone (because I absolutely despise UAC). Generally, if you need to think, you'll get a screen already. Since he did bring it up, there is one case where I would consider using a stronger warning. That would be the part of "GW Save Conversion Helper" that overwrites the chosen save with the one from the save manager, since one wrong move could cost you hours of progress.
Well, you have my "Settings.gm9" script. You can see that both the options to switch default payloads and hotkeys are inline, among other things. I'm not sure how many of these inline cases would work without the nesting, but I would feel like I was being forced to follow every "if" line with a "goto" line without it, because I would have no way of readily knowing whether a particular inline use would work or break stuff. Though if that won't break without the nesting, well, here's something that probably will. I merged your "return to retail" scripts into a single app. Keep in mind that, as written, it's meant to be merged into "Options" and will not work correctly on it's own (it has a "goto" going to a label not found anywhere within the script -- "options_main"). Though I have included the line (commented out) that would make it a standalone script.
Last edited by Kazuma77,
https://github.com/windows-server-2003/RedUnlocker
The red permission cannot modify M: but the blue one can modify both S: and M:
To prevent bricking
1) Do not run untrusted scripts
2) Do not unlock the blue one
I'm cleaning my code first.
GM9 is like Linux shell script and that style is much better than mine.
I understood what you are saying on Github "call run_line() itself..." now.
With that style, "if" with "if" as the condition should be forbidden.
I think adding flags to them is better than adding flags to "if" command itself.
I'll change it to that style.
I still use my PC a few time so try to clean up.
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
"or" and "and" etc. as keywrd to control conditions is nice but is impossible. In the launguages which uses "or" as keyword such as VBS, string should be covered with double quotes. so it's possible to use "or" etc. to such meaning.
GM9 is not - string don't have to be covered. so the interpreter can't decide it's "or" as a standard arg or as a keyword to control conditions.
so that's never the reason of not need "if" nesting
Last edited by windows_server_2003,
@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 .
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 .
Similar threads
- No one is chatting at the moment.
-
-
-
-
-
-
-
-
-
-
-
-
-
@
Psionic Roshambo:
If your not getting your pills from Psi's discount drugs who knows what your swallowing!+1 -
@
Psionic Roshambo:
Shawnita used to get her pills from some other street pharmacist and after switching to The Psi Discount plan she now only has to swallow two things a day!+1
-
-
-
-
-
-
-
-
-
-
-
