[FEATURE REQUEST] Cli scripting tool

[ExperiBass]

Got a great idea on how to improve GodMode9? Not exactly GM9, but its related to it. I'm messing with the scripting engine and its a bit annoying having to constantly shut down, eject my sd card, put it in my computer, copy over the edited file, eject it from the computer, insert it back into my 3ds, and start GM9 just to test a change. Describe the feature you'd like It would be nice to test scripts locally before putting them into my 3ds and running them, thought that might be a lot of work. Describe alternatives you've considered None, because there are no alternatives.

[aspargas2]

I've thought about making something like this, but it would indeed be a lot of work to make for what reward it is. Maybe I'll get around to it eventually. The ideal thing here would be to run GodMode9 on a proper low-level emulator, but Corgi3DS doesn't boot recent gm9 versions for some reason last I checked. I'm not sure if the reason for that is identified and how hard it would be to fix.

[ExperiBass]

yeah, i was thinkin about it and the only way i thought of was creating a low-level emulator.

[d0k3]

@GingkathFox - I can only suggest you find a system that works for you. Maybe transfer scripts via FTP instead? 3DShell provides that functionality on 3DS side, Filezilla will take care of the Windows side of things.

As for providing a possibility to test scripts locally, can't help. We'll keep that feature request open if @aspargas2 sees this as possibility for later.

[aspargas2]

Alright, we've concluded that the only practical way to do something like this is to run GodMode9 under Corgi3DS. In order to make any relatively recent commit of GodMode9 launch in corgi, you need to change the vu16 in this line to a vu32. This will be fixed in master eventually, but for now I'll upload a build of the latest commit with this fix added here. A few remarks/tips on using corgi:

• It can only emulate an Old 3DS, so you'll need to give it a NAND image that would work on an o3ds.
• It spits out a lot of spammy debug info onto stdout while running, which dramatically slows down emulation when doing certain things. I would highly recommend piping its output to /dev/null or whatever your OS's equivalent is.
• One easy/lazy way to get a small image to use as an SD image for corgi is to just copy a ctrnand_full.bin out of any NAND image and delete all the files from it that don't make sense to be on an SD card.
• From my brief testing, mounting and modifying the SD image or partitions in the NAND image while corgi is running seems to work fine, but I wouldn't count on it not causing problems in specific scenarios.

With all that said, I'm going to be closing this issue now. Let me know if you have any issues using corgi for this.

output.zip