Reason for instant crashes on PTS?
 

I have updated Srendarr to manually set the draw tier (self:SetDrawLayer(DL_CONTROLS)) on all mouse-enabled controls, verified no top level controls are set to any parent but GuiRoot, changed the combat power types to use the new global references, and still I am seeing very odd behavior.

Two main problems are occuring. First, sub menus in LibAddonMenu are unclickable, and simple toggle the submenu closed when trying to interact with them. Not sure if this is a LibAddonMenu bug or known issue.

EDIT: Needed custom subroutine to account for my custom LAM controls since I use a special method to display sub-menu controls on custom panel tabs which normally doesn't work. Each sub-widget need its draw level modified manually when the custom submenu control was opened.


The main problem however, is the second Srendarr is unlocked the entire PTS client completely exits to desktop, no error, no submit crash log prompt, just poof.

I will continue to experiment but thought maybe someone might have an idea what could have changed to cause such a radical behavior.

EDIT: Worked around the second issue by disabling the animated label on drag controls, but the reason for the crash remains elusive (see below).

I would not say it's a known issue per say. ZOS did mention that the ambiguity of buttons will have to be resolved. They told us they had issues with the ambiguity of the tier and draw levels and that was part of what they resolved for the game itself.

As much as I would like to help you with that keep in mind maybe some things are protected now. Then you have the tier and draw levels. So while I have a hard time suggesting this I would disable most of the fancy draw icons on the screen stuff or maybe gut most of the program and start with overriding one thing at a time.

If you ever overwrote ZOS xml or Lua functions then look at those again. I still have not updated MailR how I want but when I first looked at it the previous author was overriding entire functions and keybind strips. I don't know what you did to make Srendarr do what it does but you may have to comment out code and slowly mix in one thing at a time until you see what might be causing that.

Never overwrote anything, just events and simple UI hooks using API functions.

It might help if the devs could give some examples of previously functional API calls that are affected by these major changes. Hopefully in the days ahead there will be more information about scenarios that would actually require rewriting.

You would have to sift through some posts to get say the last 5 or so but the devs usually post a APIPatchNotesP34.txt that explains changes like you are mentioning. So to help with that I attached a zip of some of the docs I have.

However, they don't say anything explicit like, "If you are currently using GetSomeBuffId() your game will crash if you use it, just a heads up!" so at no point in the future will you ever know what will crash the PTS or live client if the API changed. I doubt they intend that though. There was something on another PTS that had to do with fonts that crashed the PTS and that was addressed before it went live.

I know the crash is frustrating but who knows what changes have occurred that you were unaware of not reading the APIPatchNotes religiously each update. Even I don't but I did this time around and discovered there is a new quest API even if it's not all that exciting and I can sorta get it a different way.

There is a chance the crash is unintended but if you take the time to figure it out and report that then it won't accidentally make it to the live client. Otherwise who knows.

Nope, not a known problem and not happening for me e.g. within FCOIS which got like 100 submenus ;)
Did you add custom controls in there? I have some too within the first submenu "General" where I have added a LibShifterBox e.g. and it is working fine.
Maybe your menu items you have added there got some params that force the LAm menus to behave that way then.

That's odd :-( I can only think about an endless loop but it would crash then and hang for a while and not just close the eso64.exe
What does Windows Event log say for the crash, are you able to find something in there?

PTS got known problems with the client restarting explorer.exe as you exit the client (via ALT+F4, /quit or menus).
All your icons at the taskbar are gone then because of the forced explorer.exe restart from ESO client... It's some workaround for users experiencing troubles to open Chrome after/as ESO client is running, at least this is what we found out so far by "guessing". No official answer on that so far afaik...
But this is a hacky and obviously bad workaround, if this is what is happening here, as we all can see.

Maybe it's related to your addon. But I don't think as it's addon and settings menu related afai understood your problem.
The only thig I can think about is an unhandled error if you run and API lua function with wrong params. Check the GetSlot* function changes as there was added a new param HOTBAR_CATEGORY as 2nd param (for most of these actionButton/quickSlot related API functions). If it was "inserted" as 2nd param and you pass in a value from before it might now get a wrong value and "crash".

Read my post at the official update thread in the forums please https://www.esoui.com/forums/showpos...2&postcount=20

So far narrowed this down to DisplayFrame.lua, line 369...

The function CreateDragOverlay runs without problems until it gets to this line. Which is odd, because there is nothing in the documentation re: animation as far as I can tell.

As soon as I un-comment this line:

...the game will instantly crash without error when doing /srendarr unlock.

Is anim a default Animation control (https://wiki.esoui.com/Controls#AnimationManager -> AnimationObject e.g.) ?

Not sure if this could cause the crash but as it was a recent change about controls:
Did you try to set the DrawTier, layer and level of the animation control differently (higher) already? But it really would make me wonder if this would crash the client, e.g. if the texture control or animation is somehwere below any other...

Perhaps something that got to do with the recent 3d object changes.

This is the gist of the code:

If the last line is un-commented the game instantly crashes when the code runs.

I don't think it is related to draw tiers. As you can see the DrawLevel and DrawLayer are being set.

The only scenario I can imagine is that because label has a lower draw level than its parent control it somehow causes problems, but that should really only be that it is visually below the parent and can't be clicked if mouse enabled. I can't see that causing a full game crash.

EDIT: Actually THAT even shouldn't be the case, as I believe draw level works the same as tier and layer in that a higher number means it is displayed higher on the layer stack. So the child having a higher draw layer (being on top) is actually how it should be, if I am understanding correctly?

Thank you for sharing that and thanks for showing that line you commented out. Baertram let ZOSDanBaston know and they think they may have found something.

Good to hear. :)

A fix has been submitted internally and will get merged to PTS before 34 goes live.

Thank you Dan for the quick response, and thanks Phinix for finding this ;)