Willy-JL / F95Checker

GNU General Public License v3.0
113 stars 17 forks source link

Game saves backup? #76

Closed SalehA-55 closed 1 year ago

SalehA-55 commented 1 year ago

Hey, can you add a feature to backup Game saves?

Allow to me explain my vision: You show the app where the game save folder is (just like how you assign the .exe file location). It then will copy the save folder to an already assigned "backup" folder (or it can be in the "Roaming\f95checker directory").

These are some ideas. And in case you decide to give them a shot, they don't have to be all implemented.

Thank you

FaceCrap commented 1 year ago

Well, actually the location of the game's local saves folder you wouldn't need to specify if you assigned the .exe file location, since it's always at the same location relative to the .exe file. I could see this as a useful addition, however, if you're on Windblows, there's already kind of a backup (mirror copy) of saves in %appdata%\RenPy\ structured in folders. The name of the folder however isn't always directly relatable to the game that made them. The actual folder name is set in options.rpy (look for a line starting define config.save_directory, the name of the folder is assigned to that variable. Every time you make a save, it's stored both in .\game\saves and in the options.rpy defined subfolder of the above mentioned user location. One thing to keep in mind, if you remove a game, including the saves subfolder and later install an update, the mirror copies in the %appdata%\RenPy\ folder structure won't be synced to the .\game\saves folder if you later install a newer version, consequently, only new saves will end up there.

Now, as to why it's going to be practically impossible to implement this with the current situation is because of the following: To determine the actual subfolder name in %appdata%\RenPy\ , F95Checker would need to be able to read options.rpy to get the value of the variable mentioned earlier. However, instead of the usual .rpy/.rpyc files, a lot of games come with .rpa files (and a very few even use a different extension) which are basically archives containing either both .rpy/.rpyc or just .rpyc files, together with the other game assets like images/audio/video. Now here's the first pitfall problem, depending on the RenPy version, these .rpa files use a different format. On top of that, the actual .rpy source files may not even be included. This means that for each different format, a different unpacker AND a different de-compiler needs to be included incase the .rpa files don't contain the needed .rpy files. Which brings with it a whole new set of possible problems. Just do a search in the forum for threads which have the word UnRen in their title...

The only way this might work is, if @Willy-JL would decide to ignore the mirror copies and create a backup of existing saves in the .\game \saves subfolder with a separate managing system. And there we get at the second pitfall problem. The moment he would decide that, a completely different risk will be introduced. And that is there's a real problem of ending up with saves not mirrored in the %appdata%\RenPy\ folder structure and possibly ending up with saves having the same name as exist in the mirror location but made at a different point in the game. The latter will cause very unexpected results on loading because it could restore a completely different situation than what you actually expected.

So, even though you think it might be easy to implement, there's a whole bucket load of hurdles that don't make it that easy...

Of course, it's ultimately up to @Willy-JL to decide the feasibility of your suggestion (which frankly speaking is a good one) but given the possible pitfalls and risk of the two save locations going out of sync by introducing yet a 3rd location, together with the problem of a not easily (read: very difficult) found folder name in the mirror location, I fear it won't be anytime soon.

EDIT: @Willy-JL Actually, there might be a solution to the whole issue surrounding the folder name in the %appdata%\RenPy\ user data folder. There's one file that is always readable, and which is able to overrule the save folder name defined in options.rpy... In the game's root folder (where the exe is located) there's a .py file with the same name as the exe. It has the following bit of code

    if save_directory is None:
        save_directory = renpy.config.save_directory

replacing renpy.config.save_directory with a custom defined name will overrule the name defined in options.rpy. So the folder name of the mirror copy would be a known item. The only problem is that existing saves will still be in the folder defined in options.rpy. So this will only work well for games that have never been installed before... Given that it will be near impossible for most users to find out the original name so they can move saves from that folder to the 'custom' folder, it's not a full proof solution. Also, IF (and that's a real big IF) you would actually somehow decide to implement something like this, AND decide to use this method, then personally I would very much appreciate a switch to disable this feature. Reason being that I use hardlinks and junctions to create a shadow game folder if a game has multiple paths I decide to play, and I use the .py method to force each 'path copy' to use it's own mirror save folder. Since these 'shadow copies' aren't managed by F95Checker other than via the .exe location, I suspect it might cause conflicts... but again, given the big IF...

SalehA-55 commented 1 year ago

Honestly, you have made many eye-opening points. And to be truthful, I am but a mealy simple user without any coding knowledge. But, the biggest issue seems to be the save folder location. To which I suggested that it can be user defined. Although, automating the prosses as you've suggested, is clearly a much better solution (i.e. the overrule method).

In terms of making it user defined, I feel that I haven't made it clear as to what exactly I mean, thus allow me to explain:

Ultimately, I may be missing a few crucial points, and in a little over my head here. As to the above mentioned concerns, a mixture of my suggestions and @FaceCrap, may have the the best possible outcome.

FaceCrap commented 1 year ago

@SalehA-55 I must admit that I totally overlooked the fact there's also non-Ren'Py games (I have made it a habit to simply ignore those). You are correct, those would have completely different save locations.

In hindsight, I don't expect F95Checker will ever acquire the option to modify the <exename>.py file directly. That would very much go beyond the scope of the program, plus, like you reminded me, this only applies to Ren'Py games, it's probably even harder to determine the save location for non-Ren'Py games, let alone to overrule these locations.

Manually entering the save file location seems then only viable option, but that still leaves the problem of finding out which folder in the %appdata% structure is associated with which Ren'Py game. Luckily the majority of the games I play(ed) use names that are easily recognizable, but there are those which use completely unrelatable names. What might be the easiest way for Ren'Py games is to enable the console so you can just query the config.save_directory variable. But that is also something easier said than done for most users I suspect.

As for non-Ren'Py games, I have only played 2 or 3 of those... and these don't even store their saves in the %appdata% folder (which normally points to C:\Users\%USERNAME%\AppData\Roaming\) but in a sibling folder at C:\Users\%USERNAME%\AppData\LocalLow\ Not much of an issue since %appdata%\..\LocalLow\ will put you there, and %localappdata% will give you the local folder (on the off-chance a game stores it saves there)

Still, it's going to be a helluva endavour to even come up with a solution given the pitfalls in identifying where saves get stored.

Willy-JL commented 1 year ago

yeah no thanks...

too many different formats to support for engines that im notinterested in myself, and most engines (and especially renpy being the most popular) already store in a user directory

also games tend to change config structure or inner workings between versions, so i dont think this is a good idea...