RetroArch doesn't save changed values that are already set in an included config

[Brunnis]

Description

See https://retropie.org.uk/forum/topic/28346/configuration-via-rgui-partly-broken

If we have a custom config with

#include /opt/retropie/configs/all/retroarch.cfg

changing an option that is set in the config above in RGUI and using "Save current configuration" from RGUI will not save anything.

Expected behavior

Any setting that was changed compared to the base config file or the included config file is saved in the base config file.

Actual behavior

The setting is lost, i.e. not saved in the base config file or the included config file.

Steps to reproduce the bug

1. Create an otherwise empty retroarch.cfg file that includes the default retroarch.cfg
2. Start RetroArch and change a setting that is present in the included config file
3. Choose to save configuration to the current config file from the RetroArch main menu
4. Restart RetroArch. The setting that was changed is back to its old value.

Bisect Results

Bisected to libretro/RetroArch@9eb8472

(credit goes to @joolswills for bisecting the issue)

Version/Commit

Tested on RetroArch 1.8.8 and 1.9.0. Same behavior.

Environment information

Tested on Linux and Windows 10. Same behavior.

[Brunnis]

@jdgleaver Just mentioning you to make sure you've seen the issue, since you might be the one best suited to take a look at it.

[jdgleaver]

What you are seeing here is the correct behaviour - any config values set via an #include directive are defined to be read only. This has always been the case, but before https://github.com/libretro/RetroArch/commit/9eb8472 RetroArch was incorrectly creating duplicates when attempting to set read only values, which was in fact causing undefined behaviour.

The real issue here is that RetroPie is handling things incorrectly. If it wants per-system config settings that can be modified by the user, then it should be employing regular config overrides (which can be saved per-core). Empty configs with #include directives constitute unnecessary obfuscation...

I guess I can change the code such that 'setting' a read only value creates a sort of override. This would have a performance impact, but maybe it won't be so bad. I'll look into it.

[jdgleaver]

I found a simple workaround - this should solve the problem: #11540

[joolswills]

It was many years ago when RetroPie decided on this way to have per system configs (which can affect multiple cores) - a long time before core overrides etc (afair) - I agree it's not ideal now - we do suggest users don't save configs and use overrides.

However your workaround is perfect and will resolve the issue and in fact improve the situation if users do save configs, while still allowing manual per system configs that can be set per system.

Thanks very much for sorting this. I will give it a try.

[jdgleaver]

You're welcome!

It turned out to be an easy sort of fix with no downsides, so it's all good in the end :)

[Brunnis]

Very nice! Thanks a lot. 😃