Seed data versioning/history
AndreVolpi opened this issue · 4 comments
Hello, I often watch Ironmon runs on twitch and most of the streamers often want to see something related to the run that just ended, but they have just started a new seed and the tracker has thus erased the previous' seed information/data already.
I think a configuration to enable versioning of data and, when enabled, creating a file per seed (or maybe even for the last X seeds instead of being a boolean config) would make sense.
I have skimmed through the code and seems like an easy thing to make, I wanted to know if it's ok to go forward and code it up before forking the repo and so on.
Hey, appreciate that you opened the issue to talk about it before working on it!
I've admittedly thought a little bit about this, something along the lines of still having the current one named as it is but before making the new one just rename/copy the old one as something like "Previous_Kaizo_Autogenerated.gba" (or whatever the naming scheme is, i keep forgetting as i use batches myself lol).
There's an issue some people have which is ultimately down to user-error, but a feature like this would help mitigate the effect, where:
- They savestate mid-run, finish playing for the day intending to continue the run the next day / another time
- At some point before they load the savestate, they hit the quick-load combo and generate a new rom (whether intentionally or otherwise)
- They then load the savestate on the new seed, which does bring over the pokemon as it's in memory but will have different base stats on the new seed so upon levelling up the user sees the stats change by a drastic amount.
Having the previous seed available would then let them just load the right seed to continue the run in most cases.
Easiest implementation off the top of my head is just adding to the io.popen call that runs the command calling the randomiser CLI, to just make a copy of the existing file before calling the randomiser. But if you have a better implementation in mind then i'm absolutely open for it (i've only just slightly thought about it).
We don't want to go down the route of doing this for every seed, as then that makes the user responsible for managing the files in the folder as they begin to grow with more and more seeds (we'd like to avoid the average user going into the tracker folder to delete stuff if we can, cus they might delete something they shouldn't), I guess storage space as well could be a concern longer term but gba roms don't take up much space.
Not sure how useful last X seeds would be, given the reasons for implementing such a feature are resolved with just saving the previous one, unless perhaps it was a setting the user could define and defaulted to 1? (so that those that would find it useful to have the last 3 or 5 or whatever X seeds can make use of it)
In short:
- I agree it'd be a useful feature for the reasons both you and I mentioned.
- Definitely want some limit on how many seeds are stored to not clog up the folder with a lot of files.
- Don't know how useful it'd be to save more than just the previous seed, but i'm open to a last X seeds user-customisable option potentially if there's space to put such a setting (finding space for settings is always a pain lol)
- Don't know if we'd need a setting to toggle whether it saves the last seed or not, though no harm in it i suppose. I think it should be on by default though to help with the issue I mention above
Worth noting that there's also always the option for the user to manually make a copy of the seed / log somewhere out of the tracker folder if there's a particular seed they want to save long-term.
The save X option I considered would basically be saving every seed as name-pattern-seed#.*, checking the current seed number and deleting the Xth behind one. Example: User loads the seed number 31 and has chosen to save the last 5, the tracker copies current file to the file ...-seed30.* and deletes the file ...-seed25.* (and then goes on doing the same stuff as now).
#283 with the one seed backing up option, as none of the runners I talked to felt the need for more than that. (for now people who want that can make batches I guess)
Closing as completed for 7.0.0 (releasing soon). Thank you again.