ESOUI - API 100030 and LibChatMessage Overrides

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

- Tutorials & Other Helpful Info (https://www.esoui.com/forums/forumdisplay.php?f=172)

- - API 100030 and LibChatMessage Overrides (https://www.esoui.com/forums/showthread.php?t=8996)

API 100030 and LibChatMessage Overrides

With this patch the chat system has been modified a bit. Some of you may run into issues with the new CHAT_ROUTER. I'll share what fixes one of my addon required, so it may help you with your addon :)

My addon is used to override the default Friend Login message. The old code:

Code:

ZO_ChatSystem_GetEventHandlers()[EVENT_FRIEND_PLAYER_STATUS_CHANGED] = statusChanged

I had to change it to both update the original table, so that LibChatMessage can use my override, and also the new CHAT_ROUTER. The new code:

Code:

ZO_ChatSystem_GetEventHandlers()[EVENT_FRIEND_PLAYER_STATUS_CHANGED] = statusChanged

CHAT_ROUTER.registeredEventHandlers[EVENT_FRIEND_PLAYER_STATUS_CHANGED] = statusChanged



EVENT_MANAGER:UnregisterForEvent("ChatRouter", EVENT_FRIEND_PLAYER_STATUS_CHANGED)

EVENT_MANAGER:RegisterForEvent("ChatRouter", EVENT_FRIEND_PLAYER_STATUS_CHANGED, statusChanged)

Any feedback is welcome. Enjoy!

Shouldn't the lower line "EVENT_MANAGER:RegisterForEvent("ChatRouter"" use your addon's name than instead of ChatRouter again?

Edit:
Please read my comment about your addon's hardcoded library calls from your addon txt file:
https://www.esoui.com/downloads/file...=1975#comments

This did (not your addon so far but others did in the past months) and will break other addons in the future!
Please change this to use the libraries, which provide an own txt file, properly with their txt file, or do not include + add them to ## DependsOn and let users just install it as a standalone version into their AddOns folder.

Quote:

Originally Posted by Baertram (Post 40393)

Shouldn't the lower line "EVENT_MANAGER:RegisterForEvent("ChatRouter"" use your addon's name than instead of ChatRouter again?

...
Please change this to use the libraries, which provide an own txt file, properly with their txt file, or do not include + add them to ## DependsOn and let users just install it as a standalone version into their AddOns folder.

As I'm overriding the event, I'm using the original identifier. I would use a new name (such as my addon's) if I wanted to add another event to the existing one. [That's my understanding of the API.]

I appreciate your detailed post about the other included libs. As the comments section is not for general addon related requests, I copied and removed it. It looks like a meaningful time investment to update my addons to match the recent changes from the libs.

I wonder if an addon loading those lib files for itself helps prevent compatibility issues, as would happen from regularly updating into newer releases. (Something I had to deal with and fix with LAM2 before.) Might be more luck than brains. :p

Quote:

As I'm overriding the event, I'm using the original identifier. I would use a new name (such as my addon's) if I wanted to add another event to the existing one. [That's my understanding of the API.]

Right. As yo u have removed the original function with the unregister already: adding it new with your own addon's tag should work and identifies your addon instead of telling others "this is ZO's code".

Quote:

to match the recent changes from the libs.

The ## AddOnVersion: <unsignedInteger> tag was already added with the Summerset patch.
This was the time as LibStub got obosolete but was used in a wide range of addons already.
But the better approach is to use the own txt file of a dependency and let the ingame vanilla ZOS addon manager handle this to only load the newest version of a dependency.

Quote:

I wonder if an addon loading those lib files for itself helps prevent compatibility issues, as would happen from regularly updating into newer releases. (Something I had to deal with and fix with LAM2 before.) Might be more luck than brains.

"An addon loading those lib files for itself" = hardcoded library file names called from your addon's manifest txt file?

This can work fine IF you update your addons properly at the same time as the dependencies update.
And this only works as long as the library LibStub is still used for these dependencies. It will assure that the newest version of the dependency is loaded.
AS LibStub is obsolete and is telling you that ingame already with the latest patch you should remove the usage in your addons, where possible now.
And change it to the vanilla UI usage of dependency's manifest txt file -> ## IsLibrary: true, ## AddOnVersion <unsignedInteger> tags.

If you do not update the libraries shipped with your addon, and they do not have an own txt file to assure the newest version installed somewhere else is loaded prior to the embedded old files: the same thing will happen as mentioned in multiple threads, e.g.
https://www.esoui.com/forums/showthread.php?t=8970
https://www.esoui.com/forums/showthread.php?t=8969

Whatever solution is more apoplicable for you, it's up to you. imo it's easier to make this work with the vanilla UI stuff than having to check and update the files at each patch manually to assure it works. That's not the idea of libraries, at least not for those that are commonly spread and got a wide usage.

I was actually worrying more about my addons having incompatibilities with libs' newer versions :D But yes, me using the older libs could cause issues, as well. Although it hasn't yet, luckily.

I agree that simply removing the libs from my addons and just noting them as requirements is the best move. It'll just take time and testing. When siri brought the topic up, I was on the disagreeing side about dropping LibStub and simply putting our faith in Zeni's changes. Alas, we follow the one true dev :p

I'll get to it soon enough. I appreciate your efforts in mobilizing the dev' community on this, Baertram.