two questions about saved variables

[Vuelhering]

Maybe someone can shed some light on this...

Q1:
Let's say I have a saved variable named "sv", which I load through

sv = ZO_SavedVars:New("myaddon", major, nil, {} , nil) or {}

I can do things like
sv.foo = "bar", and d(sv.foo) produces "bar".

But traversing sv with pairs() is bizarre. How do I traverse the keys I just stored?


Q2:
Saved variables are different for each character.

How do I make one that's global to all characters?

[Seerah]

Instead of using :New() use :NewAccountWide()

That said, I don't use their saved variables API. I just do it all manually. (So much easier on my sanity...)

[Halja]

In lua pairs() may not guaranty order on arrays and if the array has different types. Things may come back in a different order. Ipairs if will you are using indexed table sections. You don't have to traverse the whole lua table with pairs() or ipairs(). You can make jumps.

The following is was not tested. I may have typos. Given your savedvars file look something like this.

savedVars =
    {
        ["Default"] = 
        {
            ["@AccountName"] = 
            {
                ["$AccountWide"] = 
                {
                    ["IndexTable"] = 
                    {
                        [1] = 
                        {
                            ["LName"] = [[Doe]],
                            ["FName"] = [[Jon]],
                        },
                        [2] = 
                        {
                            ["LName"] = [[Doe]],
                            ["FName"] = [[Jane]],
                        },
                        [3] = 
                        {
                            ["LName"] = [[Smith]],
                            ["FName"] = [[John]],
                        },
                    },
                    ["version"] = [[0.1.3]],
                    ["Location"] = 
                    {
                        ["X"] = 10,
                        ["Y"] = 20,
                    },
                },
            },
        },
    }

As long as there is just one "Location" this dot notation works.

local x =  savedVars.Location.X
local y = savedVars.Location.Y

And this for indexed tables:

for k,v  in ipairs (savedVars.IndexTable) do
        d(v["LName"])
        d(v["FName"])
end

I know of two calls for saved varables. The ESOUI sample shows one.
Saved for each character:
local savedVars = ZO_SavedVars:New(savedVariableName, version, namespace, defaults, profile)

Save for the Account:
local savedVars = ZO_SavedVars:NewAccountWide(savedVariableName, version, namespace, defaults, profile)

--halja

[Vuelhering]

Originally Posted by Seerah Instead of using :New() use :NewAccountWide() That said, I don't use their saved variables API. I just do it all manually. (So much easier on my sanity...)

Ah, that'll fix Q2.

How do you do it, Seerah? You still have to go through their api to write out the variables, don't you?

Thanks

Originally Posted by Halja And this for indexed tables: for k,v  in ipairs (savedVars.IndexTable) do         d(v["LName"])         d(v["FName"]) end

Ah, that might fix Q1.

[Seerah]

Not at all. Saved variables get written to the file upon reload our logout, just like in WoW. Have a loot at one of my addons if you wish to see how I handle them. (defaults table is usually near the top of the file with upvalues, and code to handle saved vars is usually toward the bottom in the first function to run)

[Xrystal]

Traversing the keys was a nightmare for me.

Say with a saved variable table as follows:

