ESOUI - Event for player being fully in the world and ready?

ESOUI (https://www.esoui.com/forums/index.php)

- General Authoring Discussion (https://www.esoui.com/forums/forumdisplay.php?f=174)

- - Event for player being fully in the world and ready? (https://www.esoui.com/forums/showthread.php?t=695)

Event for player being fully in the world and ready?

I'm currently working on an addon, and I'm curious if there is a 'best practice' for what event to use to know the player is fully in the world and loaded. I see EVENT_PLAYER_ACTIVATED, but I haven't found any documentation on it. Is EVENT_ADD_ON_LOADED late enough in the process to know the player is loaded in to the world?

Through some testing, I seem to have answered my own question. EVENT_ADD_ON_LOADED is late enough in the process to query everything about the character, at least as far as I've seen. I've successfully queried the players inventory, worn gear and bank on that event and had no issues getting the data.

As an aside, I've also discovered that the item query functions on BAG_BANK work anywhere in the world. That was a pleasant surprise.

Very interesting. So I wonder in what circumstances you would use the player activated event. I always assumed that was the equivalent of the player login / entering world event used in wow but I guess that isn't the case. Very interesting indeed.

In my opinion, EVENT_PLAYER_ACTIVATED is the ESO equivalent of WoW's "PLAYER_ENTERING_WORLD". It fires at login and upon every load screen.

/edit: Also, EVENT_PLAYER_ACTIVATED fires after EVENT_ADDON_LOADED events fire. If you are having issues at load and want to print a debug statement to the chat frame, in my experience, EVENT_PLAYER_ACTIVATED is the event to use for this, as EVENT_ADDON_LOADED is too early for the chat frame.

Interesting note about the chat frame. I had noticed chat messages from d() did not print in EVENT_ADD_ON_LOADED.

I may go ahead and transition to using EVENT_PLAYER_ACTIVATED, as it seems more "correct", even if EVENT_ADD_ON_LOADED works in this instance.

For debugging, yes, feel free to use that event. If your addon is better served at EVENT_ADD_ON_LOADED, though, use that one. (You don't need to be printing messages to the chat frame every time a user logs in, for example.)

NOTE: don't forget to unregister for EVENT_PLAYER_LOADED after the first time it fires, unless you want your code to run again at each loading screen.

Quote:

Originally Posted by Brainling (Post 3354)

I'm going to start doing this too for my addons. Currently in my addon "Clarity" I must use zo_callLater() after EVENT_ADD_ON_LOADED calls for *all addons* because some addon TLWs still have not been created. This is not the case with EVENT_PLAYER_ACTIVATED.

One thing about EVENT_ADD_ON_LOADED is it's not called between zone changes, whereas EVENT_PLAYER_ACTIVATED is. And as you know, both are called on reload UI. Therefore, you just need to make sure you UnregisterForEvent EVENT_PLAYER_ACTIVATED for your addon immediately after it's called.

Yeah, I'll unregister it after the first call. I don't think I need it after that. Everything else will be a spot update triggered by another more granular event. I'm using EVENT_PLAYER_ACTIVATED to make sure my add-ons character specific environment is initialized and ready to go.

Quote:

Originally Posted by Brainling (Post 3372)

I suppose a real fail-safe way of doing it, if it's ever possible for the EVENT_ADD_ON_LOADED to happen *after* EVENT_PLAYER_ACTIVATED, is something like this:

Code:

EVENT_MANAGER:RegisterForEvent(Clarity.name, EVENT_ADD_ON_LOADED, function(event, name)

        if name == Clarity.name then

                EVENT_MANAGER:UnregisterForEvent(Clarity.name, event)

                Clarity.addOnLoaded = true



                if Clarity.playerLoaded then

                        Clarity:Init()

                end

        end

end)



EVENT_MANAGER:RegisterForEvent(Clarity.name, EVENT_PLAYER_ACTIVATED, function()

        EVENT_MANAGER:UnregisterForEvent(Clarity.name, event)

        Clarity.playerLoaded = true



        if Clarity.addOnLoaded then

                Clarity:Init()

        end

end)

Then you have your addon's "init" method called only once whether EVENT_PLAYER_ACTIVATED or EVENT_ADD_ON_LOADED happens last. Again, I have no idea if that's actually possible.

Edit - I'm not going to bother with the fail-safe, but if weird stuff happens I'll fall back to the above code.

I'm pretty sure EVENT_PLAYER_ACTIVATED will always happen later than EVENT_ADD_ON_LOADED. I would be surprised to see them happen in the opposite order. I would be surprised if ZO allowed their event order to be that non-deterministic.

I just ran into one problem.

ZO_CreateStringId must be called before EVENT_PLAYER_ACTIVATED fires. So if you use custom keybindings, you'll still need to register EVENT_ADD_ON_LOADED and do your ZO_CreateStringId calling at that point.

I don't need custom bindings, but that's still really handy for other developers to know. Good find.

Well I just did a registerallevents on the eventmanager to see what happens event wise and which order .. here they are with their first 2 parameters. I see a couple of key events there that sound like ones that may be usable to know certain aspects of the game are loaded. I tried telling it to write to the Saved Variable file but it looks like ADD_ON_LOADED doesn't have access to it. Trying to write to a temp table and then use the PlayerActivated event to write it to the saved variables table to get the other parameters.

Lua Code:

EVENT_ADD_ON_LOADED - 65536 - ZO_IngameLocalization,nil
EVENT_ACTIVE_QUEST_TOOL_CHANGED - 131102 - 64, false
EVENT_ADD_ON_LOADED - 65536 - ZO_Libraries,nil
EVENT_ADD_ON_LOADED - 65536 - ZO_Common,nil
EVENT_KEYBINDINGS_LOADED - 65547 - nil,nil
EVENT_ACTIVE_QUEST_TOOL_CHANGED - 131102 - 64, false
EVENT_ACTIVE_QUEST_TOOL_CHANGED - 131102 - 64, false
EVENT_ADD_ON_LOADED - 65536 - ZO_Ingame
EVENT_ADD_ON_LOADED - 65536 - XrysStartUpTest,nil
EVENT_KEYBINDINGS_LOADED - 65547 - nil,nil
EVENT_KEYBINDINGS_LOADED - 65547 - nil,nil
EVENT_ACTION_LAYER_PUSHED - 65548 - 1,1
EVENT_QUEST_DAILY_COUNT_CHANGED - 131100 - 540, 10
EVENT_QUEST_DAILY_COUNT_CHANGED - 131100 - 541, 10
EVENT_QUEST_DAILY_COUNT_CHANGED - 131100 - 542, 7
EVENT_QUEST_DAILY_COUNT_CHANGED - 131100 - 543, 10
etc
EVENT_QUEST_DAILY_COUNT_CHANGED - 131100 - 549, 10
EVENT_QUEST_DAILY_COUNT_CHANGED - 131100 - 551, 10
EVENT_QUEST_DAILY_COUNT_CHANGED - 131100 - 550, 10
EVENT_GUILD_HISTORY_RESPONSE_RECEIVED - 327721 - 1, 1  
EVENT_PLAYER_ACTIVATED - 131072 - nil,nil
EVENT_GUILD_REPUTATION_ADDED - 131364 - nil,nil
EVENT_SKILL_LINE_ADDED - 131367 - false,nil
EVENT_QUEST_DAILY_COUNT_CHANGED - 131100 - 554, 7
EVENT_QUEST_DAILY_COUNT_CHANGED - 131100 - 560, 10
etc
EVENT_QUEST_DAILY_COUNT_CHANGED - 131100 - 569, 10
EVENT_QUEST_DAILY_COUNT_CHANGED - 131100 - 571, 10
EVENT_QUEST_DAILY_COUNT_CHANGED - 131100 - 570, 10
EVENT_ACTIVE_QUEST_TOOL_CHANGED - 131102 - 64, false
EVENT_GUILD_MEMBER_CHARACTER_ZONE_CHANGED - 327709 - 2, @xxxxxx
EVENT_ACTIVE_QUEST_TOOL_CHANGED - 131102 - 64, false
EVENT_ZONE_CHANNEL_CHANGED - 131117 - nil,nil
EVENT_ACTIVE_QUEST_TOOL_CHANGED - 131102 - 64, false
EVENT_GUILD_REPUTATION_ADDED - 131364 - nil,nil
EVENT_SKILL_LINE_ADDED - 131367 - nil,nil
EVENT_ACTION_LAYER_PUSHED - 65548   - 6,2
EVENT_ZONE_CHANNEL_CHANGED - 131117 - nil,nil

edit: Interesting, I can't even get the saved variables table updated using the EVENT_PLAYER_ACTIVATED event. Unless, the function used to track all cannot do anything like that ... lets see.

edit2: *whistles* ... nothing to see here .. move along .. rofl .. forgot to initialise the saved variables table *slaps head*

edit3: rofl .. file created but empty ... but .. if I run a slash command to list the contents it is all there rofl .. wacky stuff these saved variables files.

Quote:

Originally Posted by Xrystal (Post 3398)

edit3: rofl .. file created but empty ... but .. if I run a slash command to list the contents it is all there rofl .. wacky stuff these saved variables files.

Now...that's actually interesting. Coincidence or actually exploitable to fire a save of variables when you want? *pondering*

The saved variables file is wrote from memory once you reload the UI, or quit the client normally. It's probably done this way for performance and anti-exploit reasons.

No, what I mean is, if you Initialise the Variables and then deliberately clear them, it doesn't clear the saved variables file itself from what I can see, just the one in memory. So, if you wanted to just keep the current session's data active you can use the temporary variable you initialise it with and if you want to see the data as a whole use the full global table and bypass the extra bocks that it comes with.

I tested it again the other day while running some other tests and again it seems to me that you can clear the active data but unless you empty the named _G[...] table for the saved variables file itself it won't clear it totally.

EG.

AddonLoaded ..
... InitSavedVars
... Clear local table used to write to saved vars
... rest of game play
... Log Out

Look at saved file and the data from before and the new data is still there in its entirety.

Did they remove EVENT_PLAYER_ACTIVATED?

It's not calling for me. No idea why :(

Nope, works just fine. Maybe you have a typo.

Quote:

Originally Posted by Seerah (Post 5079)

Nope, works just fine. Maybe you have a typo.

Thanks ... that's actually a relief. I'll try to figure out what's going on.

It works, you must have made some mistake. I did a similar thing to try to find what event precedes another. The main thing you need to watch is the saved variables is created just prior to EVENT_ADD_ON_LOADED for your addon being called as near as I can tell. So anything you placed in that variable before that is gone. If there's a saved variables file then it's replaced with that. If not then it's empty, not just left whatever it was. So you can't use that variable until the addon loaded event for your addon.

As far as your original question you should initialize your addon during EVENT_ADD_ON_LOADED. Just as a general rule your addon should be functional when that completes. Conceptually another addon should be able to watch for you to load and then use you. That doesn't mean they get accurate data since the subsystems you use may not be populated yet, but everything functions. Static data should be captured at EVENT_PLAYER_ACTIVATED though. All the subsystems are up-to-date at that point. Specifically guild and social data isn't loaded until after the addons are loaded. Also the POI locations for quests aren't loaded yet either.

Some, I believe is deferred, i.e. running async, so you can't count on when the list gets populated, just that it has been by player activation. I suspect the reason social and guild data isn't loaded until so late is they have problems with those subsystems on the server. I get about 12s from the first addon loading to character activation while my addon takes 0.017s to load. My mod for logging event isn't timestamping them yet so I can't see exactly where the delay lies, but I suspect most of it is waiting on guild and social data to load. The point being though that you can count on the order things are loaded. They seem to just send off requests and they get responses whenever the server gets around to it. The initial EVENT_PLAYER_ACTIVATED seems to fire once all initial data requests have completed.