You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I start this thread to see the interest from both users and developers in regards to improving the handling of savestates in RALibretro.
I've made a quick mockup to start the suggestion/discussion thread.
My thinking is it would be nice to have an interface for savestates as I've seen several devs talking about having to manually rename and place savestates into folders.
An interface like I made a mockup of above would for example:
Make it possible to rename savestate files
Place savestate files into Categories (either a predefined list or free text) (PS. This could perhaps also be used for naming folders and moving savestate files)
Comment field for each savestate
I also added mockup of possibility to set/change keybind on each savestate so a dev can choose which should have active keybinds.
There might be more fields that could be of interest here, but this is just to get the discussion started.
An XML (Gameid-Saves.xml example 12008-Saves.xml) could be kept in the Data folder.
This XML file could then contain the comments, category, keybinds etc.
The Md5 of savestate file could be used to make unique ID in an XML file.
Also if possible it would be nice to have an image for each savestate given that it supports saving screenshot when saving.
If there is a set limit of 10 savestate files that can be generated, this is kinda taken care of by renaming the savestate after it is saved as it will not take up the "savestate2..." filename anymore. (Am I right here?).
Also; If there is no way of loading savestates that are named for example "Boss 1.state" it could be done by RALibretro copying "Boss 1.state" to "whatever.name.is.needed.state" in a temp folder I am guessing.
Further along it would also be possible to have an Export button in my mockup that would put all savestates saved in the XML and the XML itself (and any potential related savesatete-screenshots) to be zipped/rar'd down and easily transferrable to other devs or as an asset for devs in the achievement sets themselves.
Anyways; I welcome people to join to discuss if this is indeed possible and/or a potential improvement.
The text was updated successfully, but these errors were encountered:
wimpyrbx
changed the title
Improvement Suggestion Thread
Savestates Improvement Suggestion Thread
Sep 16, 2020
I start this thread to see the interest from both users and developers in regards to improving the handling of savestates in RALibretro.
I've made a quick mockup to start the suggestion/discussion thread.
My thinking is it would be nice to have an interface for savestates as I've seen several devs talking about having to manually rename and place savestates into folders.
An interface like I made a mockup of above would for example:
An XML (Gameid-Saves.xml example 12008-Saves.xml) could be kept in the Data folder.
This XML file could then contain the comments, category, keybinds etc.
The Md5 of savestate file could be used to make unique ID in an XML file.
Also if possible it would be nice to have an image for each savestate given that it supports saving screenshot when saving.
If there is a set limit of 10 savestate files that can be generated, this is kinda taken care of by renaming the savestate after it is saved as it will not take up the "savestate2..." filename anymore. (Am I right here?).
Also; If there is no way of loading savestates that are named for example "Boss 1.state" it could be done by RALibretro copying "Boss 1.state" to "whatever.name.is.needed.state" in a temp folder I am guessing.
Further along it would also be possible to have an Export button in my mockup that would put all savestates saved in the XML and the XML itself (and any potential related savesatete-screenshots) to be zipped/rar'd down and easily transferrable to other devs or as an asset for devs in the achievement sets themselves.
Anyways; I welcome people to join to discuss if this is indeed possible and/or a potential improvement.
The text was updated successfully, but these errors were encountered: