Retroarch: Incremental Save State limitations?
Description
This isn't necessarily a bug but rather a question about functionality that could lead to bugs. I'm have the incremental save turned on for an emulator, so whenever I save state it increments to a new slot. How high does this go? I have am up to several hundred save slots on certain games... Does it ever end? If not, will this eventually cause space issues on my drive?
Or does it eventually go back to slot 0? Is there any more detail about how this works? Or does it literally just increment to infinity?
If it doesn't reset to slot 0 by itself is there a way to manually do this in order to avoid running out of hard drive space? I know the save states take up minimal room, but I'm running a Raspberry Pi and my SD card is very close to maxed out.
I've tried search for more details on this topic but I haven't found hardly anything beyond people explaining how to enable the incremental save state feature.
Environment information
- OS: Raspberry Pi (RetroPie)
Jakobud
All 7 comments
Its infinite, the actual number is 2147483647 as fr500 said, but by that point your savestate button would have eroded from friction, your drive would be full and you would be dead(based on pushing save once every 2 seconds).
meepingsnesroms
on 29 Jan 2018
Hmm but if you literally only have < 50mb of free space on your system isn't it kind of a bad idea to have a save state system that will eventually max our your drive? Is there really no option to specify a max or to have it eventually wrap around to zero?
Jakobud
on 29 Jan 2018
I can fix that, if you just want a buffer of the last X savestates it shouldnt be hard to add an option.
meepingsnesroms
on 29 Jan 2018
@Jakobud I don't think it should be RetroArch's job to play hard drive police. It's the user's responsibility to monitor their space usage... and I think wrapping around and overwriting existing states is quite dangerous and we shouldn't do that.
bparker06
on 29 Jan 2018
I understand. But I wouldn't call anything like that dangerous as long as a user understands what he's doing when he's enabling the option. I mean, pressing the DELETE button could be equally be considered dangerous but not as long as the user understands it.
I was just thinking some sort of option like "Limit incremented save states to 10" or some user-definable value. Sort of like a garbage collection cycle for save states if that makes sense.
The incremental save states is a very nice and helpful feature. I use it all the time. The primary reason I started using it was because I was playing with a single save state for games for a long time. But then one time I accidentally hotkey reset the game and then saved the state. Lost who knows how much time on that game from that. That's when I discovered the incrementing and turned that on right away.
The reality is that when anyone saves their 493rd save state when playing a long game like Final Fantasy (or whatever) that user is never ever ever going to care about the first roughly 480 save states they made. They will never use them or go back to load them. They really only care about recent save states. The old ones are just files filling up space. They served a purpose at one time but in almost every case will never be used again. At this point though its easy to start maybe going down a path where manually saved state slots are different than auto-incrementing save slots. That thought process sounds like another can of worms though.
I might end up just writing some sort of cron script that deletes old save states or something just based on the file name. If you have the following saved states:
gamename.state5
gamename.state6
gamename.state7
gamename.state8
gamename.state9
gamename.state10
gamename.state11
gamename.state12
Will the next save state be .state13 or .state1? What I'm wondering is does the system look for the highest number and increment it or does it look for the lowest non-existing save state and use that and fill in the gaps?
Anyways, just my two cents. Thanks! Love Retroarch. I've been playing with emulators since around 1997 but never heard of RetroArch or libretro until falling into RetroPie. Keep up the good work :-)
Jakobud
on 30 Jan 2018
But then one time I accidentally hotkey reset the game and then saved the state
We also have an "Undo Save State" feature that would have probably solved that particular mishap as well.
bparker06
on 3 Feb 2018
Oh is that another hotkey you set? Or where is the documentation for this?
Thanks,
Jakobud
on 4 Feb 2018
Related issues
wrldwzrd89
路
3Comments
RobLoach
路
3Comments
Chocobubba
路
3Comments
danabnormal9000
路
3Comments
parkerlreed
路
3Comments
Most helpful comment
I understand. But I wouldn't call anything like that dangerous as long as a user understands what he's doing when he's enabling the option. I mean, pressing the DELETE button could be equally be considered dangerous but not as long as the user understands it.
I was just thinking some sort of option like "Limit incremented save states to 10" or some user-definable value. Sort of like a garbage collection cycle for save states if that makes sense.
The incremental save states is a very nice and helpful feature. I use it all the time. The primary reason I started using it was because I was playing with a single save state for games for a long time. But then one time I accidentally hotkey reset the game and then saved the state. Lost who knows how much time on that game from that. That's when I discovered the incrementing and turned that on right away.
The reality is that when anyone saves their 493rd save state when playing a long game like Final Fantasy (or whatever) that user is never ever ever going to care about the first roughly 480 save states they made. They will never use them or go back to load them. They really only care about recent save states. The old ones are just files filling up space. They served a purpose at one time but in almost every case will never be used again. At this point though its easy to start maybe going down a path where manually saved state slots are different than auto-incrementing save slots. That thought process sounds like another can of worms though.
I might end up just writing some sort of cron script that deletes old save states or something just based on the file name. If you have the following saved states:
Will the next save state be
.state13or.state1? What I'm wondering is does the system look for the highest number and increment it or does it look for the lowest non-existing save state and use that and fill in the gaps?Anyways, just my two cents. Thanks! Love Retroarch. I've been playing with emulators since around 1997 but never heard of RetroArch or libretro until falling into RetroPie. Keep up the good work :-)