Overrides break retroarch.cfg

[another-sapiens]

Description

Whenever an Override is used (Core, Game, etc.), the config breaks. On a fresh re-install (deleting app data too), everything works correctly. As soon as an Override is used and RetroArch is restarted, problems start appearing.

Most noticeably, gamepads stop working correctly, and the UI changes opacity.

Looking into it, using any Override seems to be changing more values inside retroarch.cfg than intended. For example, the value input_axis_threshold goes from "0.500000" to "0.000000", despite never manually telling RetroArch to do this. Changing it back fixes the controller issues. Same thing happens with opacity.

Expected behavior

Overrides don't cause unintended changes.

Actual behavior

Overrides change values inside retroarch.cfg that the user didn't mean to change, possibly breaking input.

Steps to reproduce the bug

1. Install RetroArch 1.17.0 from Flatpak
2. Download cores and try a game
3. Change any setting, like turning on Rewind, and save an Override. Be careful, it might break your input.
4. Restart RetroArch
5. To make gamepads work again, retroarch.cfg must be deleted
6. To really see what is being changed, the pre-override cfg file can be saved to a separate place and compared with the post-override one. This is how I found out about input_axis_threshold.

Bisect Results

This only happens since the latest Flatpak version, 1.17.0

Version/Commit

• RetroArch: 1.17.0

Environment information

• OS: Fedora Silverblue (Linux)

[zoltanvb]

Can you check if the config changes are concerning values that have a floating point value, and can you tell what locale the system uses (LC_NUMERIC)? It may be a different version of #15756 .

[another-sapiens]

Strange... I unmasked the Retroarch flatpak to re-update it to 1.17 so I could test this out (I rolled back to 1.16 because of this bug). When I did, I ran flatpak run --env=LC_NUMERIC=C org.libretro.RetroArch and it worked perfectly (even after app restarts).

However, when I ran retroarch again (without setting LC_NUMERIC=C), it also worked correctly. Was something changed since this issue was opened?

In case it's useful: yes, my LC_NUMERIC is es_ES.UTF-8. However, the floating point values that are changed keep the . (dot) instead off replacing it with a , (comma), like the linked issue says.

Anyways, if the problem doesn't show up on my system for a few days, perhaps I should close this issue.

[zoltanvb]

No changes, at least not for this particular issue.

RetroArch config file should have the dot as floating point indicator always, irrespective of system locale, that is the correct way. The linked issue happened when another library invoked by RA set the locale to something else.

[another-sapiens]

I've been on 1.17 for almost a week with no issues. I wonder why the problem went away.
In any case, I'm closing this as solved, since I can't reproduce the bug.

Thank you for taking the time to respond!