SetSettings issue

[sirinsidiator]

In my addon ScreenshotHelper I try to disable all UI elements that are not hidden with the hide interface shortcut. In order to achieve this, I use SetSetting to turn off a couple of things.

This works most of the time, but sometimes it just randomly doesn't and the worst part, it doesn't fail consistently. It seems to only happen after login and only with settings that have a boolean value (checkboxes). Sometimes the group indicators just stay off, another time it is the FPS widget that gets disabled. I have yet to find a reason or a pattern why these stay off and other than that I am all out of ideas. Maybe someone can shed some light on the issue?

The code in question looks like this and for the full code, just download the addon.

-- the settings we want to overwrite when the gui gets hidden
local DESIRED_SETTINGS = {
    [SETTING_TYPE_UI] = {
        [UI_SETTING_SHOW_QUEST_BESTOWER_INDICATORS] = false,
        [UI_SETTING_SHOW_FRAMERATE] = false,
        [UI_SETTING_SHOW_LATENCY] = false,
    },
    [SETTING_TYPE_NAMEPLATES] = {
        [NAMEPLATE_TYPE_ALL_HEALTHBARS] = false,
        [NAMEPLATE_TYPE_ALLIANCE_INDICATORS] = NAMEPLATE_CHOICE_OFF,
        [NAMEPLATE_TYPE_GROUP_INDICATORS] = false,
        [NAMEPLATE_TYPE_RESURRECT_INDICATORS] = false,
        [NAMEPLATE_TYPE_FOLLOWER_INDICATORS] = false,
    },
    [SETTING_TYPE_COMBAT] = {
        [COMBAT_SETTING_SCROLLING_COMBAT_TEXT_ENABLED] = false,
    },
    [SETTING_TYPE_CHAT_BUBBLE] = {
        [CHAT_BUBBLE_SETTING_ENABLED] = false,
    },
    [SETTING_TYPE_IN_WORLD] = {
        [IN_WORLD_UI_SETTING_TARGET_GLOW_ENABLED] = false,
        [IN_WORLD_UI_SETTING_INTERACTABLE_GLOW_ENABLED] = false,
    }
}
-- we copy the structure to a second table where we save the current values
local savedSettings = ZO_DeepTableCopy(DESIRED_SETTINGS)
 
local function SaveSettings()
    for system, entry in pairs(savedSettings) do
        for settingId, value in pairs(entry) do -- for each setting in our structure we get the value either as a boolean or a number
            if(type(value) == "boolean") then
                savedSettings[system][settingId] = GetSetting_Bool(system, settingId)
            else
                savedSettings[system][settingId] = tonumber(GetSetting(system, settingId))
            end
        end
    end
end
 
local function ApplyCustomSettings(settings)
    for system, entry in pairs(settings) do
        for settingId, value in pairs(entry) do
            SetSetting(system, settingId, tostring(value)) -- we set each setting as a string
        end
    end
    ApplySettings() -- call apply afterwards (no idea if this does anything)
end
 
local function OnGuiHidden(eventcode, guiName, hidden)
    if (guiName ~= INGAME_GUI_NAME) then return end
    if (hidden) then -- when the gui gets hidden
        SaveSettings()
        ApplyCustomSettings(DESIRED_SETTINGS)
        SetFloatingMarkerGlobalAlpha(0)
    else -- when it becomes visible again
        ApplyCustomSettings(savedSettings)
        SetFloatingMarkerGlobalAlpha(1)
    end
end
 
local handle
handle = RegisterForEvent(EVENT_PLAYER_ACTIVATED, function()
    UnregisterForEvent(EVENT_PLAYER_ACTIVATED, handle)
    SaveSettings() -- we save them once, in case the EVENT_GUI_HIDDEN is called with hidden == false for some reason
    RegisterForEvent(EVENT_GUI_HIDDEN, OnGuiHidden)
end)

[sirinsidiator]

I am still trying to figure out this problem.
I found a way to reliably reproduce it and either it is a bug in the game, or I am simply doing something wrong.
Here is a video which shows what I mean:

When I toggle GUI, the addon disables all options that are related to things that show up even when the GUI is hidden, like nameplates, sct, etc.
At this point everything is still okay.
Once I leave the area the settings are suddenly randomly discarded. It's always a different bunch of options that is disabled, but always the ones I have set to off and then on again.

