Scope of SavedVariables insruction
 

Hi !

The SavedVariables directive in an add-on's TOC-file specifies the variables it saves in-between gaming sessions.

I've been developing an add-on for quite some time now, which is constructed in a very Java-like namespacing system, that is, all seperate components of the add-on are placed into different namespaces. This is accomplished by defining nested array/table variables and later-on defining the variables and functions as fields inside the table.

However, when I try to specify a table variable defined inside a namespace as the variable to save, it fails to accomplish it. In order for SavedVariables to find and save te variable, I must define the table at global level, i.e. not inside any namespaces.

While the current approach uses a global variable, that is then copied inside the namespace into the actual table when VARIABLES_LOADED event is triggered, I would certainly like to know what the scope of SavedVariables is, if anyone knows.. To me, it seems it can only identify global-level variables correctly..

- Gorak

You're trying to save a property on an object without saving the entire object?

Just save the top-level object and all nested objects will be saved. If this is inefficient (for example too many transient state values will be saved) the normal solution is to separate the persistant state into an object and then save that. This object can have nested tables that mirror the nesting in other parts of your code. You can use Lua's meta-table feature to bind the persistant and transient objects together.

You might also be trying to build a monolithic add-on. Do you really need extensive nesting? Can you refactor your code into several add-ons with a flatter namespace?

You can only store global variables in SavedVariables.lua.

Precisely. Couldn't have put it any better :)

Will take this into investigation. The current system, which uses the mirroring techinque (that is, a global table variable which holds specific status fields I wish to save) works fine as well, but breaks the overall design schema.

No, this is impossible, because the individual components of the add-on are designed to function as part of the larger scale and they cannot function alone. The components are placed into seperate files though. The "namespace" system is used to avoid extensive namemangling, such as <add-on name><version>_<functionname>, for example.

- Gorak