user story: starting a new game, where you intend to use playset preserver, but you're indecisive about the mod set and you keep changing your mind about which mods to include while looking at game rules, custom character, or day 1 - but every time you change the playset a little, you have to delete and recreate the preserved playset, which is annoyingly slow for a big playset.
user story: playset debugging, where your playset is crashing, and you are constantly disabling and reordering and reenabling mods and relaunching the game only to crash for the 15th time. since preserved playsets reportedly speed up game startup by ~30-50 seconds on some machines when mod count is high, there is potential usability here but is hampered by the tool's current inability to update preserved playsets (you have to delete and reinstall, which is a lot of redundant wasteful disk I/O for a small change to the playset, too slow to be worth it for testing playset crashes.)
user story: a user wants to start a new game, but isn't sure if their old preserved playset is missing any new updates. if you make a second preserved playset, there's no simple way to tell if it's identical to the first one or not. a user who only uses preserved playsets with ck3 may want to easily "check for updates." [this user story is more distinct from the first two, maybe a separate issue]
so: enable the tool to overwrite an existing installation.
various ideas for how it should work:
- to update a preserved playset, you follow the same sets of prompts as you do for creating a new one; only, instead of refusing to overwrite an existing folder, the tool will offer to update it if it's a preserved playset. this makes the tool basically idempotent, which is nice.
- alternatively, we could make the first prompt be "create or update?" which would make the updating case a nicer user experience, especially if the user uses a non-default name for the preserved playset but e.g. he typos it the second time. this is probably superior UX. we could actually check if there are any existing playsets and if there aren't, skip asking about update.
- by default, it should make no assumptions about the state of the playset, the mod files, or the existing playset definition, except that if the file2mod_map.txt file is present, it can be relied upon about which file came from which mod.
- but the user is prompted, and if he agrees, the tool can assume the input mod files have gotten no updates (e.g. because the last playset was generated 2 minutes ago) and the old preserved files have not been manually changed. this would mean no files would have to be read, except the copying of the specific new files, which would be nice and fast for rapid debugging.
- we could store file checksums in the file2mod_map.txt, and just assume (or prompt?) the user hasn't manually edited any preserved files to invalidate them. that would mean we could check for mod file updates by reading half as many files (we could skip reading the preserved files).
- alternatively, we could just rely on file mtimes to see if any mod files (that aren't overridden) are newer than preserved files. (but be careful! e.g. if a mod updates such that a file is deleted, it could mean that an older file from another mod now needs to overwrite a newer file in the preserved playset)
- (also, in theory, a mod could update something like
replace_paths, or its name as used by file2mod_map, and this shouldnt break things)
- alternatively, we could open every file and compare it to what it should be. maybe we can package rsync or something faster than python at this task..?
- the viability for these various options is based on how slow they actually are; it's not worth it to make it only 10% faster if the user now has to think "well, i hope a mod didn't update literally just now and i'm not going to bother to check, but now i have a little doubt about it and i only trust the tool's output 99% now instead of 100%"
- note that there are two basic use cases and they shouldn't be confused:
- the playset was changed but the mod files (probably) did not receive any updates (rapid playset editing scenario)
- the playset was not changed but the mod files might have been updated and we want those updates
- if playsets are "supposed to be updateable" probably the default playset name shouldn't have a date on it. (though the full date & time should be in version.txt.) but of course the new playset can't just have the same name as the source playset so what do we put for a suffix? "(preserved)"?
user story: starting a new game, where you intend to use playset preserver, but you're indecisive about the mod set and you keep changing your mind about which mods to include while looking at game rules, custom character, or day 1 - but every time you change the playset a little, you have to delete and recreate the preserved playset, which is annoyingly slow for a big playset.
user story: playset debugging, where your playset is crashing, and you are constantly disabling and reordering and reenabling mods and relaunching the game only to crash for the 15th time. since preserved playsets reportedly speed up game startup by ~30-50 seconds on some machines when mod count is high, there is potential usability here but is hampered by the tool's current inability to update preserved playsets (you have to delete and reinstall, which is a lot of redundant wasteful disk I/O for a small change to the playset, too slow to be worth it for testing playset crashes.)
user story: a user wants to start a new game, but isn't sure if their old preserved playset is missing any new updates. if you make a second preserved playset, there's no simple way to tell if it's identical to the first one or not. a user who only uses preserved playsets with ck3 may want to easily "check for updates." [this user story is more distinct from the first two, maybe a separate issue]
so: enable the tool to overwrite an existing installation.
various ideas for how it should work:
replace_paths, or its name as used by file2mod_map, and this shouldnt break things)