[ASR] Persistent Data
apple1417 opened this issue · comments
The game time can kind of be considered a variable - I vaguely remember some old conversations suggesting as much, and that you might even completely remove the timer and only track variables. The game time is persistent between autosplitter reloads (as long as you're not calling set game time). So why not variables too?
To start with, autosplitters will need to be able to read out the current value of a variable, and if the variable has been set at all. This basically requires #694, needing to parse strings to get data back out is nonsense. User space code would then be responsible for checking if a variable already exists before initializing it to it's default, and if so using that value instead.
Persistence could also solve all the issues with autosplitters which require tracking some sort of state. If all state is stored in persistent variables, then it can recover from being reloading in the middle of the run.
Discussion points:
- Do we want to handle more complex types? If you have a big struct with dozens of fields, extracting them into separate unique variables could be quite a pain, or what if you have an arbitrarily sized array? At the same time, handling any field containing a (wasm) pointer feels like a problem waiting to happen.
- When should variables be reset? Though I can't think of an example, it doesn't seem impossible for there to be situations you want something to persist over a timer reset - but at the same time there are certainly things you do want to reset at the end of the run. Do we want a difference between "per run" and "per livesplit session" persistence? What happens if you load two completely different autosplitters during the same run - or what if it's the same autosplitter, just with a small irrelevant change somewhere?
- Are all variables persistent? While you could simply ignore the stored value and overwrite it, are there extra implications to that? It might be nice to have explicit separation. And surely not everything persistent is something which needs to be stored in the split file?
In my opinion, variables are not the right solution to fix keeping state over reloads. If you try allow for it, you need to answer the above questions in awkward ways, which really feel like we're hacking onto a system which wasn't designed for it. It should be solved with a similar, but separate system. There should still be per-run persistent variables though, for things like death counters.
As an extension of the above, it might be nice to let users pick the initial value of (some) variables. This is really just asking for more settings types, but there could be some merit to automatically associating a setting with a variable.
The specific use case I have is in restarting the save-quit counter in Borderlands 3 after restarting my PC during a multi-day run with a single split - the current ASL implementation uses a counter component, which you can change the base value of. I realize this is a quite specific situation though, and I'm kind of using livesplit wrong, so not going to harp on about it.
Variables are specifically meant for the user to visualize information. I think if the auto splitter needs to store additional state, then it should be as part of the settings API, which is already semi set up to support settings that are not exposed to the user to be configured.
With #736 you can now freely store boolean, strings and maps in the settings. Is this sufficient to close this issue?
The one thing that might still be nice is some way to flag "internal, don't show this in the gui" - but I'm going to say yeah probably enough until a need actually arises
The settings map is not shown in the GUI. The settings map and the GUI are separate concepts as explained here: https://livesplit.org/asr/asr/settings/index.html#overview
The difference is also strongly highlighted in the debugger now:
(Note that the lolol and okok key have no equivalent in the GUI and also the opposite way, do none of the titles ever show up in the settings map)