ESOUI - Saved Variables Bug and AddOns ToU

ESOUI (https://www.esoui.com/forums/index.php)

- News (https://www.esoui.com/forums/forumdisplay.php?f=5)

- - Saved Variables Bug and AddOns ToU (https://www.esoui.com/forums/showthread.php?t=1843)

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:

Go to your Documents folder (the same one that you had to use to install your addons)
Go to your Elder Scrolls folder
Go to your Live folder
Go to your SavedVariables folder
MAKE A BACKUP OF THIS FOLDER!
You should see a listing of files for each addon you used. They will be named [AddOnName].lua
You can open those files using any text editor (I'd say just use NotePad). Right click the file name, choose Open With and pick whatever editor you want to use
Somewhere close to the top of the .lua file will be a line that says ["@Username"]
Change that to replace ["@Username"] with [""].
Save and close.

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.

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:

ADD-ON TERMS

ADD-ONS
The creation and use of Add-ons are subject to the Add-on Terms of Use, available below and at https://account.elderscrollsonline.com/add-on-terms. Among other things, the Add-on Terms of Use specify that:

ZOS is not responsible for any Add-ons, or the Game if You download and/or use an Add-on; YOU USE THESE AT YOUR OWN RISK;

ZOS will not provide customer support on any Add-ons or Your Game product if You download and/or use an Add-on. Disable all Add-ons prior to contacting Customer Service;

Your Game may not function properly as a result of downloading and/or using Add-ons.

Any Add-ons and/or files that appear to be Add-ons that You download could contain malicious code that could affect Your system. ZOS is not responsible for any such malicious code or the performance of Your system as a result of such malicious code;

ZOS RESERVES THE RIGHT TO CHANGE THE API AT ANY TIME, OR TO DISABLE AND/OR RESTRICT ANY ADD-ONS AT ANY TIME; and

If you create an Add-on, You must include the following disclosure in a Readme or similar .txt file: "This Add-on is not created by, affiliated with or sponsored by ZeniMax Media Inc. or its affiliates. The Elder Scrolls® and related logos are registered trademarks or trademarks of ZeniMax Media Inc. in the United States and/or other countries. All rights reserved."

As a reminder, Your use of the Game is subject to the Terms of Service available at https://account.elderscrollsonline.com/terms-of-service, Privacy Policy available at https://account.elderscrollsonline.com/privacy-policy, and the Code of Conduct available at https://account.elderscrollsonline.com/code-of-conduct, and supplemented by the End User License Agreement available at https://account.elderscrollsonline.com/eula. The Add-on Terms of Use is a "Supplemental Terms" as defined in the Terms of Service and are incorporated by reference.

ADD-ON TERMS OF USE

These Add-on Terms of Use ("Add-on Terms of Use") are entered into by and between ZeniMax Online Studios LLC ("ZOS") and You, an individual ("You" and "Your"), and govern Your creation and/or use of any Add-ons. These Add-on Terms of Use are Supplemental Terms to the Terms of Service ("Terms of Service", available at https://account.elderscrollsonline.com/terms-of-service and together with any other Supplemental Terms, including, but not limited to, the Privacy Policy available at https://account.elderscrollsonline.com/privacy-policy, and Code of Conduct available at https://account.elderscrollsonline.com/code-of-conduct, collectively, the "Agreement"). The Agreement is supplemented by the End User License Agreement available at https://account.elderscrollsonline.com/eula. Any capitalized terms not otherwise defined herein shall have the meanings given to them in the Terms of Service.

As part of the ongoing Services provided to You, ZOS will make available an application programming interface (the "API") to allow You to create, download, enable, use, or associate Content, including user-generated Content ("UGC"), that modifies or otherwise provides enhanced features to the user interface ("Add-ons") for The Elder Scrolls® Online software-as-a-service product purchased by You (the "Game").

The creation, download, enabling, use and/or association of the API and/or any Add-ons is on a USE AT YOUR OWN RISK basis. As with all Content, including UGC, all uses of the API and any Add-ons are for Your own personal, non-commercial use solely in connection with the Game, subject to the terms and conditions of the Terms of Service, including these Add-on Terms of Use. Your use of the API, creation of any Add-ons through the API, and/or the enablement of any Add-ons in the Game each constitutes Your acceptance of these Add-on Terms of Use. IF YOU DO NOT ACCEPT THESE ADD-ON TERMS OF USE, DO NOT USE THE API OR CREATE, DOWNLOAD, ENABLE, USE OR ASSOCIATE ANY ADD-ONS WITH YOUR GAME.

1. RESTRICTIONS ON USE

ZOS grants a limited license right for personal, private, non-commercial, non-transferable, and limited use governed by the Terms of Service, including the Add-on Terms of Use, to distribute Add-ons You create to other authorized users who have purchased the Game, solely for use with such users’ own authorized copies of the Game and in accordance with and subject to the terms and conditions of the Agreement, including the Add-on Terms of Use, and all applicable laws. You agree that any Add-on distributed to other Game users will include the following disclosure in a Readme or similar .txt file, “This Add-on is not created by, affiliated with or sponsored by ZeniMax Media Inc. or its affiliates. The Elder Scrolls® and related logos are registered trademarks or trademarks of ZeniMax Media Inc. in the United States and/or other countries. All rights reserved.” You agree that in its sole discretion and without notice, ZOS reserves the right to modify, restrict, or disable any Add-ons, including any You have enabled, without notice, at any time and for any or no reason, including, but not limited to, (i) direct and indirect violations of the Rules of Conduct, as described in the Terms of Service; (ii) evidence of commercial gain or attribution, including game exploitation; (iii) undue or unfair burden to the Game, its Services, including customer service support, and/or to other users.

2. DISCLAIMERS

IN ADDITION TO THE DISCLAIMERS AS SET FORTH IN THE TERMS OF SERVICE, AND TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, YOU ACKNOWLEDGE AND AGREE THAT THE USE OF ADD-ONS IS AT YOUR SOLE RISK AND YOU ASSUME ALL RISKS ASSOCIATED ANY ADD-ONS ON YOUR MACHINE. ZOS CUSTOMER SERVICE SHALL HAVE NO OBLIGATION TO PROVIDE ANY SUPPORT WITH RESPECT TO THE API OR ANY ADD-ONS, OR TO PROVIDE ANY SUPPORT RELATED TO THE GAME IF AN ADD-ON IS ENABLED IN YOUR GAME’S USER INTERFACE. YOU ACKNOWLEDGE AND AGREE THAT ADD-ONS MAY NOT FUNCTION PROPERLY FOR ANY OR NO REASON, AND THAT ZOS SHALL NOT BE RESPONSIBLE FOR ENSURING THE PERFORMANCE OF ANY ADD-ONS OR THE PERFORMANCE OF THE GAME WHEN AN ADD-ON IS ENABLED. YOU ACKNOWLEDGE AND AGREE THAT ENABLING AN ADD-ON CAN AFFECT AND/OR CAUSE YOUR COMPUTER, SOFTWARE, GAME, AND/OR ACCOUNT TO FUNCTION IMPROPERLY.

WITH RESPECT TO ANY ADD-ON THAT IS DOWNLOADED ON OR OVER THE INTERNET, YOU ACKNOWLEDGE THAT THE FILES FOR SUCH ADD-ONS MAY CONTAIN SPYWARE, MALWARE, VIRUSES OR OTHER MALICIOUS CODE THAT COULD AFFECT YOUR COMPUTER OR SYSTEM(S). YOU AGREE THAT ZOS IS NOT RESPONSIBLE FOR ANY SUCH MALICIOUS CODE CONTAINED IN AN ADD-ON OR ANY DETRIMENTAL EFFECTS TO YOUR COMPUTER OR SYSTEMS CAUSED BY AN ADD-ON (WHETHER DUE TO MALICIOUS CODE OR OTHERWISE). USE OF THE INTERNET, INCLUDING THE DOWNLOAD OF FILES FROM THE INTERNET, IS AT YOUR SOLE RISK AND FILES SHOULD ONLY BE DOWNLOADED FROM SOURCES TRUSTED BY YOU.

3. ENTIRE AGREEMENT

Except as set forth in this Section, if there is any conflict between the Terms of Service, a EULA and any Supplemental Terms, You acknowledge and agree that, for the purposes of the Add-on Terms of Use, the terms and conditions shall govern in the following order of precedence: (i) Terms of Service; (ii) the applicable EULA; (iii) the Add-on Terms of Use; and (iv) the applicable Code of Conduct.

Source

Authors, make particular note of the sixth bullet point:

If you create an Add-on, You must include the following disclosure in a Readme or similar .txt file: "This Add-on is not created by, affiliated with or sponsored by ZeniMax Media Inc. or its affiliates. The Elder Scrolls® and related logos are registered trademarks or trademarks of ZeniMax Media Inc. in the United States and/or other countries. All rights reserved."

zzz disclosures. Guess we have to add a readme :)

Quote:

Originally Posted by Cairenn (Post 9671)

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.

I just looked at my pre-patch ZO_Ingame.lua
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:

zzz disclosures. Guess we have to add a readme

I hope they fixed the issue that the game would treat any .txt file lying next to a Manifest file as another manifest file.

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,

["body"] = nil -- invalid string value,

["medium"] = 0,

Unfortunately, because the comma is also commented, if there is another table value on the following line, the it will be missing a preceding comma and the parser will be unable to read your saved variables, and so on the second logout, the entire file will be overwritten with an empty one.

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:

Originally Posted by Flamage (Post 9697)

Code:

["showTitle"] = true,

["body"] = nil -- invalid string value,

["medium"] = 0,

I think this is a separate problem in that text used to be stored between double brackets - [[SOME TEXT]] and is now stored between double quotes - "SOME TEXT"

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:

Originally Posted by dominoid (Post 9707)

I think this is a separate problem in that text used to be stored between double brackets - [[SOME TEXT]] and is now stored between double quotes - "SOME TEXT"

Actually that's an improvement, because you CAN escape a double quote in a double-quoted string, "blah\"blah", while there is no way to escape a closing squacket in a squacket-enclosed string, blah[1] becomes [[blah[1]]] and blows up.

I mean, it WOULD be an improvement, if done right...

Quote:

Originally Posted by niocwy (Post 9705)

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 ?

Okay download just finished.

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:

Originally Posted by niocwy (Post 9718)

Okay download just finished.

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.

Before the patch we had user addons with seperation by account ("@accountname") while the ZO_ingame.lua used ("").
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:

Originally Posted by Sharlikran (Post 9727)

in this case something is either bugged or thiers been change its not because services etc NA server has been up 24 hours plus now and all services are up and running

Quote:

Originally Posted by Cairenn (Post 9671)

.....
Authors, make particular note of the sixth bullet point:

If you create an Add-on, You must include the following disclosure in a Readme or similar .txt file: "This Add-on is not created by, affiliated with or sponsored by ZeniMax Media Inc. or its affiliates. The Elder Scrolls® and related logos are registered trademarks or trademarks of ZeniMax Media Inc. in the United States and/or other countries. All rights reserved."

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:

Originally Posted by Anceane (Post 9731)

end users Don't half to worry about adding this its for authors that wish to release addons for others, need the disclaimer included with thier download

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"

2. Reload.
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:

Originally Posted by Lua Reference Manual

Literal strings can be delimited by matching single or double quotes, and can contain the following C-like escape sequences: '\a' (bell), '\b' (backspace), '\f' (form feed), '\n' (newline), '\r' (carriage return), '\t' (horizontal tab), '\v' (vertical tab), '\\' (backslash), '\"' (quotation mark [double quote]), and '\'' (apostrophe [single quote])

You can also write:
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:

Addon Settings: The add-on settings currently are not working as intended.
STATUS: Currently investigating.

Quote:

Originally Posted by zgrssd (Post 9814)

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:

Too little much too late.

Quote:

Originally Posted by GrfxGawd (Post 9811)

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.

/signed

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:

Originally Posted by GrfxGawd (Post 9815)

Too little much too late.
As a real programmer, I really thought you'd be much too smart for this.

I know I am a awesome programmer, even if I have to learn lua a lot more.

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:

Originally Posted by Sephiroth018 (Post 9831)

...normally you would have such nice little things called unit tests and integration tests...

Look, ZeniMax Online Studios - Job listings

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:

Originally Posted by zgrssd (Post 9839)

That was childish of me. I threw back the second comment you ever made interacting with me. But I'm moving on from that, and I'm not doing that with you anymore. Regardless of how wide apart our feelings and ideas may be on however many subjects there is one commonality we share - we're both here to help support a community and a game we care about.

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:

Originally Posted by Ethelsia (Post 9974)

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

It currently is considered as a bug and ZOS is investigating.
See the official Known Issues thread for it:

Addon Settings: The add-on settings currently are not working as intended.

STATUS: Currently investigating.

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:

local displayName = GetDisplayName()
if displayName == nil or displayName == "" then
   if GetNumGuilds() > 0 then
      displayName = GetGuildMemberInfo(GetGuildId(1), GetPlayerGuildMemberIndex(GetGuildId(1)))
   else
      displayName = "@" .. GetCVar("AccountName")
   end
end
 
function GetDisplayName()
   return displayName
end

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:

Originally Posted by Garkin (Post 9996)

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

This looks like a very useful piece of code, if they don't fix the bug in 1.2.4 then I'll be employing this and stop using ZO_SavedVars altogether. Thanks!

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:

Originally Posted by farangkao (Post 10021)

I see only one problem: It ends up overriding GetDisplayName() regardless if it works properly or not.
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

    local currentGDN = GetDisplayName



    --Second, defined your corrected function

    local function newGDN()

      local displayName



      if GetNumGuilds() > 0 then

          displayName = GetGuildMemberInfo(GetGuildId(1), GetPlayerGuildMemberIndex(GetGuildId(1)))

      else

          displayName = "@" .. GetCVar("AccountName")

      end



      return displayName

    end

    

    --Thrid, check if the currently used GDN function is faulty

    local displayName = currentGDN()

    if displayName == nil or displayName == "" then

      --Overwrite the current version

      GetDisplayName = newGDN

    end

Just putting it in your code would be too agressive/out of user hands. How about:
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:

Originally Posted by Ethelsia (Post 10175)

they havent fixed it lol its prolly your old data pre 1.2.3

Quote:

Originally Posted by SkOODaT (Post 10178)

they havent fixed it lol its prolly your old data pre 1.2.3

you are right! Silly me :banana:

Quote:

Originally Posted by Ethelsia (Post 10175)

Basically the problem is that GetDisplayName returns "" (empty string). So when trying to load/create the saved variables, the SavedVar system goes for the "" account entry in the SavedVar table.
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:

for default,sv in pairs(XrysGatherer_SavedVariables) do 
            for account,accountv in pairs(sv) do
                for accountWide,acWideV in pairs(accountv) do
                    for i,v in pairs(acWideV) do
                        if i == "ItemData" then itemInfo = v end
                        if i == "NodeData" then nodeInfo = v end
                    end
                end
            end
        end

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:

Originally Posted by zgrssd (Post 10188)

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:

Originally Posted by zgrssd (Post 10212)

Yes. This is what I do with all of my addons.

Quote:

Originally Posted by Seerah (Post 10214)

Yes. This is what I do with all of my addons.

I personally think having a seperation by account name is a good thing and writing the variable directly means you have to manualyl take care of that.

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:

Go to your Documents folder (the same one that you had to use to install your addons)
Go to your Elder Scrolls folder
Go to your Live folder (or liveeu for european users)
Go to your SavedVariables folder
MAKE A BACKUP OF THIS FOLDER!
You should see a listing of files for each addon you used. They will be named [AddOnName].lua
You can open those files using any text editor (just use NotePad). Right click the file name, choose Open With and pick whatever editor you want to use
Start to search (Ctrl+F) for string ["@Username"] (replace Username with your ESO Username), if not found, go to line under, if found, go to the Post Scriptum section
If you didn't find ["@Username"], somewhere close to the top of the .lua file will be a line that says [""] = (generally line 5)
Change that to replace [""] with ["@Username"]
Save and close.

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 !

Start to enlarge notepad window to full screen, it will help.
Then, you will need to find the whole block of settings under ["@Username"] this block contains all your saved settings before ESO 1.2 - and/or if you already patched and launched game, your new settings.
This block must be deleted (with ["@Username"] too and closing brackets too !), read exemple under !
Then, find the line (Ctrl+F) with [""] =. It must be changed with ["@Username"] =
Save and close.

Example : Lines in red will be deleted, Line in green will be changed :

Code:

SN_FS_SavedVariables =

{

    ["Default"] = 

    {

        ["@MyAcountName"] = 

        {

            ["Ayantir"] = 

            {

                ["SN_FS"] = 

                {

                    ["debug"] = true,

                    ["version"] = 1,

                    ["stack_on_insert"] = false,

                    ["configVersion"] = 1,

                },

            },

        },

        [""] = 

        {

            ["Ayantir"] = 

            {

                ["SN_FS"] = 

                {

                    ["debug"] = false,

                    ["version"] = 1,

                    ["stack_on_insert"] = false,

                    ["configVersion"] = 2,

                },

            },

            ["Victoire"] = 

            {

                ["SN_FS"] = 

                {

                    ["debug"] = false,

                    ["version"] = 1,

                    ["stack_on_insert"] = false,

                    ["configVersion"] = 2,

                },

            },

        },

    },

}

Resulting in :

Code:

SN_FS_SavedVariables =

{

    ["Default"] = 

    {

        ["@MyAccountName"] = 

        {

            ["Ayantir"] = 

            {

                ["SN_FS"] = 

                {

                    ["debug"] = false,

                    ["version"] = 1,

                    ["stack_on_insert"] = false,

                    ["configVersion"] = 2,

                },

            },

            ["Victoire"] = 

            {

                ["SN_FS"] = 

                {

                    ["debug"] = false,

                    ["version"] = 1,

                    ["stack_on_insert"] = false,

                    ["configVersion"] = 2,

                },

            },

        },

    },

}

Well explained, thanks Ayantir. :)

I've been gone for a while....you mean to tell me ZO still hasn't fixed this bug?!?

Quote:

Originally Posted by skyraker (Post 11165)

I've been gone for a while....you mean to tell me ZO still hasn't fixed this bug?!?

They just did, actually. So now everything that people have done to work around the bug needs to be un-worked-around again.

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).