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 11:22 AM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2014 - 2022 MMOUI