Modify other addon local scoped saved variables.

[Phinix]

Greetings,

Something I would like to be able to do, would be the ability to change settings of another addon by directly modifying known saved variables for that addon (followed by a UI restart).

Addons which have saved variables defined in the global space this is simple. However for addons that define saved variables in a local scope they are not directly accessible. I am looking for a workaround.

I had thought about hooking ZO_SavedVars.New and checking for the addon in question, and if detected hook the return of the saved variables reference using a debug posthook. I am not having much luck with the syntax of that.

I also thought doing something similar and just injecting a different table for the "default" value might push a custom set of variables onto the other addon during initialization. The problem there is that you would have to also modify the version to something higher than the current to have the engine overwrite the existing values, which would leave the addon in question with the wrong version in saved variables, which would be unacceptable.

Anyway, I was just wondering if there might be any better methods to do this.

TIA!

[Phinix]

Seems you can't hook ZO_SavedVars as they are protected functions. Might be able to use secure hook according to LUA docs but honestly I am thinking there would have to be a better way regardless. The entire concept is dependent on the operating addon loading before the target and that seems to much up to chance even given the right naming.

Probably there is no way to do this.

[votan]

Originally Posted by Phinix Seems you can't hook ZO_SavedVars as they are protected functions. Might be able to use secure hook according to LUA docs but honestly I am thinking there would have to be a better way regardless. The entire concept is dependent on the operating addon loading before the target and that seems to much up to chance even given the right naming. Probably there is no way to do this.

You may just think too complicate. I don't know exactly what you want to do, but:
ZO_SavedVars is just a wrapper to the sub-tree of the structure saved in the global variable declared in the manifest file.

Any ZO_SavedVars:New wraps the same shared sub-tree. You just have to know the name AND wait for those addon EVENT_ADD_ON_LOADED event. The easiest way is to make your addon optional depend on them. In this case your event comes after those.
Or you delay the unregister for EVENT_ADD_ON_LOADED until EVENT_PLAYER_ACTIVATED. This is done in WaypointIt for example.

The only problem you may have is, that changing the settings outside LAM2 does not force the controls to refresh automatically. But you want to do a reload anyway...

[Phinix]

Hi Votan,

That's a good point about delaying unregistering the addon loaded event. I hadn't thought of that.

I am wondering if you could maybe provide an example of direct alteration of a saved variable for an addon using the method you describe. Assume the following scenario.

Someone else has an addon that defines SavedVariables in a local scope like this:

local SomeAddon = {}
SomeAddon.Name = "Some Addon"

local SavedVariables
local Defults = {}

local function OnAddonLoaded(event, addonName)
	if addonName ~= SomeAddon.Name then return end
	EVENT_MANAGER:UnregisterForEvent(CWMAddon.Name, EVENT_ADD_ON_LOADED)
	SavedVariables = ZO_SavedVars:New(SomeAddon.Name, 1, nil, Defaults)
end

EVENT_MANAGER:RegisterForEvent("SomeAddon", EVENT_ADD_ON_LOADED, OnAddonLoad)

Or alternately like this, but either way local scope:

SomeAddon.SavedVariables = ZO_SavedVars:New(SomeAddon.Name, 1, nil, Defaults)

Assuming both "SomeAddon" and my addon are loaded, how can I directly change SomeAddon's saved variables when defined as such in local scope?

EDIT:

Using Zgoo or /script d(SomeAddon), the later being the manifest name for saved variables, I can see the table structure.

	["Default"] = table [#0,1]
		["@AccountName"] = table [#0,10]
			["$AccountWide"] = table [#0,9]
			["Character1"] = table [#0,9]
			["Character2"] = table [#0,9]
			["Character3"] = table [#0,9]
			...etc.

How to reference the variables in each of the "Character" and "@AccountName" tables?

[Phinix]

Thinking I MAY have figured it out...

local AccountWideDB = SomeAddon.Default[GetDisplayName()]["$AccountWide"]
local CharacterDB = SomeAddon.Default[GetDisplayName()][GetUnitName('player')]

Testing...

[votan]

Originally Posted by Phinix I am wondering if you could maybe provide an example of direct alteration of a saved variable for an addon using the method you describe.

I'm currently at work, but for an example you can look at Votan's Rune Info. I will test, if I talk BS when I'm back home.

[Phinix]

The above syntax definitely does work!

Originally Posted by votan ZO_SavedVars is just a wrapper to the sub-tree of the structure saved in the global variable declared in the manifest file.

This was the key piece of knowledge that triggered my "getting it." By referencing the name listed for the Saved Variables in the manifest .txt file I was able to directly manipulate the saved variables of any addon using some variation of the above syntax.

Since I force a ReloadUI() after doing so there should be no problems with it.

Thanks very much for your insight, Votan.

[sirinsidiator]

I am not sure what you plan to do, but I have to speak against overwriting some other addons save data. You may think it is a good way to do it, but it is bound to cause unexpected issues in the future if an author ever decides to change their saved variables in some ways and suddenly there are bug reports that do not make sense for them, because they do not know about your little hack.

A better way would be to ask that addon author to provide a method that you can call that does exactly what you need.

[Phinix]

@sirinsidiator - I completely agree, this is never something that anyone should do during the normal course of coding an addon. In general, addons should be "blind" to the internal structures of other addons. The only communication should be through officially supported global functions like what I make available for ESO Master Recipe List.

However, this is a very unique case. If you check my signature, you will see Phinix Addon Powered UI. This is basically a set of pre-configurations of many popular addons to create a comprehensive user interface, freeing people from having to configure it all themselves.

The addon I am working on removes the need to manually edit these SavedVariables files and allows you to simply install all the addons, then type a slash command in-game to instantly reload the UI with all the settings applied.

I was careful to avoid certain potential problem causing issues. For example, I am not setting the version field in any of the addon saved variables I touch, so future updates should not be effected. Further, if an author completely changes the addon names, it should not effect functionality as the scripts will only be setting unused variables.

Overall I understand your concerns, but for the very unique special case of this project I believe it is an acceptable practice.

Plus I caution people to always back up their existing saved variables (and even have a video showing how) to avoid unforeseen complications.

[sirinsidiator]

I was more thinking along the lines of my addonA now has a new feature that is better than addonB's similar feature, so I simply shut it off if I detect addonB or something like that.

In your case you will have to update your configuration addon with each new update of an addon anyways. You should still ask the addon authors in question to notify you when something changes in the saved variables. That way they know that there is an addon that can modify their save data and you do not have to check every update for potential changes.

[Phinix]

Here is the end result:

http://www.youtube.com/watch?v=o6Jb9tQ-2so

[sirinsidiator]

Nice work! About the addon keybind separation, that is done by merlight's libAddonKeybinds which seems to be included in one of the addons you use.

[Baertram]

I am not setting the version field in any of the addon saved variables I touch

Hm. I often see addons updated but the SavedVars version is not updated at all (to keep existing data).
This would be a problem then (sometimes)