The Gold Road Chapter – which includes the Scribing system – and Update 42 is now available to test on the PTS! You can read the latest patch notes here: https://forums.elderscrollsonline.com/en/discussion/656454/
Maintenance for the week of April 29:
• PC/Mac: No maintenance – April 29
• PC/Mac: No maintenance – April 29
New addon auto saving feature clarification
cyx54tc
✭✭✭✭
based on the new API doc
1. If the addon's saved variables are too large (more than 50kb in size or more than 4ms to write) it will instead wait until the next load screen to do the work.
Question: by 4ms do you mean 400ms??? cuz I doubt that the open file API returns the handle within this time frame. Tested this with a 3kb file and nothing was written after 15min
2. An addon can request to be prioritized for saving, which is useful if you know that a change happened: RequestAddOnSavedVariablesPrioritySave(addonName)
Question1: Why is /script d(RequestAddOnSavedVariablesPrioritySave) returning nil?
Question2: When do we have to call this? Do we have to call this to get the auto save feature to work? Or does the auto save have a limit on how many saved vars it could save in one cycle? Whats stopping addons from abusing this function every time a change happened?
Question3: Instead of this function can we give users an additional checkbox to enable/disable this feature for selected addons and let them set the max time/file size for auto saving instead of hard coded it to 50kb/4ms? And then do the saving in a cycle style like addon1 -> addon2 -> addon3 -> addon1 -> addon2.
1. If the addon's saved variables are too large (more than 50kb in size or more than 4ms to write) it will instead wait until the next load screen to do the work.
Question: by 4ms do you mean 400ms??? cuz I doubt that the open file API returns the handle within this time frame. Tested this with a 3kb file and nothing was written after 15min
2. An addon can request to be prioritized for saving, which is useful if you know that a change happened: RequestAddOnSavedVariablesPrioritySave(addonName)
Question1: Why is /script d(RequestAddOnSavedVariablesPrioritySave) returning nil?
Question2: When do we have to call this? Do we have to call this to get the auto save feature to work? Or does the auto save have a limit on how many saved vars it could save in one cycle? Whats stopping addons from abusing this function every time a change happened?
Question3: Instead of this function can we give users an additional checkbox to enable/disable this feature for selected addons and let them set the max time/file size for auto saving instead of hard coded it to 50kb/4ms? And then do the saving in a cycle style like addon1 -> addon2 -> addon3 -> addon1 -> addon2.
0
-
Draxinusom_✭✭1. You misunderstood. The game (c-code!) now tries to save and if it takes too long postpones that. Prior to this mechanism, when you changed something in your addon (lua code) it will never get written until you exit the client (normally, not kill the process), log out to character screen or forced a UI reload using /reloadui. Otherwise it never got written. Now it does "background saves". The idea is to save data oportunistically so that if the client crashes or gets terminated there's a good chance the data was saved before.
2. Question 1: because the function only became available today with Murkmire patch. Question 2. You don't have to call it, the feature is enabled by default but you can request priority (for example you have a big text input box and the user just wrote a lot of text in it. It would be terrible if that is lost, so you now request priority saving. Note that nobody guarantees that you actually get priority, nor is there any deadline or timeliness on this). Question 3: I believe the game does already do some cycling by itself with no change needed by addon authors already.0 -
SlippyCheeze✭✭✭1. If the addon's saved variables are too large (more than 50kb in size or more than 4ms to write) it will instead wait until the next load screen to do the work.
Question: by 4ms do you mean 400ms??? cuz I doubt that the open file API returns the handle within this time frame. Tested this with a 3kb file and nothing was written after 15min
Most system call times run in the microsecond range, not the millisecond range, and the case of opening a file that has been previously opened should be nothing but a kernel file-cache check. Assuming, of course, that ESO doesn't simply hold the file open for the exact purpose of reducing that.
Encoding large amounts of data and writing it is really not as time consuming as you think, and 4ms should be more than enough time to encode and write most addons content without any real trouble.
Also, note that this just delays the encode/write cycle for a large addon until the next time you get a loading screen such as a zone change. Worst case data loss is now vastly less than it used to be, when it was "until you log out of the character".2. An addon can request to be prioritized for saving, which is useful if you know that a change happened: RequestAddOnSavedVariablesPrioritySave(addonName)
Question1: Why is /script d(RequestAddOnSavedVariablesPrioritySave) returning nil?
What environment did you run that in?Question2: When do we have to call this? Do we have to call this to get the auto save feature to work? Or does the auto save have a limit on how many saved vars it could save in one cycle? Whats stopping addons from abusing this function every time a change happened?
In order, never, no, kind of, and nothing. In detail, you never need call it, and auto-save just happens without you doing anything.
Autosave indeed has a limit on what it'll write out at a time, but the one visible to you is the one you identify in your first question: small data is written more frequently, large data during loading screens.
Any time-based spreading of save operations is invisible to anyone in the game.
[/quote]Question3: Instead of this function can we give users an additional checkbox to enable/disable this feature for selected addons and let them set the max time/file size for auto saving instead of hard coded it to 50kb/4ms? And then do the saving in a cycle style like addon1 -> addon2 -> addon3 -> addon1 -> addon2.
That is a terrible idea. Users don't have any meaningful basis on which to make those decisions, and since they directly impact the performance of the game (eg: by stalling addon activity, which must happen every frame, dropping frames) ...
Again, the limit on what "fast" saves do, as opposed to "slow" saves, is not really a huge thing.0 -
cyx54tc✭✭✭✭In an ideal world this would work just fine. But that just reminds me of the yield keyword that disappeared from modern programming language.
yield would end the current section and let other programs take control over the thread until yield was called. But this ended up with a disaster since everyone just want to take control for as long as possible and never called yield.
Same thing could be done here. An addon could just decide to call RequestAddOnSavedVariablesPrioritySave every 5s and be on the top of the queue. But if the write takes too long ESO client might just end the current save session and wait for the next one. (if all addons with < 50kb will be attempted per cycle then there would be no reason for the RequestAddOnSavedVariablesPrioritySave function) In the end no addon's saved var will get auto saved due to this.
So I believe it would be better if ESO just remove that priority queue and give each addon equal amount of chance to be written.
P.S. tried the API in PTS and it returned null. Havent tried live yet
Edited by cyx54tc on October 23, 2018 4:55AM0 -
BoarGulesSoul ShrivenI don't think this function exists as documented even with the Murkmire upgrade
/script d(GetAPIVersion() >= 100025 and RequestAddOnSavedVariablesPrioritySave)
reports nil.
0 -
Shinni✭✭✭RequestAddOnSavedVariablesPrioritySave is not a global function, it's a method of the addon manager.0
-
SlippyCheeze✭✭✭Same thing could be done here. An addon could just decide to call RequestAddOnSavedVariablesPrioritySave every 5s and be on the top of the queue. But if the write takes too long ESO client might just end the current save session and wait for the next one.
your speculation about the implementation is incorrect, and you are complaining about a problem that does not exist.0 -
Baertram✭✭✭✭✭Afaik not EVERY ADDON will AUTOMATICALLY use this new feature.
You need to add something to your addon's manifest .txt file if I remember correctly in order to "register your addoN" to use this function, and then call the function to try to do your SV updates.
The update to the SV will not be done THEN as you execute/call the function but within a timeframe ZOs has defined and designed (unknown so far).
So it's not meant to be used, and cannot be used, to update the SavedVars in "real time" to communicate between other addons and external programs! Forget this idea please!
Also SlippyCheeze is right. Your problem is non-existend and handled internally within ZOs code. Just don't spam the updates and use them wise for REALLY needed SV updates in order to make it work as intended.Edited by Baertram on October 25, 2018 10:41AM0 -
SlippyCheeze✭✭✭
I promise you that calling this a million times will absolutely *not* result in saving a million times. Really. Honestly.0 -
Baertram✭✭✭✭✭Pretty sure spamming it will just result in "no one able to use it anymore" so think before doing it
0 -
Solinur✭✭✭Chip mentioned there is a cooldown period for getting another priority request granted for an addon@Solinur Pact EU - PC (Solinur: Templar - Magicka DD, Moves-like-Günther: Sorcerer - Stamina DD, Kinara Sol: Templar - Stamina DD, )
Addon Author0