I can reproduce it. The issue is that the localStorage is getting too full to store the save file, which is about 150KB, out of the total 5MB that the browser can store. If you’ve been playing lots of things in Parchment then even if you haven’t been making lots of save files there could be lots of autosaves taking up space. Then when you try to restore, it fails because the save file is empty.
Parchment/Dialog could be storing data in localStorage much more efficiently, and it could be using IndexedDB, which has much bigger limits (over a GB I think), and it could also be evicting autosaves to make space. I have plans to make those sorts of changes, but they’re not short term plans, it will take a lot of work to get everything ready.
What can we do about this?
- We could make it remove autosaves to free up space. It currently doesn’t store dates for when autosaves were created/used, so we’d probably just have to delete all of them.
- Without changing the whole Dialog system, we could make it store files more densely. Each byte currently takes up about ~3.5 characters, but it could be compressed using base32768 into ~0.5 characters/byte. (I was researching this literally 2 days ago.) That’s an improvement of 7 times!
- Inform doesn’t check the results of
glk_stream_closeto see if bytes were actually written. I’ve reported this as a bug to the I7 tracker. But we should also check that GlkApi is returning 0 when Dialog can’t write to localStorage. If you wanted to change Counterfeit Monkey’s save code you could patch that part of the template layer. Actually if anyone did want to work on that, it could be made part of the 6M62 bug fixes extension.
Although I do want to overhaul how the Dialog system works in Parchment, I think it would be worthwhile looking at doing 1 and 2 before then. They would make a big difference to how much data can be stored even within the limits of localStorage’s 5MB.
Any thoughts @zarf on this?