Enable configgen to parse unique config entries based on relative path

[udance4ever]

Summary

Enables configgen to parse relative paths in batocera.conf and handle 2 cases:

1. Software with multiple media formats (eg. disk and cassette): Batocera user config does not hash on both softName and media Type #11781
2. Multiple MAME rom sets (MAME, MAME2010 and MAME2003+)

PR is paired with Enable ES to save unique config entries based on relative path

Both PRs will be pulled out of draft when it is confirmed configgen and ES get along well with their mutual changes :)

Testing

game_settings_name in es_log is correct:

2024-06-30 02:59:27,707 INFO (Emulator.py:87):game_settings_name game settings name: cas/zonx.zip

and configgen successfully parses the following options in batocera.conf and uses the correct software list for the same software name "zonx":

coco["zonx.zip"].softList=coco_flop

coco["cas/zonx.zip"].softList=coco_cass

Upgrade

TODO: A post upgrade script would check batocera.conf for any ROMs at level depth of 2 or greater (relative to /userdata/roms) & update those entries with relative paths.

[Hew-ux]

Batocera should maintain compatibility across versions. It is like a firmware, and users should be able to freely go back and forth versions without alteration to their userdata.

The solution here would be to accept absolute paths in addition to relative paths.

[udance4ever]

Batocera should maintain compatibility across versions. It is like a firmware, and users should be able to freely go back and forth versions without alteration to their userdata.

I totally strive for this ideal!

is this really realistic though? it's similar to making schema changes in a database. we recently moved psvita data from system to saves and it would require a script to reverse the process to run psvita games from system again in an older release. this is just one example - rpcs3 is another that we've refactored.

The solution here would be to accept absolute paths in addition to relative paths.

is this a solution because one could have absolute paths in their config file so it would be a universal reference across versions of Batocera Linux?

[nadenislamarre]

exceptioonally we can break some thigs sometimes, mainly to "fix" while on long term, it seems a good point.
however, modifications have to be done in es too, and i guess it has impact on retrobat too,
not easy task to complete

[udance4ever]

modifications have to be done in es too, and i guess it has impact on retrobat too

The change to ES was pretty trivial thankfully:
udance4ever/batocera-emulationstation@b23270d

@Tartifless will the above commit impact RetroBat? I noticed RetroBat uses it’s own XML config file so I’m thinking no?

but if so, I can put a #ifdef around it.

[Hew-ux]

we recently moved psvita data from system to saves

You are correct, and that was bad practice (preferably, the system should have been patched from the get-go to accept our standard paths). There is a difference however, as although the user on the newer version of Batocera would be able to start using the new savefile location with the new Batocera version, they could still go back to an older version and the old save files would still be there, as they were not touched by the firmware. While your proposed upgrade script would have moved those files, and further complicates people needing to move back and forth for testing purposes (for instance, they are testing for a regression for another system, but once returning to the new version their old save files are now moved by the script unexpectedly and they don't discover this until way later).

A compromise would be to accept the changed behaviour (invalidating old keys) and informing the users in the community spaces/changelog about the changes, leaving the older keys alone. The top priority is that we avoid altering userdata without interaction where feasible. (eg. a lot of configgen lines don't detect for a specific string, but pass-through whatever is present to the emulator, so future versions can retroactively pass strings to older versions without needing any scripts). You'll actually see many people still having the comments from Batocera 5.27 in their batocera.conf files because we don't routinely wipe it.

The solution here would be to accept absolute paths in addition to relative paths.

is this a solution because one could have absolute paths in their config file so it would be a universal reference across versions of Batocera Linux?

Correct. That is, users who set the config the older way would still be able to carry over their settings while newer users could use the newer format. But more precisely, it doesn't break in newer versions with the same config file. Of course, this is not always feasible, but with a bit of elbow grease I think this one would be (could be just as simple as detecting a / at the stat of the string).

[nadenislamarre]

there is a possibility to do this pr at the same time we do an other one : create a file batocera-games.conf to remove game pollution from batocera.conf.
we untouch batocera.conf, and when we create batocera-games.conf, we copy batocera.conf and fix values.