ESOUI
Page 3 of 3 < 12 3
Show 60 post(s) from this thread on one page

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)

zgrssd 07/02/14 04:01 AM
Quote:
Originally Posted by farangkao (Post 10021)
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.
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...

Ethelsia 07/04/14 06:01 PM
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.

SkOODaT 07/04/14 06:19 PM
Quote:
Originally Posted by Ethelsia (Post 10175)
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.
they havent fixed it lol its prolly your old data pre 1.2.3

Ethelsia 07/04/14 08:37 PM
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:

zgrssd 07/05/14 02:06 AM
Quote:
Originally Posted by Ethelsia (Post 10175)
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.
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.

Xrystal 07/05/14 11:05 AM
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:
  1. for default,sv in pairs(XrysGatherer_SavedVariables) do 
  2.             for account,accountv in pairs(sv) do
  3.                 for accountWide,acWideV in pairs(accountv) do
  4.                     for i,v in pairs(acWideV) do
  5.                         if i == "ItemData" then itemInfo = v end
  6.                         if i == "NodeData" then nodeInfo = v end
  7.                     end
  8.                 end
  9.             end
  10.         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)
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.

zgrssd 07/05/14 05:52 PM
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.

Seerah 07/05/14 06:17 PM
Quote:
Originally Posted by zgrssd (Post 10212)
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.
Yes. This is what I do with all of my addons.

zgrssd 07/08/14 06:00 AM
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.

farangkao 07/08/14 07:34 AM
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.

Ayantir 08/04/14 11:28 PM
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:
  1. Go to your Documents folder (the same one that you had to use to install your addons)
  2. Go to your Elder Scrolls folder
  3. Go to your Live folder (or liveeu for european users)
  4. Go to your SavedVariables folder
  5. MAKE A BACKUP OF THIS FOLDER!
  6. You should see a listing of files for each addon you used. They will be named [AddOnName].lua
  7. 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
  8. 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
  9. If you didn't find ["@Username"], somewhere close to the top of the .lua file will be a line that says [""] = (generally line 5)
  10. Change that to replace [""] with ["@Username"]
  11. 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 !
  1. Start to enlarge notepad window to full screen, it will help.
  2. 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.
  3. This block must be deleted (with ["@Username"] too and closing brackets too !), read exemple under !
  4. Then, find the line (Ctrl+F) with [""] =. It must be changed with ["@Username"] =
  5. 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,
                },
            },
        },
    },
}

Cairenn 08/05/14 12:50 AM
Well explained, thanks Ayantir. :)

skyraker 08/05/14 09:43 AM
I've been gone for a while....you mean to tell me ZO still hasn't fixed this bug?!?

katkat42 08/05/14 10:19 AM
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.

AstroCat 08/05/14 02:09 PM
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! :)

skyraker 08/05/14 11:29 PM
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. :)

Wykkyd 09/15/14 09:47 AM
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 03:27 AM.
Page 3 of 3 < 12 3
Show 60 post(s) from this thread on one page

vBulletin © 2024, Jelsoft Enterprises Ltd
© 2014 - 2022 MMOUI