ESO crashing more often due to addons?
 

Anybody get the impression that the game crashes (freezes) much more than it ever did before, while working on addons? It's been pretty aggressive for me. Wonder if it's due to any "optimizations".

No, not by addons so far but by client changes I get the impression. Even with addons disabled it crashes sometimes for no obvious reason. And gpu drivers also give me that impression recently. Fps drop, client crashes. Older versions are more stable so I switched back.

Big yikes. Trying to update / develop addons now is a constant crashing fest. I wonder what's been changed that would cause this? Usually I'd get regular errors when I did something invalid, like a bad call.

I guess you need to give more detail as this is not happening for me.
If you produce endless loops the client normally freezes.
But crashes, have not produced one by addon tests or coding so far this year (only on PTS as the companions were added and one changed the clent language via script -> crash. But this was fixed before last update to live already) :p

Maybe if you tell us what produces a crash for you in detail we are able to test if this happens for us as well.

Yeah, something seemed off with my specific set up, getting all those crashes from addons. Had a hunch and it was right: https://www.esoui.com/downloads/file...=2485#comments (redirects errors to chatbox)

Printing to chat is more iffy now. Heck, I haven't tried it without chat addons like rChat enabled, but it didn't use to be the case a year ago.

I dislike mods that redirect Lua errors so they don't annoy users. There are only two Lua errors I won't fix in MM. One is because the MM window is open prior to initializing everything and the other is when there is a corrupt record and I'm not about to make instructions on how to find the needle in the haystack.

Otherwise unless an author knows what Lua errors users should expect they need to be corrected. To me it's like driving down the road with your car on fire and then redirecting the audible sound telling you to get out before your car explodes to make it silent so you don't have to listen to it over and over and over. If the car drives while on fire it's fine right? I can't think of a better analogy to illustrate the proper emphasis that errors are important.

I just can't think of any reasonable or valid reason to ignore an Lua error using BugCatcher or No, thank you or anything else.

Yeah, your words in the ears of those "annoyed users". Unfortunately they won't tell the errors as this is sooooo much time they would have to invest and as long as the UI is not broken and they can go on playing, supressing them is less work :confused::(:(:(
I'm very annoyed of these suppressing addons as well, as I got so much error reports which were related to just a broken UI because of errors they due not see/didn't not want to see and so on.

@Phuein Instead of printing to chat the old way and having to adjust it each time a patch comes up make use of LibChatMessage, or use the d() message (which was not invented to show chat messages but debug information though!).
And for your debugging or info messages use LibDebugLogger and DebugLogViewer. Helps a lot to track errors and provides a list of installed/Activated addons if they share their SV file of LibDbeugLogger.

Agreed about hiding errors. To be fair though, the default shouldn't be that much of a bother to normal users. Make it easy for them to pass on the log msg to us devs.

I'm not the No, thank you! addon dev, and besides it looks like it does use d() already. Which should work for anything without crashing - always had for me. Is LibChatMessage designed for handling this kinda stuff? I haven't used it directly for any of my addons. If you know more, you should definitely post another comment on the addon page recommending it!

Other addons interacting with the output doesn't seem like the issue in this case. Does CHAT_ROUTER fix the invalid formatting that causes crashes? Looks like that's the only difference from using d().

Not sure what you compare CHAT_ROUTER to here?
CHAT_SYSTEM?
It's only left over as compatibility alias to the newer KEYBOARD_CHAT_SYSTEM, which is an object of the newer class ZO_ChatSystem.
https://github.com/esoui/esoui/blob/...iases.lua#L820

And CHAT_ROUTER is ZO_ChatRouter which handles formatting etc. now.
https://github.com/esoui/esoui/blob/...dlers.lua#L167

Not sure what causes the client crashes here, maybe code page differences. I also remember there was a chat related issue Sharlikran worked on in the gitter.im/esoui/esoui channel with some Korean/Chinese dev. They found out there needs to be fixed something and I think this was done on PTS already.

Are you able to reproduce the crash on live and PTS? Maybe it's the same that Sharlikran noticed and it's meanwhile fixed on PTS?

This has been fixed but it's basically because of characters in unofficial translations like Korean as an example. The issue was due to an IME issue. It only happens when you delete characters you are typing. As far as I know it's not related to output to the chat window.

Yeah, sounds unrelated. Also, I don't have PTS installed :P Been mostly away for the last year.

I was comparing CHAT_ROUTER used in LibChatMessage to just using d(). Would be lovely to know if Zeni' recommends not using d() anymore. They do still have it in the code base. Anyways, I'll keep CHAT_ROUTER in mind for future chat issues.

I think CHAT_ROUTER is used in d() so this makes no difference:
https://github.com/esoui/esoui/blob/...gutils.lua#L36

And Zeni does not recommand anything. d() was meant to be used for debug messages (as d for debug already tells us :p) and not "normal addon output" to chat. But we all mostly used it for exatcly that purpose, where othr ways would have been the correct ones.
So if we create /change addons we should not stick to d() anymore but use e.g.
The same is sued for system and debug messages, only with the fixed event = "AddSystemMessage".
Normal chat messages run through that formatting function as well with the event = the event used like group joined, etc.
See a list here:
https://github.com/esoui/esoui/blob/...hatdata.lua#L1

The old way was to use CHAT_SYSTEM:AddMessage(messageText) which now points to CHAT_ROUTER:AddSystemMessage()
https://github.com/esoui/esoui/blob/...iases.lua#L820
So this is kinda the same like using d(), because

d() does:
And LibChatMessage defines an even better way where you can output messages related to your addon with a defined prefix and other features.

In total I'm not concerned if d() is "abused", but there often had been trouble as d() uses the system channel and some addons suppress system messages. So an alternative output, to normal chat channels, or via LbChatMessage or even LibDebugLogger would be better imo.

Thanks for the details. Looks like using d() shouldn't be the cause of the above issue then, and as it's for printing error messages, it does seem suitable. If only the whole game was open-source and we had access to see core changes :D