What is up with Retroarch Default Command-Line Parameters field?

[skizzosjt]

This field has never made sense to me, that is, only regarding Retroarch. Doesn't matter what I've ever entered here, from what I can tell, it's ignored. For any other emulator or script masquerading as an emulator, I can always make use of the Default Command-Line Parameters field. So, this situation seems to only apply to Retroarch

 

For Retroarch, I always need to resort to use the "Extra Command-Line Parameters" field that is instead under the "Associated Platforms" tab. Here, commands actually work. I do take note that the fullscreen parameter gets auto-filled here. I just don't know why it needs to be here rather than the default

 

With that said, can someone please explain to me how does a user make use of Default Command-Line Parameters field for Retroarch? I am lost on why things behave like they do regarding this situation.

[sundogak]

43 minutes ago, skizzosjt said:

This field has never made sense to me, that is, only regarding Retroarch. Doesn't matter what I've ever entered here, from what I can tell, it's ignored. For any other emulator or script masquerading as an emulator, I can always make use of the Default Command-Line Parameters field. So, this situation seems to only apply to Retroarch

 

For Retroarch, I always need to resort to use the "Extra Command-Line Parameters" field that is instead under the "Associated Platforms" tab. Here, commands actually work. I do take note that the fullscreen parameter gets auto-filled here. I just don't know why it needs to be here rather than the default

 

With that said, can someone please explain to me how does a user make use of Default Command-Line Parameters field for Retroarch? I am lost on why things behave like they do regarding this situation.

LB is basically a launcher taking your inputs and creating a command line to launch the emulator.  The flags you are trying to pass are specific to a RA core.  RA base executable + core [and any switch/parameters] = emulation.   The first example you give is trying to give a switch/parameter to the base retroarch.exe before a core is loaded.  RA doesn't know what to do with it so ignores it. The second screen works because RA now knows which core to run and LB adds those additional parameters to RA + the core at that point.

Edited February 9 by sundogak

[skizzosjt]

Hey @sundogak, thanks for chiming in here!

Can you give an example of what would work in the default command line parameter field for Retroarch? If there ever was a candidate for a default, the fullscreen parameter would be just that. it is redundant to have to put it in every core's specific field in my opinion.

 

 I tried a bunch of variations of this. Parameter sequences do not matter. For ex, this works via command prompt - but doesn't if transposed into LB default command line parameter field

retroarch --appendconfig "retroarch_Mega_Bezel.cfg" --set-shader "MAME_Mega_Bezel.slangp" -f "D:\ROMS\MAME .261 Non-Merged\MAME 0.261 ROMs (non-merged)\1941.zip" -L "mame_libretro.dll"

The -f parameter also doesn't work in the default command line parameter field. (I'm sure why the devs designed to auto fill it in the extra field instead) Fullscreen is certainly not core specific, yet, this parameter, along with literally anything else, doesn't work in the default field.

 

I think I'm just ranting a bit here, because if I am correct with my suspicions, LB has a field we can enter stuff into that seems to do literally nothing to impact things one way or the other. That can be confusing to users. This is why I ask for an example of how to use this field. If I am not "getting it", I need to understand how the field was meant to be utilized.

 

If it does in fact do nothing for Retroarch, it should be able to detect when Retroarch is the emulator and grey out the default field and users should not be allowed to enter things here to prevent confusion. Or if that is not feasible, a note beneath the field saying "This field is ignored for Retroarch - instead use Extra Command-Line Parameter field in Associated Platforms".

 

[sundogak]

Only the parameters in the associated platform for RA are added to run command.  As to why RA isn't managed differently, I do not know.  I have never run into it as issue as anything RA wide I use the Retroarch.cfg  (e.g., fullscreen or default shaders) and specific flags have to go with the associated core entry.

Edited February 10 by sundogak

[JoeViking245]

14 hours ago, skizzosjt said:

This field has never made sense to me, that is, only regarding Retroarch. Doesn't matter what I've ever entered here, from what I can tell, it's ignored. For any other emulator or script masquerading as an emulator, I can always make use of the Default Command-Line Parameters field. So, this situation seems to only apply to Retroarch

As you know, with all emulators, the Default Command-line Parameters get completely overridden when there are any Custom Command-line Parameters present in the Associated Platforms section, for that platform.

In case of RetroArch, in the Associated Platforms section LaunchBox adds the [would-be required] field Core.  Which in turn, automatically adds to the command-line parameter -L "core_name_from_the_core_field.dll".  Most likely (guessing here), since the Association Platforms section is adding [something] the command line, the Default Command-Lines Parameters are ignored (overridden).  Which will be the case with any platform using RetroArch.

