[Feature Request] Create option to include core name/version in save state filename

[odditude42]

For save states which are handled by the libretro interface, options should be added to have save state filenames to include the core name and core version, delimited by character(s) or pattern(s) deemed least likely to cause collisions.

Justification:

1. Prevent user confusion when trying to load a state created by a different core (leading to failure for unknown reason).
2. Prevent data loss from clobbering a save state created by a different core.
3. Allow users to the ability to identify with a glance at their states folder whether or not they need to lock a core from being updated
4. Allow the frontend to display a toast notification (optional) indicating a mismatch with the core version the state was created with, a common cause of user confusion.

Arguments against:

1. Most users will not switch between multiple cores for the same system.
   • Users bugtesting cores will likely directly benefit, as they can have identically-indexed save states in multiple cores for comparison testing.
2. Metadata should be encapsulated in the file header, not the filename.
   • Agreed on principle, but:
     1. End users can't identify the source of savestates from their file manager.
     2. A more complex feature would need to be programmed into RetroArch to allow reviewing that information, and it would still be less convenient to the end user.

A discussion would warranted on whether or not it would be useful to have (optional) warnings on loading legacy states without the core version tag present if version tagging is enabled.

[miguedevel]

Isn't this already covered by the option named "Sort Save States into Folders by Core Name" located under Settings - Saving ?

[odditude42]

@miguedevel you're absolutely right, for the core name portion at least.

the core version portion remains relevant.

[miguedevel]

@miguedevel you're absolutely right, for the core name portion at least.

the core version portion remains relevant.

True. So, would creating a subfolder with the core version number under the core's name work as an implementation?

[odditude42]

Possibly, although that could lead to "disappearing" savestates after a core update - trading one source of confusion for another.

A possible solution there would be to update the state loading code to:

1. Check for presence of a ignoreoldstates flag in the (global/core) config.
2. If the flag is not present, check for presence of previous savestate version folders.
3. If previous folders exist, iterate folders in reverse order checking for state with matching index.
4. If state with matching index exists, provide the warning described in (4) above and provide options to:
   1. Attempt to load state
   2. Cancel load state
   3. Cancel load state and ignore older states going forward (sets ignoreoldstates flag)

The above would assume that sorting by version is enabled by default, and would provide a reasonable UX for newer users. The flag could also be exposed in the menu alongside the sort-by-version setting for direct configuration.