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
Currently, the way the libretro core version of EasyRPG Player handles the savefiles for each game is just like standalone: the engine generates these files (for instance, "SaveXX.lsd") inside the game directory itself.
While this is an understandable approach, it makes this core one of the few that ignore the savefile directory as indicated by the user under Settings -> Directory in RetroArch. This also has the drawback of making it difficult to backup these saves automatically through an external cloud service, such as Dropbox, since in order to preserve those savefiles the user would have to put the entire game directory on the cloud server beforehand.
What would be useful is a core option that allows to define the core behavior with regards to savefile positioning:
Default - core generates and keeps the savefiles inside the game directory, just like it does right now;
Libretro - core creates a sub-folder named after the content (for instance, "yume_nikki" if the file loaded is "yume_nikki.easyrpg") inside the savefile directory defined in Settings -> Directory ("for instance, D:\Dropbox\Saves\yume_nikki"), then stores the savefiles (Save01.lsd, Save02.lsd, etc.) and loads them from that folder.
Just to clarify, this is different from #32, since that one was about requesting the implementation of savestates, but here I am referring to the normal savefiles created by the engine during regular gameplay.
The text was updated successfully, but these errors were encountered:
when you use this ".easyrpg" naming this will be indeed simple.
The case that makes this kinda complex is when the game is called "RPG_RT.ldb", in that case RetroArch will tell the core "Your Savefile is 'RPG_RT'". Oh great RetroArch, this is completely useless!
This is also the reason why I didn't implement this yet: I'm not sure how to prevent this conflict with the RPG_RT file.
Now that I think about it... An easy solution would be to reject saving in the libretro dir (and always use the gamedir) when the content is called "RPG_RT".
You read my mind! I actually wanted to suggest that same workaround, but then I omitted it thinking it would be best left to the developer's preference. :)
Yes, a solution that could potentially address this nuisance is:
if the content loaded is named "RPG_RT", default to normal behavior even if the core option is set to "Libretro";
otherwise, if it's a .zip or .easyrpg file that is being loaded, if the name is not RPG_RT and if the core option in question is set to "Libretro", place the savefiles in a similarly named subfolder within the savefile directory as set by the user.
Hi @Ghabry, is there by chance any update regarding this request?
No pressure intended, as usual! I was just wondering if you had time to look into it, as it would make syncing saves through an external cloud service so much easier.
Currently, the way the libretro core version of EasyRPG Player handles the savefiles for each game is just like standalone: the engine generates these files (for instance, "SaveXX.lsd") inside the game directory itself.
While this is an understandable approach, it makes this core one of the few that ignore the savefile directory as indicated by the user under Settings -> Directory in RetroArch. This also has the drawback of making it difficult to backup these saves automatically through an external cloud service, such as Dropbox, since in order to preserve those savefiles the user would have to put the entire game directory on the cloud server beforehand.
What would be useful is a core option that allows to define the core behavior with regards to savefile positioning:
Just to clarify, this is different from #32, since that one was about requesting the implementation of savestates, but here I am referring to the normal savefiles created by the engine during regular gameplay.
The text was updated successfully, but these errors were encountered: