Porting to a Wayshrine - Only partial UI-Reload ? Persistent TopLevelWindows ..

[thelegendaryof]

Yo,

I've release my ChatTabs Manager yesterday with an short Example Plugin that doesn't use
any complicated code just the CALLBACK_MANAGER to setup it 's Tabs.

Manager: http://www.esoui.com/downloads/info1...bsManager.html
Example: http://www.esoui.com/downloads/info130.html

Today I've noticed a strange Bug.

If I port to a Wayshrine - after the Loading Screen - the TopLevelWindows I created before with wm:CreateTopLevelWindow(controlName) which get stored in CETA.chatTabs (which is a simple table, CETA = ZO_Object:Subclass()) seem to stay persistent which will at the moment raise an error.

Edit:

God I'm stupid. Fixing what isn't broken.

I actually forgot to UNHOOK OnPlayerActivated after the first initialization not knowing that it will get retriggered after every loading screen. I actually thought every Addon gets reloaded completely after every Loadingscreen. LMAO!

I'll let that stay here for everyone else thinking the same. Wall of Fame!

[Seerah]

Curious... Why are you trying to get the garbage collector to take care of your frame?

[thelegendaryof]

Well it 's not "one" frame but many frames (f. e. if multiple plugins are using it) that get stored in:

 
CETA.chatTabs[x].control

CETA is my Subclass Instance defined as a Global like this:

 
CETA = ZO_Object:Subclass()

Everything is working as intended after load. Also when reloading the UI the Memory is fresh and clean and no Errors popup.

But when I'm porting to a Wayshrine (and only then!) it seems like my CETA object and every child (e. g. CETA.chatTabs) of it isn't cleaned / reset properly - it still persists in the Memory with the former state (and won't get reset even when I'm forcefully calling the garbage collector). That is why I will get an Error that a formerly created TopLevelWindow Control is already existing (e. g. Can't create Control. Control MY_DEBUG_CONSOLE is already existing).

That is due to client still triggering all loading Events like it 's a "clean" start in my case. The same goes for the TopLevelWindow Control (CETA.chatTabs[x].control) - it 's still existing in the Memory including all of it 's children (e.g. Buttons, Background and so on).

The Events I'm speaking about are Setup and Registered like this:

function CETA:OnAddOnLoaded(event, name) ... end
function CETA:OnPlayerActivated() CALLBACK_MANAGER:FireCallbacks("CETA_ADD_TABS", self) end

em:RegisterForEvent(self.addonName.."_OnAddOnLoaded", EVENT_ADD_ON_LOADED, function(...) self:OnAddOnLoaded(...) end)
em:RegisterForEvent(self.addonName.."_OnPlayerActivated", EVENT_PLAYER_ACTIVATED, function(...) self:OnPlayerActivated(...) end)

As far as I found out (I'm pretty new to Lua) it seems like that the Garbage Collector failed to clean up the Memory correctly. That might be due to the way the native API-Functions and their metatable are setup or because my code itself is setup in a way that the Garbage Collector can't grab it by itself. Sounds logical, due to CETA being a global and not a local variable. Maybe ZOS is usually calling an selfmade Garbage-Collector for Plugins at load which won't get called when porting to minimize the loading time or they just simply forgot to call it? Hm.

Either way, by traversing and niling with my above functions it I'm able to get it garbage collected successfully before re-initializing it properly again. I could've choosen to work with the old copy from the Memory but that might lead to more problems in the future due to wrong memory addresses and stuff which seems worse to me then to marking it up for cleanup for myself and reinitializing it once after porting.

Is that a bad practice or a wrong conclusion (as said I'm a pretty new to Lua, so I'm a bit unsure) ?

Cheers!

[Xrystal]

I came across the same with while testing out/learning the ZO_Object/ZO_ObjectPool/ZO_ControlPool functionality.

It's the first time I have come across it so sounds like it is linked to those values which, of course isn't documented anywhere to know what to do in these situations.

For now, seeing as I am testing, I just told it to test for its existence and only create it if it didn't already exist but with live data it may be more of a problem.

[thelegendaryof]

Hm, ok.

Even niling out all the instances (!) of the TopLevelWindow including any children (!) and methods (!) ESO will still keep it as a children with a copy and even the GUI will still stay. Thought you're able to create another TopLevelWindow with the same Name as a new Children (thought the GUI seems to stay the same). Pretty, pretty weird! Zgoo tells me there are two Children with the same name then.

There is no API-Function (yet) to remove UI stuff completely from the Memory - right?

So for now like you said:

Check if the UI-Element exists and link to the Instance rather then niling it
(as the Garbage collector will clean the link but it will never get deleted)

[Seerah]

Don't force the garbage collector to run. Reuse your frames if and whenever possible. I have no idea what you could be doing that would prevent you from reusing the frames (or just hiding them and leaving them in memory for the rest of the game session).

EVENT_PLAYER_ACTIVATED fires at login and for every loading screen afterward. If you don't need the event after you login, unregister it.

[thelegendaryof]

Jesus, I love you Seerah. Thanks for pointing out that EVENT_PLAYER_ACTIVATED will get refired after every Loadingscreen.
I actually seriously thought that the Plugins would get completely reloaded not matter what ... (facepalm)

Fixing what isn't broken. I'm good at that ...

[Seerah]

Glad you got it all fixed.