[haggen]

Did you try printing messages to see if your functions are called at unexpected times?

Also, I had the same doubts about 'ApplySettings()' and if it actually did something, until I had problems when changing the UI global scale. It only got applied after the aforementioned function has been invoked.

I can't right now, but later I'll check out some stock code that meddle with settings and see if I can figure something out.

[sirinsidiator]

The output is what you see in the top right corner.

I tried everything I can think off. Calling ApplySettings after every single SetSetting, once after everything was set, with a delay. I even called each SetSetting with some milliseconds delay between each. That's just a few things I tried, but nothing works.

[sirinsidiator]

I looked around a bit more and saw that I used an incorrect value for setting NAMEPLATE_TYPE_ALLIANCE_INDICATORS. After I changed it, the behavior changed and it now always sets NAMEPLATE_TYPE_ALL_HEALTHBARS to off without fail. No other setting is affected. When I remove NAMEPLATE_TYPE_ALL_HEALTHBARS from the list, suddenly some other settings are affected again.
It feels like the game "light off" at this point.

I also saw that ApplySettings is only necessary when setting some of the video settings.

[sirinsidiator]

I added this code which seems to solve the problem. Not really happy with it, but at least it seems to work now.

SaveSettings() -- save and restore the settings when we leave an area through a loading screen, otherwise they may get messed up
    RegisterForEvent(EVENT_PLAYER_ACTIVATED, function()
        if(not GetGuiHidden(INGAME_GUI_NAME)) then
            ApplyCustomSettings(savedSettings)
        else
            ApplyCustomSettings(DESIRED_SETTINGS)
        end
    end)
    RegisterForEvent(EVENT_PLAYER_DEACTIVATED, function()
        if(not GetGuiHidden(INGAME_GUI_NAME)) then
            SaveSettings()
        end
    end)

[sirinsidiator]

Logged in on the pts and had half the settings switched to off again. Seems like the "fix" only helps with part of the problem. Guess I'll have to save the settings in saved variables and overwrite them whenever I log in...

[merlight]

OPTIONS_WINDOW_FRAGMENT calls RefreshSettings when showing, and SendAllCachedSettingMessages when hiding. Maybe you need to call those as well as ApplySettings.

[sirinsidiator]

I just tried calling both ApplySettings and SendAllCachedSettingMessages immediately after setting them and in a second attempt on EVENT_PLAYER_DEACTIVATED, but it does not change anything.
Maybe @ZOS_ChipHilseberg has some input? The workaround I put in the latest version does seem to work for me, but I honestly would prefer if I could do it correctly and don't have to rely on something like that.

[ZOS_ChipHilseberg]

Can you summarize the repro steps for this? From what I read it looks like it's changing the settings and then going to another zone? We can look into it once we know exactly what we're looking for.

[sirinsidiator]

Sure.
1) Install ScreenshotHelper v1.3.3
2) Bind the control for toggling the GUI (part of the base game's own controls)
3) Press the key twice
4) Either log out or go to a different area like in the video

What I do in the addon is calling SetSetting in a loop for all things that still show up when the interface is hidden. It works fine when I press the key, but breaks on step 4.
When the game crashes, it seems to keep the settings like expected.

[ZOS_ChipHilseberg]

What are the expected and observed result?

Also, here is how the settings system works. When a setting is changed it is cached off in a map on the client side. Every 1.5 seconds the client will pick a setting out of the map and send it to the server. This is done to prevent hitting the message rate limit when the player is quickly rotating through settings (like holding left on the thumb stick in the gamepad options for a horizontal list selector). The cache can be flushed manually by calling SendAllCachedSettingMessages() and it is also flushed automatically when the player changes zones or logs off. However, if it sends so many options updates that the message rate limit is hit, some of them can be lost.

ApplySettings() exists because some options changes (like graphics settings) are very disruptive when they are changed, sometimes requiring a reload. So they don't get put into effect until apply is called. I don't think this is your issue though.

[sirinsidiator]

The expected results is that the settings stay the same before and after the UI is toggled off and on again as this is only a temporary state for taking a screenshot without glows, nameplates etc.

The observed result is that they do stay the same when toggling off and on again, but after relogging or changing the area, part of the settings are falsely set to off.