Saved Variables Bug and AddOns ToU
Okay, we have a couple more important things to let you guys know about that have resulted from the patch:
First, it seems that there has been a change (we think bug, but getting that verified) to the Saved Variables files, which includes your AddOns settings. Previously they were saved under your ["@username"]. It seems that they are saved under [""] now. What this means is that if you log into the game without having made the necessary change in your files, and if you didn't keep a backup of them, all your addon settings will be reverted to the default settings. If you haven't yet logged in, or if you have a backup of them, there is a fix you can use. All you need to do is:
If it turns out that this was a bug introduced with this patch and Zenimax reverts it, you'll be able to just drop your backup of the SavedVariables folder back in and be all set again. You did make the backup we told you to make, right?! Next, Zenimax has added an AddOn Terms of Use to the game. If you want to use AddOns in the game, you will need to agree to it before you can use them. The first time you click on the AddOns button in game it will bring the agreement up for you to accept. It reads as follows: Quote:
Authors, make particular note of the sixth bullet point:
|
zzz disclosures. Guess we have to add a readme :)
|
Quote:
It already used the "" marker instead of the @username There might actually be something intentional to resetting the files. I mean UTC does itterate over stuff like the ChatCategories, thier count might have changed so the old data is no longer valid. I do not actually mind them resetting UTC's saved var file. I might actually do that intentionally for the saved data when I update it. Quote:
|
FYI to other addon developers, it also appears that ZOS has introduced a limit on the maximum size of strings stored in saved variables. If your string is longer than (guessing, not verified) 2048 characters, it will be replaced with something like
Code:
["showTitle"] = true, |
Dumb Zenimax, they are ruined all my pleasure from game!
|
I'm not able to find out right now because I haven't finished downloading, but is there an issue when multiple accounts log in onto on machine ?
|
Quote:
|
I was able to "fix" the X4dChat mod just by commenting out the affected line, which doesn't seem to include code used anywhere else. But it included a reference to a global called "CHAT_CATEGORY_OUTGOING" which apparently no longer exists?
|
Quote:
I mean, it WOULD be an improvement, if done right... |
Quote:
There's no more separation between multiples accounts in the savedVars. Just the one [""] table, under which are the characters settings and only one accountWide table. |
Quote:
After the patch all the user addons use "" while ZO_ingame.lua is seperated by account ("@accountname"). That does imply the non-seperation of the ZO_ingame file was a bug. And when trying to fix it they flipped it around so now all user addons are affected isntead. I guess it was not that planned after all. On the other hand, if we can now do account seperation via code this would allow for limited cross account communication. But I figure this is a bug that will be fixed (unfortunately that fix means one more reset of the data in the future). |
arrrg i dont know what to do lol i run ALOT of addons like ALOT and i really dont want to edit 100 plus saved vars i REALLY hope this is a bug LMFAO
|
This has been known for a while that when a patch is released this can happen. It didn't start with this patch however, I've never seen it last this long. It also happens when they disable some of the in game social features. When TESO will start reporting the name again remains to be seen.
|
Quote:
|
Quote:
I am not author, but i use an addon from an author who left, and as so far it did not broke, i keep using it because this is the only one doing what i want, so to name it its Pawksickles (it changes the whole set of police of the game). So considering the above disclosure, should i add it myself to continue to use it? and if so, where should i insert it ? in the .txt already in the folder? or into the main lua? Or should i do nothing :) Thank you |
Quote:
|
Lucky for me all of the newer versions of my addons that were converted to standalone use a new Saved Variables process that didn't rely on your "@name" any longer, so most of them should be perfectly fine after this update. (I say this while not having had the chance to actually test it yet, thanks to my day job).
See this if you want to see through my crystal ball: http://www.esoui.com/forums/showpost...2&postcount=17 |
I've considered writing up a tutorial on saved variables without using the extra layer of API, but haven't had time.
|
I'm ashamed to say I didn't even know this was possible, and yet it seems so obvious now.
|
I think I may consider this option when I rewrite the saved variable layout in version 2 of my gatherer.
|
BACKSLASHES break it.
If you happen to have any important backslashes in your saved variable contents... ESCAPE IT TWICE. Or do some other magic.
1. Code:
/run MyAddonSV.something = "Blah\\blah" 3. View the SV file to see ["something"] = "Blah\blah" 4. Take your best guess what happens... Zenimax, there are quite a few good coders out there, would you PLEASE hire one..? This is just embarrassing... First the number-truncation (try to save the number 0.123456789 and see what you restore back, I bet it's 0.123456 which is not even close), then nil-comments with broken commas, and now this... :/ |
Hey,
I think this is a normal behavior. It's up to you to make sure that '\' is allways properly escaped. Quote:
local text = "Blah\\blah" d(text) you will get: Blah\blah Edit: On the other hand they are escaping " characters, so you may be right that they should also escape \. |
Alot of my .lua files, had [""] added as well as the ["@name"] still being there. For some reason, on a few its at the top of the file, while others it is on the bottom.
This leads me to believe, that if you did not backup your files first, they have not been overwritten. They are now reading the [""] instead of the ["@name"]. Both of them should be listed. Server down so I havent been able to test if it worked or not but it should! |
It's funny how everyone is like this happen b4 it's going to fix itself on the main forums, everyone is in the dark as to what's going on no official post bout the saved vars bug lol the PTS is still uesing account names too everything is inconsistent lol
|
1.2.3.
just checked after i did not have any setting on my addons. But did not found any addons saved files with the "" they still have the @AccountName ... ok found some [""] = That I did was Search&Replace [""] = to ["@OTHER"] = ( to get rid of some setting which might have been saved ) ["@Account"] = to [""] = ( to get my old setting ) (used TextCrawler to do that on all saved Files) PLEASE BACKUP YOUR FILES BEFORE THAT! |
Just noting another bug, though not so game-breaking...
Since hiding the lock icon on tooltips and switching to text for enchantment locks, the game incorrectly reports all items as not being locked. The 5th return from GetItemInfo returns false and the locked field in the data table on an inventory slot has false as well. |
If this was a "bug", as it has been so generously monikered, ZOS has had a great many hours to announce and make apology for the accidental disruption and deletion of data caused by their programming error, the User Account "" error. Nothing has been said.
This was no accidental oversight on the part of Zenimax. The "@nothingHereNow" combined with the borderline draconian additional TOS along with no API being delivered and utter and complete disregard of of basic industry standard of deprecation of functions (and more) - this wasn't an accident. At best, you can call it massive systemic corporate incompetence, but I think that's just playing the part of the naive apologist. Now, lest someone says "You should worry about fixing a problem and not waste our space - blah blah blah" - Accurately assessing the origin of a failure is an extremely crucial part of systemically isolating both the chain of events, and where/how errors were induced before you can begin to formulate methodologies to mitigate what's wrong now, and implement solutions to help prevent future failures. |
Just some news: Apparently this is part of the currently know issues, so it is a confirmed bug:
http://forums.elderscrollsonline.com...nown-issues/p1 The last entiry on the list reads: Quote:
|
Quote:
|
Quote:
Also, normally you would have such nice little things called unit tests and integration tests, which would have shown at least that issue, as it happens for everyone. And if they have a professional build environment (which I really hope they have, anything else would be highly unprofessional), it also wouldn't matter that it was not happening on PTS, as the final build that went live would also have it's automatic tests executed and would only show up as broken build because of failed tests. I really don't understand how something like that can happen. |
Quote:
And as such the first thing I understand is that if I were in thier situation I would have made the same or a similary serious mistake. They don't have to appologize. They don't have to explain. They are just fallible humans like I am. And stuff like this just happens with big updates in something that has the complexity of a MMO. |
Wish upon a star
Quote:
Including Build & Release Engineer and oddly a Producer I guess they ran out of monkeys. I didn't know my vanity pet was rescued from the ZOS dungeons of development and customer support. Makes me feel good to know that I fostered a code-slinging monkey that was rescued from a digital dungeon in Maryland. Disclaimer: No monkeys were abused in the production of the message or any add-ons I'm involved with. Not that I'm claiming ZeniMax Online Studios did; I don't speak for them, and they take my money every month. |
Quote:
|
Anyone know if the username is coming back (as it beeing a bug now) or not? (as it beeing removed on purpose)
Thanks! Cheers Sia |
Quote:
See the official Known Issues thread for it:
|
Thanks Sephiroth018 :)
|
Today farangkao gave me an idea how to deal with missing account name in saved variables or maybe I should say how to deal with broken GetDisplayName() function.
Just put this code to the main chunk any of your .lua files: Lua Code:
And voilà, your saved variables with @AccountName works again. |
It got already tested by the guy with 2 Accounts, and the 2nd account without Guild was also correctly displayed, once he saved his Account Name at the Login screen.
So there is a small chance the function will still return "" ,but for most cases it will work until they fix the function. |
Quote:
|
2nd Toughts about Garkin's Code....
I'm not sure if i see this correctly, but be aware, if you replace the default GetDisplayName() function, it might affect other Addons as well, and therefore make their Saved Data invalid. So before you distribute any Addon which replaces GetDisplayName() ,you should do some tests incl. some other Addons who saves their data. We don't want the End-Users to have a 2nd time frustrated about data-loss. If ZOS is fixing the Function ,it might end up being the same situation ,or they maybe consider to migrate autoamtically all "" data back to "@accountname" ... However , it might be possible with rewrite of GetDisplayName to automatically load the old Data and by reverting the function to the original to save it in the new container. Some tests are certainly necessairy before releasing anything to the public. |
Quote:
And if you put that code into multiple Addons, each of those would would verride GetDisplayName() again. Based on that data, this verison might be slightly better: Code:
--First get the current function We make a Addon just for this (call it "DisplayNameFix" or something like this) Users can choose to install it or not. And can prerpar thier settings files accordingly. We put this addon as OptionalDependency for all our Addons, so it runs before them (only nessesary if we need the DisplayName before the LoadedEvent/Settings loading). Once the issues is solved Zenimax Side, we can just make it a blank (empty the .lua file and remove the entry from the manifest, as well as). Edit: Noticed one mistake - we do not check if our retrival functiosn returns anything valid either. Each of those functions might bug out. I need to look into it a bit more... |
looks like they fixed it half-way. The @username is back in the SavedVariables file, but GetDisplayName still returns nothing... Also in the SavedVariables file they now add the same data twice once with the correct AccountName and once more with a blank username .. Anyhow, I guess my AddOn is a special case as I'm not using the SavedVariables file inside the game but use it to export data out of the game for another application to pick it up.
|
Quote:
|
Quote:
|
Quote:
It still keeps you old one around (just as if you logged in with a different account on same window user). It just cannot access it anymore because it does not look for the right account name in the table. Unless we force it too: http://www.esoui.com/forums/showthread.php?t=1904 At least as far as saved variables are concerned, this forces the proper Display name to be used. It is also designed to turn off the second the original GetDisplayName() starts working again. But it is still a pretty deep change on the client side so I have no idea what issues it might cause. You still have to modify the saved var files. But it will make the transition back a lot smoother and gives you seperation by account name back now. |
It must be accessing it somehow as my gatherer addon is still able to access ALL data in the saved variables file. I've logged in twice since this all went gaga and gathered a total of 10 items ( my addon still reports 600+ nodes have been found in places I haven't visited since the early days ). Even though the old data is under @Account and the new data is under "". It may just bypass the account name totally and just use the AccountWide table name to access the data within it in both account blocks. The one thing I do notice is that it thinks all nodes are new nodes now even though I know I have gathered from there before. I suspect the difference is due to how the data is accessed.
edit: Yep, my history is accessed directly rather than using the saved variables functions. Lua Code:
The downside that I see now is that it overwrites the newest "" data with the older "@..." data if it is later in the table or viceversa. I have literally put everything on hold with this addon until I see what they finally decide to do so that I can see what code I need to change. Quote:
|
When using the build in saved var function, the SavedVar file is ordered as following:
At the top/root you got a global variable*. It is the same name you gave in your manifest. Chances are that you could jsut directly read/write to this variable. If you use the default System, there is a table below the global. The first seperation is done by ESO accounts/login name. The next level is seperated between "Account Wide" and "Character Wide". For the acount wide section, the data just ordered by namespaces. The Character wide are first seperated by character name, then by namespaces. If you leave parameters blank some tiers might not appear. If you don't give a namespace (for example) there won't be a namespace tier. *It never occured to me before that this is just a global variable that get's dumped/read as whole during unload/UI load. If so accesing it directly might indeed be an option. |
Quote:
|
Quote:
If two people use the same computer/windows user profile to go online, the last you want is to mix up both players settings (or lump them together when they are indeed seperate persons) On the other hand, manually doing this allows your addon to overwrite the User delivered by GetDisplayName(). And share data Windows Account Wide. |
Good to Know :)
Especially if you like to write an Addon that Supports multiple Accounts (shared Data) you could then get all Data from all Accounts saved. Need to test this out. |
Because Users don't know to to want what is GetDisplayName() bug and wants theirs addons work without some work, here is a little guide to get your settings back :
So, ESO 1.2 introduce a bug called as GetDisplayName() bug, resulting the loss of your addon settings in June when this update was released. And as this bug has been corrected in 1.3, we lost our settings again. So if you got an addon with a whole bunch of datamining or personnalization, this could help : All you need to do is:
Do this for each of the addon .lua files that you have in that folder. Once you've done all of them, you should be able to log into the game and not lose all your settings now. Relog and try your addon again? If it didn't work, please replace your addon settings file from your backup. -------- PS: Okay, Your addon settings already got ["@Username"] First, please take note that is for advanced users only !
Example : Lines in red will be deleted, Line in green will be changed : Code:
SN_FS_SavedVariables = Code:
SN_FS_SavedVariables = |
Well explained, thanks Ayantir. :)
|
I've been gone for a while....you mean to tell me ZO still hasn't fixed this bug?!?
|
Quote:
|
When the bug happened I stopped ESO and took a break, hoping 3.0 would fix it, and I think it did! So I never went through all my mods to "fix" them but of course they are now way outdated, but at least the bug is fixed! :)
|
Okay. I misread Ayantir's post and thought he was still pointing out how to work around the original bug, not working around the bug fix. :)
|
My fix suggestion still stands and I honestly think more developers should switch to it.
I save everything to the variable declared in each addon's manifest. And I still filter by version number and character name. I do nothing at all with account names, because that's basically pointless. if manifestGlobalVarName == nil then manifestGlobalVarName = {} end if manifestGlobalVarName[<versionNum>] == nil then manifestGlobalVarName[<versionNum>] = {} end <youraddon>.GlobalSettings = manifestGlobalVarName[<versionNum>]["GLOBAL"] <youraddon>.Settings = manifestGlobalVarName[<versionNum>][<characterName>] <load your defaults if need be> <make sure to gsub() the ^ characters off the end of the character name> Done. I then save/load things in and out of GlobalSettings or Settings as appropriate. Works like a charm. Not a single addon using this method has had a saved variable problem since they switched to this system months ago (some switched more recently). |
All times are GMT -6. The time now is 05:24 AM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2014 - 2022 MMOUI