So, I realize that config- and override-handling and how it should work has been a heated topic, as can be seen in old threads like this one over here, but still I want to bring it up again, since I can’t shake the feeling that the current behavior is a bit impractical still.
The problem: I have my main retroarch_main.cfg as well as an appendconfig that has just one line with the video_refresh_rate in it. The reason being that I have my RetroArch configured on a Laptop. Sometimes the Laptop goes into a docking station that’s connected to anoter Monitor - with a different refresh rate, of course. That’s where the appendconfig comes in, like this:
retroarch.exe -c retroarch_main.cfg --appendconfig overrideRefreshRate.cfg
All right, seems easy enough. When I’m running RetroArch on the go, I only use the main config, that sets the refresh rate to the laptop’s display. And when the laptop is docked, I just append the overrideRefreshRate.cfg.
Yes, this DOES work UNLESS override loading is enabled and additional override configs are found. If I remember correctly this is by design: As soon as overrides are enabled, they take priority. And that would be fine still. But the thing is even if the override-config doesn’t actually override the very setting that’s in the appendconfig, it still get’s canceled out. For example: As soon as I have a Super Mario World (USA).cfg that contains just run_ahead_frames = “2”, this override cancels out the refresh-rate-override from the appendconfig so that the video_refresh_rate value falls back to the one from the main config.
And that’s just odd behavior. Sure, I could create a second main config file that I use when the laptop is docked, but that seems unnecessarily complicated just to change one single setting and then have two otherwise identical main configs to maintain. I can see this getting messy quick.
One current workaround is pretty messy already: Delete the default retroarch.cfg next to the executable and then pass both configs as appendconfigs like this:
retroarch.exe --appendconfig retroarch_main.cfg|overrideRefreshRate.cfg.
Voila! Weird, but this results exactly in the behavior that solves the problem! Now even if there are overrides enabled and found, retroarch has no main config to fall back to and the values from both configs are respected. That’s great. Except now you can’t save any config changes anymore since retroarch fails to write to a non existing retroarch.cfg, bummer. And also if some day you accidentally just run retroarch without any parameters, it generates a new retroarch.cfg and the workaround stops working. So a less than elegant solution still.
Giving overrides priority is ok, it’s great even. But why does the sheer existence of an override cancel out ANY settings from an appendconfig, even if they are not actually overridden. It would be so nice (and logical and practical) to be able to combine the config, appendconfigs and automatic overrides.
And if there’s an elegant solution for my problem, by all means please do tell! Maybe there’s something I’m missing here. But as I understand it, an appendconfig is meant exactly for a special case like this, to change just one little setting but still use the same main config. And I don’t see the reason why it shouldn’t play nice with additional overrides, especially those that don’t in fact override a specific setting from an appended config.
All of this is on Windows 10 btw, but I suppose this fundamental behavior is the same on all platforms.