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: Lua Code:
However, that high level abstraction could obviously be built by the community over a much simpler ZOS API, such as: Lua Code:
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: Lua Code:
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. |
|
08/06/18, 10:04 AM | #2 |
|
If you want some insight in all this you can check out this thread
I gotta say, I'm a bit curious how code written for an ESO addon would somehow have *permission* issues with regards to real-world projects. |
08/06/18, 11:15 AM | #3 |
You are preaching to the choir. Check this thread. They are already working on something.
|
|
08/06/18, 12:14 PM | #4 |
What the addon API does is register C functions to be called by Lua code. If the underlying C code isn't written yet, there's no point in posting what the API function is going to look like.
|
|
08/06/18, 02:54 PM | #5 | |
|
|
|
08/06/18, 03:03 PM | #6 |
|
Yes but SlippyCheeze isn't adding anything "C-related" to the game so doesn't really apply here. I mean, it's his employer he's talking about.
|
08/06/18, 03:05 PM | #7 | |
|
I'd also be in the position where copyright would be retained by my employer, requiring a statement in the code to that effect, and I honestly don't want to deal with the oddities that would likely cause out in the wider world. The delay was getting the approval of a release covering ESO addons; it was hardly a controversial thing, but it was something that required waiting on the request to be looked at by a committee that meets infrequently. Now it is granted, I can touch anything related to any addon for ESO without blinking. At least, as long as it is in lua. So, it isn't exactly that I couldn't write code, it was that I couldn't release it without going through processes I didn't want to deal with. "Can't release" was a shorthand for this, honestly, over-long explanation. FWIW, depending where in the world you are, even without a written agreement on the subject, you are probably either subject to a "by default" assignment to your employer, or in a grey area where it isn't clear under law who owns those rights, if you are employed to produce software for a living, or anything like that. If you are a university student, I'd upgrade that to "are subject, 100 percent", everywhere I'm aware of. Universities are even more grabby than private companies. Government workers are also usually 100 percent subject to something similar, but the processes are fairly different. This is a horribly unclear area, and IMO subject to vast overreach, but I'd rather understand the problem area and work in ways that don't subject me to potential pain and annoyance later. |
|
08/06/18, 03:07 PM | #8 |
|
FINAL UPDATE: see http://www.esoui.com/forums/showthread.php?t=7901 instead of this thread.
|
08/06/18, 03:09 PM | #9 | |
|
|
|
08/07/18, 11:45 AM | #10 |
A lot of big companies have a blanket copyright claim to any creative work done by their employees mainly to prevent corporate secrets from leaking out. In such cases, they have legal right to order such work to be taken down without the author's consent.
|
|
08/07/18, 01:05 PM | #11 | |
|
As I noted below, it also is a grey area of the law: in many places, it isn't actually clear-cut if you personally own something if, for example, it might have been developed using knowledge that was part of your job, or does something substantially similar to a product of your employer. Those y'all can go to court and fight about, but there is no certainly if you, or your employer, would prevail. Most of this also applies to universities, and government agencies, not just large private companies. Though in the government case, it usually means that the government owns the content, and there are rules on release, but it more or less equates to "the entire country owns" than anything else. Anyway, point was, even though I'm really not a fan of this sort of thing, and I think it reaches far beyond what is reasonable, I can't just ignore the law because it is a stupid law. |
|
08/08/18, 09:54 AM | #12 |
My experience with this is limited, but I had a friend that worked the phones at a call center, definitely not a software development job, and they had a contract like this. This issue was one of the many things he constantly complained about.
|
|
08/08/18, 12:55 PM | #13 |
|
O_o now, that is definitely overreach, and I doubt a court would hold it up. but ... who has the $$$ to fight that out, eh?
|
08/09/18, 10:16 AM | #14 |
It's a contract like any other that involves signing over rights to your work. Court would definitely uphold it, but with small cases like these, it wouldn't even get that far. DMCA (Digital Millennium Copyright Act) notices don't require court action to be issued and most content hosting services obey them without any question. Think of these notices as a threat of a lawsuit if action is not taken.
|
|
08/09/18, 12:57 PM | #15 | |
|
It also depends on employment type; if you are a contractor or consultant, often the other party doesn't own the rights other than anything explicitly enumerated in the contract. Not applicable to that situation, but ... The law is complicated. Complicated law is totally not fun. |
|
ESOUI » Developer Discussions » General Authoring Discussion » support more frequent write (only) of saved variables |
«
Previous Thread
|
Next Thread
»
|
Display Modes |
Linear Mode |
Switch to Hybrid Mode |
Switch to Threaded Mode |
|
|