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

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:

Too little much too late.

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

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
 

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.

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

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:

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.

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.