So you are correct. Though the developers had the foresight to add the Core field and auto-populate them with the most likely core (along with adding -f to the Extra Command-line Parameters) for our convenience, they neglected to disable the Default Command-line Parameters field in the Details section.

But who would have discovered this other than a 'power user'?  

Sounds like a reasonable BitBucket item.  Though not a bug, not sure it's actually a feature request either.  But a 'something' none-the-less.

[skizzosjt]

Thanks both of you!

 

On 2/10/2024 at 8:12 AM, JoeViking245 said:

As you know, with all emulators, the Default Command-line Parameters get completely overridden when there are any Custom Command-line Parameters present in the Associated Platforms section, for that platform.

Nah actually I was thinking pretty similar to this user who made a rather similar report. But thanks to all this testing and both of your feedback, now I understand how it all works!

https://bitbucket.org/jasondavidcarr/launchbox/issues/5519/112-mame-default-command-lines-on-details

The difference there with MAME is it seems you can remove everything from the entry in the Associated Platforms line and it will then allow the default command-line parameter field to work per the expected order of precedence.

With this new info in mind I think this is intended behavior, but, maybe can call it an oversight on not disabling the default field that is always ignored. Retroarch seems to require the core to be selected in the Associated Platforms (if it's not defined at the game level custom command-line parameter field that is) which therefore means there will always be an entry there and further means the Default Command-Line Parameter field is always ignored. If you try to remove the core association in Associated Platforms Retroarch will not even launch. I have startup screens on and those don't even start, gives the impression LB doesn't try to launch the game in that situation. I filled out a "trivial bug" report in hopes it can be improved upon.

https://bitbucket.org/jasondavidcarr/launchbox/issues/8568/retroarch-default-command-line-parameter

[JoeViking245]

1 hour ago, skizzosjt said:

gives the impression LB doesn't try to launch the game in that situation.

In that case (with the core having been left blank), LaunchBox is [most likely] still passing -L "".  (the core_name.dll would have gone between the quotes)  So ends up being:

"D:\Emulators\Retroarch\retroarch.exe" -L "" "D:\ROMs\Atari 2600\Adventure.zip"

Again, just for an emulator using retroarch.exe.  So it does try to launch it.  It just happens to return an error (fail).

[skizzosjt]

15 hours ago, JoeViking245 said:

In that case (with the core having been left blank), LaunchBox is [most likely] still passing -L "".  (the core_name.dll would have gone between the quotes)  So ends up being:

"D:\Emulators\Retroarch\retroarch.exe" -L "" "D:\ROMs\Atari 2600\Adventure.zip"

Again, just for an emulator using retroarch.exe.  So it does try to launch it.  It just happens to return an error (fail).

I was doing it through a supplemental emulator in my list used for testing so I needed to go through the right click context menu and click on the specific core to launch. In this case when I remove the core, that core will no longer show up in the right click context menu. So, I have a suspicion now with your feedback if I did that with the main (default) emulator it would behave as you mention here.

I think since I'm not able to click on a core through the right click menu, I try and instead click on "Retroarch TEST" as I named the emulator, nothing happens because I'm not really clicking on a selection that triggers a game launch. Probably makes sense it works like that. No Startup Screens pop up because I'm not engaging with LB properly to start the launch processes. I bet if made it the default emulator rather than an auxiliary one, as in I can use the normal Play button to start the game, Startup Screens should still pop up even though we know the game will fail to properly launch. 

[skizzosjt]

tried a new experiment tonight with another test instance of Retroarch, but making it my default emulator for SNES. if you have no core assigned and no parameters in the extra command-line parameters field, or the game specific custom command-line parameters field, you can in fact include the core parameter, or any parameter at that, on the default command line parameters field. games launched and other features worked as expected like Startup and Shutdown screens. so, not a very practical way to do this, you would need to have a separate instance for every core since you can only declare one core in the default field. I kinda ran out of time when I testing the other day, I def should have tried this then as I was suspicious about right clicking onto just the emulator name rather than the core name was part of behavior I saw. that's on me for not being more thorough, but there's only so much time in a day lol. so I have good understanding now of how all this works and what I come out of it is I just want better communication to users about why the field acts like it's disabled for any normal situation of use. typical users will likely find it confusing or frustrating. though I realized this whole situation within like 5 mins of first using the program, i just kinda left it as a "it is what it is" situation without understanding why I had to use the extra command-line parameter field or couldn't make use of the default command-line parameter field. I wonder if other users did the same thing as me. at least now I know why and that just makes me more confident in using this program to it's full potential for my evolving use cases