Why does uidata.xml have debug info?

[user1679]

What is the purpose of __CORE_DEBUGLOG_LOG inside the uidata.xml file considering the information is a duplicate of debuglog.txt? This file is where some mod options and other game data are saved and occasionally it gets so big that sometimes when you change a mod's options they don't update in the file. It seems odd to have a file that can be several MB in size that just mirrors debug info which can be obtained elsewhere.

For example, I got a message that my game was modded. I clicked "don't show again" and then "ok". Next time I loaded my game it appeared again. I looked in uidata.xml and this was not updating properly to disable the alert:

__CORE_DETAILMONITOR_USERQUESTION

I had to delete the file completely which also meant I had to reset most of my mod options too. It seems that dumping a ton of debug info into this file sometimes causes it to not update the changes made to other parts of the game. It's not a permission issue considering it is located in my documents folder (windows 10).

[Dj_FRedy]

It is not a duplicate, it has some peculiarities: viewtopic.php?t=366654#p4381310
'Clear Log' to safely delete logs before manipulating other options.

::Edited::

[user1679]

That's interesting that it isn't validated because I just removed all my mods except 1, deleted the file and loaded the game. I got the warning, answered it and exited. When I restarted I didn't get asked again.

I have had this problem in the past where suddenly none of my options would save and I have to rename the file to get a new one to generate and then copy the old data into the new file. It's not a permission issue so I assume it's some sort of race condition caused by the way data is flushed to the disk.

[Dj_FRedy]

I have partially edited my previous message to better inspect this issue.
-------------------
Ok, I was interpreting my modified files wrong when I responded in my last message by stating that '__CORE_DETAILMONITOR_USERQUESTION["modified"]' is not validated, in 'onShowMenu()' there is a block that handles this.

On the other hand, 'menu.contextMenuMode' is set to "modified" when initiating the menu in the local 'init()' function, the block I previously pointed out,

Code: Select all

    if menu.isStartmenu then
        if (__CORE_GAMEOPTIONS_RESTORE == nil) and C.IsGameModified() then
            menu.contextMenuMode = "modified"
            menu.contextMenuData = { width = Helper.scaleX(400), y = Helper.viewHeight / 2 }
        elseif C.IsVentureSeasonSupported() and OnlineHasSession() and (not OnlineGetVentureConfig("allow_validation")) and (not OnlineGetVentureConfig("disable_popup")) then
            menu.contextMenuMode = "ventureextension"
            menu.contextMenuData = { width = Helper.scaleX(400), y = Helper.viewHeight / 2 }
        end
    end

causing that selecting another menu and subsequently returning to the previous menu results in an unwanted 'return' in the 'onCloseElement()' function, this translates into a double click on the back button or keys in the first instance for all games that are modified. That's why I tried to handle it from my side some time ago, although I didn't perfectly remember the reason for my code in the beginning. This time I added a comment to remember it.

Code: Select all

    -- 'menu.contextMenuMode' it's set "modified" causing that selecting another menu and subsequently returning to the previous menu results in an unwanted 'return' in 'onCloseElement()'
    if (menu.contextMenuMode == "modified") then
        if __CORE_DETAILMONITOR_USERQUESTION and __CORE_DETAILMONITOR_USERQUESTION["modified"] then
            menu.contextMenuMode = nil
        end
    end

As you can see, it has little or nothing to do with what you were asking lol, but yes, what happens to you is strange, I don't have the same experience and I can't think of what could cause it, in your particular case.