XrysGatherer_SavedVariables =
{
    ["Default"] = 
    {
        ["@Xrystal"] = 
        {
            ["$AccountWide"] = 
            {
                ["Options"] = 
                {
                    ["ShowAlert"] = 0,
                    ["version"] = 1,
                },
                ["Data"] = 
                {
                    ["Bleakrock Isle"] = 
                    {
                        ["raw jute"] = 
                        {
                            [1] = 
                            {
                                ["X"] = 0.526202,
                                ["Date"] = 20140331,
                                ["Trade Skill"] = [[Clothing]],
                                ["Item Type"] = [[Raw Material]],
                                ["Y"] = -0.137464,
                                ["Action"] = [[Collect]],
                                ["Time"] = [[23:01:20]],
                            },
.... etc

Despite having my variable SVData being registered as being the Data table in the file traversing SVData grabs the whole table tree.

eg:

SVData[zone][item][values] cannot be traversed by doing pairs(SVData) as the first value that appears is not the zone values or even the data value. Instead it shows up Default then account etc. I ended up writing a function to generate a table just containing the data I need for display purposes.

This is an example of how I generated the data element of the table so I could search through it.

local function UpdateHarvestHistory()
    harvestHistory = {}
    for default,sv in pairs(XrysGatherer_SavedVariables) do 
        for account,accountv in pairs(sv) do
            for accountWide,acWideV in pairs(accountv) do
                for index,data in pairs(acWideV) do
                    if index == "Data" then
                        table.insert(harvestHistory,data )
                    end
                end
            end
        end
    end
end

This is the only way I was able to consistently access the data using the for/pairs functions.

Also, although I am not 100% sure of it, but I believe the local variable you set up to write to the saved variable table can be cleared for each gaming session so that individual game sessions will not be storing a massive table in memory apart from your actual global saved variables table.

I initialise my addon table as such:
SVData = ZO_SavedVars:NewAccountWide(addonSV, 1, "Data", SVDefault)
where addonSV = "XrysGatherer_SavedVariables" and SVDefault is an empty table by default.

Now, when I set SVData = {} at the start of the addon and when player activated I thought it was forcing a clear of the data table. Apparently not as I definitely recall still having my data available and accessible via XrysGatherer_SavedVariables, and it didn't wipe the data out on log out, from memory, it just cleared the sessions version of the data.

So, and I suppose some further testing should really be done to be sure, I suspect the SVData variable set up to create the saved variables is really a session table that updates the Saved variables table on log out. Unlike wow where it seems to be a link to the same data. This could be useful if I wasn't imagining it as it could mean that you have access to session data as well as all data.

Hopefully I haven't confused things further but this almost fried my brain during the beta weekends trying to get this all to work rofl.

[Vuelhering]

Originally Posted by Seerah Not at all. Saved variables get written to the file upon reload our logout, just like in WoW.

Ah lol, so it'll write out just due to the text file and "## SavedVariables:" keyword?

I'll take a look if this doesn't work right. Thanks.

[Vuelhering]

Originally Posted by Xrystal Now, when I set SVData = {} at the start of the addon and when player activated I thought it was forcing a clear of the data table. Apparently not as I definitely recall still having my data available and accessible via XrysGatherer_SavedVariables, and it didn't wipe the data out on log out, from memory, it just cleared the sessions version of the data.

Yep, I just verified this.

[Xrystal]

Okay, I've been working on the saved variables some more today so that I can get a way to import data, delete duplicates, wipe whole segments etc but still have the information accessible as normal without the need to log out ( except in the case of importing another file if importing several at a time ).

Anyways, the picture attached shows the output from the following traversal function ( which won't work under normal circumstances so have to pull some strings ).

This function only goes as far as the first useful set of information that is used to write to the saved variables using the table that you set up at the beginning.

EG. Normally I would write something along the lines of table.insert(SVData[zone][item],{ ... etc ... }). I had to set my saved vars to the Data subtable so that I knew when I got to the information I wanted.

local function CheckSavedVars()
    for default,sv in pairs(XrysGatherer_SavedVariables) do 
        ChatMsg:AddMessage("Default: "..tostring(default).." "..tostring(sv).." "..tostring(type(sv)))
        for account,accountv in pairs(sv) do
            ChatMsg:AddMessage("Account: "..tostring(account).." "..tostring(accountv).." "..tostring(type(accountv)))
            for accountWide,acWideV in pairs(accountv) do
                ChatMsg:AddMessage("AcWide: "..tostring(accountWide).." "..tostring(acWideV).." "..tostring(type(acWideV)))
                for index,data in pairs(acWideV) do
                    ChatMsg:AddMessage("Data/Version: "..tostring(index).." "..tostring(data).." "..tostring(type(data)))
                    if index == "Data" then
                        for i,v in pairs(data) do
                            ChatMsg:AddMessage("Contents: "..tostring(i).." "..tostring(v).." "..tostring(type(v)))
                        end
                    end
                end
            end
        end
    end
end

In short the results were along the lines of what I was seeing happening but it is nice to get confirmation in writing.

The SavedVariables table actually stores both the values imported into memory when you first log in and the values added via the SVData table after it is initialised that session. I am assuming the ZO_SavedVars object knows what to do when you want to look at the data via SVData as it has access to both old and new data if accessed directly but you can't traverse it like you can the original table.

The first block of "Data" tables is your existing data and the second block of "Data" tables are your current session data. Handy for those addons that may want to keep track of session records. Yes, it has given me ideas for another feature, in between my work on the map pins.

Just something for your brains to tick over.

The question is whether this knowledge helps me with my current saved variable update problems.

edit:
Ah, now I see why I was getting confused with lack of information before. My harvestHistory extraction routine is automatically grabbing both the full data and the session data, not realising that both loads of data are in the table. It also explains why it is not letting me clear all the data I was expecting when I tell it to clear. It's because the stuff it isn't clearing is the current sessions data. Looks like 0.0.9 will be a little while longer before it's update.

edit2:
Actually after a few logins and reloads between test runs of my debug code and it seems there is no specific order to the data, just that there are multiple blocks of the Account Data table. One for all data ( or just what was loaded ) and one for the current session possibly. Although for some reason it is letting me delete certain data but not all data. Must be something else that decides what gets kept and what doesn't during the session manipulation of the saved variables.

edit3:
Scratch that. Looks like it must have been due to some dodgy account ID due to the import tests I was doing. So more tests to see if I can get the same corruption to happen again.