problem with command line switches

[avih]

Nice, glad it worked, and thanks for the info

So if I summarize your conclusions, musera:

1. Both the ISO file name, and the path for --cfgpath CAN use quotes.
2. The ISO file name must appear as the first argument (before any other flags/switches).

Am I correct?

I now noticed that the CLI help (invoking pcsx2.exe -h) shows both with and without the '=' character (i.e. --cfgpath <path> at the top of the dialog, and --cfgpath=<path> at the detailed help below). Should we use only one of them at the help? which one?

Also, this help dialog shows that the ISO file name appears last. Any thoughts on it? Rezard?

[musera]

Nice, glad it worked, and thanks for the info

So if I summarize your conclusions, musera:

1. Both the ISO file name, and the path for --cfgpath CAN use quotes.
2. The ISO file name must appear as the first argument (before any other flags/switches).

Am I correct?

Yes

I now noticed that the CLI help (invoking pcsx2.exe -h) shows both with and without the '=' character (i.e. --cfgpath &lt;path&gt; at the top of the dialog, and --cfgpath=&lt;path&gt; at the detailed help below). Should we use only one of them at the help? which one?

Just tested "--cfgpath <path>" and it came up with an error stating "Option 'cfgpath' requires a value, '=' expected". Though the error has some poor wording, it pretty clearly states that the = sign is needed.

[avih]

Thanks, musera. I'll update the help dialog with these.

Rezard, can you please update your post with this new info (order, quotes, and setting useDefault<Config>=disabled for custom folders)? FYI, I just linked to that post from the quick guide.

[musera]

Ahh one last note which is very important. When using cfgpath="path" make sure it doesn't end in a slash (ie cfgpath="path/" is bad), if you could write that in some sort of document or somewhere it may help people. I was just writing a script to check whether a game has all appropriate config files and a memory card and had to spend an hour trying to figure out why it wouldn't work, was just that bloody slash >_<

[avih]

Ahh one last note which is very important. When using cfgpath="path" make sure it doesn't end in a slash (ie cfgpath="path/" is bad), if you could write that in some sort of document or somewhere it may help people. I was just writing a script to check whether a game has all appropriate config files and a memory card and had to spend an hour trying to figure out why it wouldn't work, was just that bloody slash >_<

Hmm.. thanks. I might be able to remove the last '\\' or '\' or '/' while processing the path (possibly also at other places which process a path). Not critical, but can be highly annoying...

Regardless, the help dialog is automatically provided by wxWidgets. It sets the display format and order (for both the top "summary" without the '=', and for the lower detailed help which includes the '='). That's at 3rdparty/wxWidgets/src/common/cmdline.cpp . While not hard, I'm not going to change this 3rd party library, We'll do with what's provided as it is now. We'll just have to update the guide (and quick guide, etc).

[avih]

Ahh one last note which is very important. When using cfgpath="path" make sure it doesn't end in a slash (ie cfgpath="path/" is bad), if you could write that in some sort of document or somewhere it may help people. I was just writing a script to check whether a game has all appropriate config files and a memory card and had to spend an hour trying to figure out why it wouldn't work, was just that bloody slash >_<

OK, this is weird. Not sure I can reproduce this one. I tried using a "path" and "path/" and both seem to use the same (correct) folder. If, however, I use "path\", then something interprets the last \" as an escape sequence and it works a bit different (didn't determine if that's broken).

Are you sure you had issues with slash (and not with backslash)? Also, could you please post one working and one non-working command lines which show this issue? (please test them both from actual DOS prompt and from a batch file, it might be interpreted differently). Also, at this stage, it might be helpful to know which OS you use.

Thanks again.

[Rezard]

So I finally understand why I couldn't get the cfgpath in "quotes" to work before. It's all about the backslash.

I was using the backslash on the end of path, which will not work if in "quotes". If the path doesn't have to be contained in "quotes", it will work fine with the backslash on the end. I really appreciate you guys bringing this to my attention.

About the "usedefault____" options; Which one's are necessary?
I figure the mem card only if using a specific one (chosen when configuring the inis with PCSX2), or the plugins.

[musera]

OK, this is weird. Not sure I can reproduce this one. I tried using a "path" and "path/" and both seem to use the same (correct) folder. If, however, I use "path\", then something interprets the last \" as an escape sequence and it works a bit different (didn't determine if that's broken).

Oh my apologies, it was a backslash that was the problem. My brain had gone to mush after debugging a script that seemed to have no issues for an hour.

About the "usedefault____" options; Which one's are necessary?
I figure the mem card only if using a specific one (chosen when configuring the inis with PCSX2), or the plugins.

I seemed to have issues when disabling plugins, it worked sometimes and then sometimes didn't. It was possibly my fault but I didn't take the time to figure it out. The rest were just disable any that were appropriate.


Might I propose adding a few new switches:

--memc0="<path>"
changes memory card in slot 1

--memc1="<path>"
changes memory card in slot 2

bah had a couple of others in mind but lost them as I was writing.

[avih]

So I finally understand why I couldn't get the cfgpath in "quotes" to work before. It's all about the backslash.
...

Yes. There's still the problem that if you pass a file name as an argument to a batch file, and then use --cfgpath="%~dp1" , you WILL get a string ending in \" . One solution would be to create a subfolder for the config files and concatenate it manually such that you know it doesn't end in \" (e.g. "%~dp1inis" , after creating inis, or other creative folder name - maybe even the actual iso-file-name.config folder, etc).

I'll try to check in what ways \" hinders the interface, and possibly smooth it out a little (programatically, when detecting such scenario). But the most important thing is indeed that we now know "path\" is problematic.

About the "usedefault____" options; Which one's are necessary?
...

Whichever ones you'd like to override with custom folders. Maybe memcards and sstates? (depending on how much you'd like to isolate. What's best to isolate is another question - see further down at this post).

Might I propose adding a few new switches:
--memc0=""
...

Memcards specifically need all to reside at the same folder IIRC, and therefore cannot (easily) use full separate path for each.


However, generically speaking, I can see the need for a command-line based per-iso-isolation (to include memcards, possibly specific config, etc), which is apparently not very easy to achieve currently via CLI. While there are at least two PCSX2 launchers which allow just that, it's still cumbersome to use PCSX2 itself from a generic launcher (e.g. XMBC).

If we want to improve isolated invocation from generic launchers, I think we need to answer these (preferably after personally observing the needs at this scenario, and bumping into the current CLI limitations):

1. What's best to isolate?
2. Does the current CLI supports #1 reasonably?
3. How to extend the CLI to better support #1?

[Rezard]

Might I propose adding a few new switches:

--memc0="<path>"
changes memory card in slot 1

--memc1="<path>"
changes memory card in slot 2

But a custom location for the memory card folder can be within the ini. Just configure in the MemoryCard Manager the desired location of your folder (same for savestates, plugins, etc in the Plugin/BIOS Selector). With the ini goes the location(s).