OK, so I managed to track down this specific case, and (HOPEFULLY) it will help others to eliminate this from their addons as well.
It appears to be a change in the way ZOS is handling hooks to certain global functions. For example in Master Recipe List, I narrowed the above errors down to two specific hooks. By changing these to use ZO_PreHook() I was able to keep the functionality of the hook and avoid these insecure code errors. So:
Code:
local ESOMRL_ZO_TreeHeader_OnMouseUp = ZO_TreeHeader_OnMouseUp
ZO_TreeHeader_OnMouseUp = function(self, upInside)
if GetCraftingInteractionType() == CRAFTING_TYPE_PROVISIONING then
local treeNode = self.node.tree
if treeNode.exclusive or treeNode.open then
treeNode.exclusive = false
treeNode.open = false
end
stationNav = 1
stationItem = 1
ClearStationSelection()
end
ESOMRL_ZO_TreeHeader_OnMouseUp(self, upInside)
end
Becomes:
Code:
ZO_PreHook("ZO_TreeHeader_OnMouseUp",
function(self, upInside)
if GetCraftingInteractionType() == CRAFTING_TYPE_PROVISIONING then
local treeNode = self.node.tree
if treeNode.exclusive or treeNode.open then
treeNode.exclusive = false
treeNode.open = false
end
stationNav = 1
stationItem = 1
ClearStationSelection()
end
end)
...and:
Code:
local ESOMRL_ZO_TreeSetNodeOpen = ZO_Tree.SetNodeOpen
ZO_Tree.SetNodeOpen = function(self, treeNode, open, userRequested)
if GetCraftingInteractionType() == CRAFTING_TYPE_PROVISIONING then
if stationNode == 0 then open = false stationNode = 1 end
if stationItem == 0 or stationNav == 0 then open = false end
end
ESOMRL_ZO_TreeSetNodeOpen(self, treeNode, open, userRequested)
end
Becomes:
Code:
ZO_PreHook(ZO_Tree, "SetNodeOpen",
function(self, treeNode, open, userRequested)
if GetCraftingInteractionType() == CRAFTING_TYPE_PROVISIONING then
if stationNode == 0 then open = false stationNode = 1 end
if stationItem == 0 or stationNav == 0 then open = false end
end
end)
YMMV but at least it a clue.
EDIT:
So the obvious question for Master Chip (or anyone more knowledgeable) would be, WHY?
If I had to guess it would be the way internal references are cleared out from the active context, and it not happening with custom hooks because of some "waiting for return" type state, and some other, newer function that requires code states be "unburdened" by such waiting states in order to be considered "secure."
/stabdark