SavedVariables and portable settings

[MunkDev]

Hello, I was just wondering if there's any conventional way of importing saved variables from another character, other than keeping a matrix with realms and toons and loading the whole damn table each time?

I want to keep my memory usage to a minimum, and while loading a couple of strings isn't that demanding, I store more than a handful of strings on each character. I want to avoid having to read from a gigantic table if I can avoid it.

[Resike]

I wouldn't really worry about this. Variables gets loaded into the memory when you login into the game and/or reload your UI, and it's getting saved when you log out of the game. Also it doesn't really matter how big is the table when you are searching in it since you probably will only searcing in the current profiles subtable. And when you just want to import a profile you just overwrite the current profile table with the selected one.

[MunkDev]

Do you think it would be a good approach to store two identical tables? As in one table that is character specific and one subtable in a large table for all characters?

Let's say the memory load is minimal. I still don't like the idea of players having to remove all settings on all characters if the account-wide table becomes corrupted. So the only purpose of the account-wide table would be to store settings for import/export.

What is the most common approach to this?

[Resike]

Could work, but it could create more trouble then it would solve.

You can dodge most of the saved variable corruption with this method (written by Phanx):

local defaultSettings = {
    ["profiles"] = {
        ["Default"] = {
            ["options"] = {
                ["width"] = 400,
                ["height"] = 600,
                ["scale"] = 1,
            },
            ["frames"] = {
 
            },
        },
    },
    ["profileKeys"] = {
 
    },
}
 
local function UpgradeVariables(src, dst)
    if type(src) ~= "table" then
        return { }
    end
    if type(dst) then
        dst = { }
    end
    for k, v in pairs(src) do
        if type(v) == "table" then
            dst[k] = UpgradeVariables(v, dst[k])
        elseif type(v) ~= type(dst[k]) then
            dst[k] = v
        end
    end
    return dst
end
 
MyAddonDB = UpgradeVariables(defaultSettings, MyAddonDB)

This way if the user manages to overwrite the ["scale"] with a string, then it would reset to it's default value on load.

It's also good if you let say in a new version you want to replace the ["width"] and ["height"] values with ["size"] = 600, then it's gonna create this variable on load, to prevent nil errors for users with an older saved variables.

But i would say for multi-profile addons with import and export settings the more common way is to use the account-wide variables only.

[Banknorris]

I also dislike having a general saved variable with the data from all characters being loaded all the time. What may work (I thought about it but never really implemented) you can make a secondary addon (a lot of addons have subaddons so not a big deal) that would be enabled when the user want to export/import and once it is done it would be disabled again.
1) user enable module
2) user log on the char with data to export
3) char saved variables are copied in the general saved variables
4) user log on the char with data to import
5) data from general saved variables are copied into the current char saved variables
6) user disable the module

This would work if the import/export is very rare. If not then it would be very annoying disabling/enable the module and logging into another toons.

[MunkDev]

I'm afraid the stuff I'm importing is button maps, bindings and mouse settings so it's very likely it will be used often. Now, another question pertaining to the same thing:

Having registered the event PLAYER_LOGOUT, I can't seem to store the subtable on logout. It's as if my frame never even receives the event. Calling the function manually stores the table just fine. Any ideas why this is happening?

[Banknorris]

I use this techinique:

local function OnLogoutStuff()
    --logout stuff here
end
 
local Original_Logout = Logout
function Logout()
    OnLogoutStuff()
    return Original_Logout()
end
 
local Original_Quit = Quit
function Quit()
    OnLogoutStuff()
    return Original_Quit()
end
 
local Original_ReloadUI = ReloadUI
function ReloadUI()
    OnLogoutStuff()
    return Original_ReloadUI()
end
 
local Original_ConsoleExec = ConsoleExec
function ConsoleExec(msg)
    if msg=="reloadui" then
        OnLogoutStuff()
    end
    return Original_ConsoleExec(msg)
end

[MunkDev]

Lol. So you really have to hook the actual functions? Why does that event even exist then?

[Resike]

Not sure why do you need the logout event. The client should automatically dump your current saved variables from the memory to the hard drive on logout. And thoose saved values gonna get loaded into the memory on the next login.

[MunkDev]

The reason I want to do this is because I want to duplicate the table and store them in the account-wide saved variable for import on other characters. I want to do it on logout to ensure the duplicated table is up to date. Eventually I might remove the character specific variables, but my addon is riddled with bugs and at the moment I think this is the best approach.

[semlar]

This is ridiculous, nobody wants to enable a secondary addon to import settings from another character because you don't want to store what is likely less than a megabyte of data in an account-wide table.

You could do exactly the same thing by just having an empty account-wide table in your addon purely for storing what you intend to import on another character.

But you should ask yourself whether this functionality is even necessary; most players use account-wide bindings, and the people who don't could probably live with importing from the last character they were logged into or a generic template, rather than picking from their entire list of characters to copy from.

[Torhal]

Originally Posted by semlar This is ridiculous, nobody wants to enable a secondary addon to import settings from another character because you don't want to store what is likely less than a megabyte of data in an account-wide table.

Sounds like a common case of Overengineering.

[MunkDev]

Originally Posted by Torhal Sounds like a common case of Overengineering.

Reminded me of this.

Originally Posted by semlar This is ridiculous, nobody wants to enable a secondary addon to import settings from another character because you don't want to store what is likely less than a megabyte of data in an account-wide table.

This was not a solution I considered for even a moment.

Originally Posted by semlar You could do exactly the same thing by just having an empty account-wide table in your addon purely for storing what you intend to import on another character.

Yes. That's pretty much what's going on. Copying the character specific table also allows a proper backup that you can fall back on if you mess up or in any way trash your settings. A character can import its own bindings, which will load the table from their previous game session.

Originally Posted by semlar But you should ask yourself whether this functionality is even necessary; most players use account-wide bindings, and the people who don't could probably live with importing from the last character they were logged into or a generic template, rather than picking from their entire list of characters to copy from.

I have a default setup that loads automatically. Saving generic templates would be an idea that I might look into.
Also, the bindings I'm talking about are not bindings in the traditional sense:



For the record I went with the approach of storing a character specific table and then dumping that into the account-wide table on logout. This gives both a chance to reset bindings to an earlier stage and allows for importing bindings on other characters.