Raw SavedVariables

LibSavedVars normally provides an enhanced interface for accessing saved variables. When a value is not present in the SavedVariables file, LibSavedVars automatically supplies the corresponding value from the defaults table.

In some situations, an addon needs access to the raw saved data instead of the resolved settings view.

Raw SavedVariables provide direct access to only the values that are actually stored.

---

Resolved Settings vs. Raw Data

The normal LibSavedVars interface combines saved values and defaults.

Example defaults:

local defaults = {
    enabled = true,
    scale = 1.0,
    window = {
        x = 100,
        y = 100,
    },
}

A new user may have an empty SavedVariables table:

{}

However, accessing the settings object returns:

settings.enabled
-- true

settings.scale
-- 1.0

settings.window.x
-- 100

The values come from the defaults table.

---

Raw SavedVariables

The raw data contains only values that have actually been stored.

Example:

{
    scale = 1.5
}

Accessing the raw table:

local rawData = settings:GetRawDataTable()

returns:

{
    scale = 1.5
}

The default values are not included:

rawData.enabled
-- nil

rawData.window
-- nil

---

When to Use Raw Data

Most addons should use the normal settings interface.

Raw data is intended for advanced scenarios such as:

• Writing migrations.
• Debugging saved variables.
• Inspecting user changes.
• Exporting settings.
• Importing settings.
• Implementing custom cleanup operations.
• Comparing stored data against defaults.

---

Accessing Raw Data

Example:

local rawData = settings:GetRawDataTable()

if rawData.enabled then
    -- The user has explicitly saved this value.
end

This is different from:

if settings.enabled then
    -- The value may come from defaults.
end

The first checks whether the user has stored a value.

The second checks the effective value after defaults are applied.

---

Raw Data and Migrations

Migrations should normally operate on raw saved data.

Example:

Version 1:

{
    opacity = 0.8
}

Version 2:

{
    display = {
        opacity = 0.8
    }
}

Migration:

settings:Migrate(2, function(savedVars)

    savedVars.display = savedVars.display or {}

    savedVars.display.opacity =
        savedVars.opacity

    savedVars.opacity = nil

end)

The migration works with the stored structure, not the resolved settings view.

---

Raw Data and Defaults Trimming

Raw data is especially useful when using defaults trimming.

Before trimming:

{
    enabled = true,
    scale = 1.5,
    window = {
        x = 100,
        y = 200,
    }
}

Defaults:

{
    enabled = true,
    scale = 1.0,
    window = {
        x = 100,
        y = 100,
    }
}

After trimming:

{
    scale = 1.5,
    window = {
        y = 200,
    }
}

The raw table contains only values that differ from defaults.

---

Raw Data with LSV_Data

When using LSV_Data, the active settings may be composed from:

• Account-wide settings.
• Character settings.
• Pinned account settings.

The raw data for each underlying saved variable source remains separate.

Example:

LSV_Data
 |
 +-- Account SavedVariables
 |
 +-- Character SavedVariables

Use the appropriate saved variable object when inspecting raw storage.

The active settings interface should still be preferred for normal addon operation.

---

Do Not Modify Raw Data Unless Necessary

Directly modifying raw data bypasses some of the protections provided by LibSavedVars.

Avoid:

local raw = settings:GetRawDataTable()

raw.someSetting = value

when normal access is sufficient:

settings.someSetting = value

Use raw access only when intentionally working with the stored representation.

---

Debugging Example

A useful debugging pattern:

local rawData = settings:GetRawDataTable()

d("Stored values:")

for key, value in pairs(rawData) do
    d(key .. ": " .. tostring(value))
end

This shows what the player actually has stored, rather than the values provided by defaults.

---

Best Practices

When using raw SavedVariables:

• Use normal settings access for gameplay code.
• Use raw data for migrations and diagnostics.
• Do not assume missing keys are errors.
• Remember that missing values may be supplied by defaults.
• Avoid modifying raw tables unless performing intentional data operations.
• Test raw data handling with both new and existing saved variables.

---

Summary

Raw SavedVariables provide direct access to the data physically stored by ESO.

The normal LibSavedVars interface answers:

"What value should my addon use?"

Raw data answers:

"What values has the user actually saved?"

Understanding the difference is important for advanced features such as migrations, defaults trimming, debugging, and data management.