|Go to Page...|
||Thread Tools||Display Modes|
|08/06/18, 09:56 AM||#1|
support more frequent write (only) of saved variables
Dear ZOS, one of the biggest pain points around addons, for me, is that the model of saving data only at the clean exit of the application leads to quite some pain when I care about the content stored in them.
As a concrete example, I have been using Notebook 2018 to keep a "travel journal" of sorts for my adventures in Tamriel.
On a couple of occasions I have had the game hang, and lost quite a few notes. Enough pain, for me, that I have started to simple /reloadui after writing one, which is rather uncomfortable, and definitely slows down and breaks up my gameplay experience.
To mitigate this I would propose two possible solutions:
Solution one, my preference, would be to add an API mechanism to permit an addon to signal that it has made "significant" changes, and would like to have them saved to disk. By making this an active request, it helps ensure that authors like myself can request a save when the variables are in a "good", consistent state, and ready to write. (Avoiding, for example, saving half the configuration changes the user has made, but dropping the second half, if the game was to crash.)
Solution two, far less optimal, would be to save more frequently: on zone transitions, or loading screens, or simply on a timed basis. This removes direct control from addon authors, but still delivers the primary benefit, which is that addon users are much less likely to lose their data -- or at least as much of the data -- in the event of a crash.
I see that in the past you expressed significant concerns about real-time communication with applications outside the game:
Given the existence of the /reloadui command as a facility to support writing data at an arbitrary time. A number of addons use exactly that method to ensure they "commit" results to disk - to the point that libSaveToDisk exists to automate the process under user control; examples:
Adding an API driven mechanism that allowed these addons to save their data in a less disruptive way to gameplay would not significantly reduce their ability to transmit data to external programs, though it would limit their ability to read it from them. (Which suggests that in the later case, they may retain the reloadui mechanism.)
The API driven mechanism would also, I would hope, encourage using a mechanism that could be appropriately rate-limited by ZOS, so that data is only saved as frequently as you judge appropriate. (For example, taking an appropriate copy of the data on call, but only writing it to disk every minute.)
API-wise, I'd suggest something like this as what I would personally find most valuable:
However, that high level abstraction could obviously be built by the community over a much simpler ZOS API, such as:
If you chose to implement rate limiting, then having an appropriate return from the low level function would be hugely valuable, to prevent foolish loops that call this every second or two. Even a boolean to indicate if it worked or not would reduce the likely pain of repeated calls into the runtime.
Alternately, an event to signal that the variables have been saved, and simply ignoring calls to write them during the period between the two -- with an arbitrary delay possible, making for natural rate limiting -- would also meet the needs; then the high level implementation would be more or less:
Finally, the purpose of this is to implement a user friendly "your data has a high probability of being safe" mechanism; making sure that we can effectively communicate the robustness to the user would have huge value.
Thank you for your time and consideration.
PS: also mentioned here on the official forums.
PPS: I am, as yet, unable to publish any code I have written to the ZOS addon API, as I am awaiting some internal processes at my employer to permit that. Forgive me making requests without published code to back them, please.
Last edited by SlippyCheeze : 08/06/18 at 04:51 PM.
|ESOUI » Developer Discussions » General Authoring Discussion » support more frequent write (only) of saved variables|