Command-line arguments

[ce-programming]

Command-line arguments

[alberthdev]

This is something I'd like to work on when I get a chance! I think the ideas included:

• Configuration adjustment - having the ability to save and load a GUI setup + emulator configuration from a file via the command line. (Should we have the ability to change configuration using the GUI as well?)
  • --load-config [CONFIG] and --save-config [CONFIG], potentially.
  • QSettings supports loading and saving configuration to an INI file.
  • One thing to note - would it be possible to override configuration on command line? For instance, if the ROM is typically file1, could we override that with file2 without overriding the configuration? Since we use QSettings to fetch our settings... we need to save them there as well. (Is there a way of opening QSettings read-only?) ROM may not be the best example (since we can override at runtime), but there may be other settings to consider.
• --rom [ROMFILE] - obligatory ROM file selection.
• --send [FILE] - send files on emulator start. I still need to evaluate whether QCommandLineParser can handle duplicate arguments (e.g. --send file1 --send file2) or not. If not, not a big deal - we could maybe do something like --send file1,file2 or some other path delimiter.
• Keypresses: Macro files potentially? If we do allow specifying on the command line, we should be able to distinguish quick presses from holds. If we're really crazy, we can specify the hold down, hold up time as well...
• Another idea would be to have screenshots/screencapturing abilities exposed to CLI as well.

Another interesting thing to consider (outside the scope of this particular issue) - do we want to add any Lua support? Might be kind of interesting to do, though it may add some overhead... What do you guys think?

[elfprince13]

It would be great to have a "execute this program/app" option.

I would prefer exposing an IPC mechanism over embedding a specific scripting language.

[debrouxl]

I agree that an IPC mechanism, which is the topic of issue #16 , is higher priority than scriptable emulator operation using Lua, Python, JS or another widely used programming language, possibly using an embeddable implementation (Duktape, XS6, Micro Python, etc.) inside a native code program.

Said scripting front-end, with advanced file send / file recv / keypress / screenshot / other capabilities, should build on top of the IPC. I'll create an issue for scripting on top of the IPC.

[mateoconlechuga]

While I agree having an IPC would be neat, I disagree that this should become a feature. This is already implemented throughout the GUI, and the userbase for it would be very minimal compared to the effort spent in implementing it. I would like to focus more on the CLI when starting the program, as I feel this would be the most useful feature.

In addition, because of state saving, it is going to be rather difficult to find a way to safely transfer files on start.

[geekbozu]

So in pull request #75 i added in basic support for some of this stuff. Most notably autotester integration as well as something @adriweb requested else where. Which is forcing a ROM load instead of the saved state.

Loading a ROM via commandline is currently not possible there is no interface to do so. In Cemu's current setup one could be added but it would change the ROM that is loaded after that. (EG. it would get saved as the current ROM). I believe this to be acceptable practice, but in some auto testing situations it might be a nuisance to the end user if it overwrites their typical use ROM.

In addition, because of state saving, it is going to be rather difficult to find a way to safely transfer files on start.

There is now a command line argument to ignore that. Alternatively we could assume sending files implies a reset of the device. Both are acceptable.

[mateoconlechuga]

A list of command line arguments can be found here: https://github.com/CE-Programming/CEmu/wiki/Command-Line-Arguments

Because this implements many things; I feel that the scripting interface could easily handle future items, especially with lua. This topic is being closed; however a future command line argument to load a lua script is really the only nesassary thing left.