Bug with Assigning Save Location by Command Line in 1.3.6

RetroArch Windows devices
#1

I noticed a bug with assigning save locations on 1.3.6 on Windows 7 using the command line. Using the -s or --save command line modifiers in a script causes Retroarch to reset the save location to the default save location (rom folder). If a different save location has been assigned in the config, then using s or --save will override the config setting as well to use the default location.

System Details: Affected Version: Retroarch 1.3.6 (stable) / all cores I’ve tested OS: Win 7 Ultimate 64bit Method of launch: Autoit script

Assorted Notes: -Same script has been used for two years now without issue, so it’s not a problem with the script -Save state location can be assigned from the command line with -S without problem.

#3

I know for sure that the issue occurred in 1.3.6 with Snes9x Next and Mednafen PCE-Fast (the other cores I changed my setup to use the configs instead so I’m not sure if I tested the properly). I can also verify that “-s” used to work for Snes9x Next and PCE-Fast at least around RA 1.0.0.2 era when I originally setup the scripts I use.

I can understand wanting to depreciate it if it doesn’t work, but the command line option is really handy for people running RA on HTPCs/emuboxes where there are a ton of programs/scripts used to launch and control apps. Being able to specify the save location in the command line allows you to manage all your save locations in a big list of variables for your scripts so that you don’t need to dig through a bunch of configs every time you want to update the location. You also don’t need to worry about save location if your RA config gets corrupted or becomes outdated.

#4

I don’t see how digging through configs is any harder than digging through frontend settings. Using override configs or the Sort Saves/States in folder settings seems much cleaner than setting the folders for every core through command line switches.

#5

It really depends on your setup but I’ll agree to disagree with you on this (I can explain more about my setup if you want me to but I don’t think either of us convincing the other is material to the bug report).

What is important is that using the -s functionality as specified in the RA help page will actually interfere with the methods you listed (override configs) in the 1.3.6 build. For users with setups that date from before overrides and save sorting were added to RA, their setups will appear to lose their existing saves until they update their batch files even if they’ve already updated their configs to save to the correct location. They may not even notice for a while as save states work expected and they’ll actually need to load an SRM to have the issue.

I’m not saying we need to fix the -s implementation for every core, but if you do depreciate it, the change could be handled more gracefully so that people who use the -s functionality know that they need to update their configs.