"script ran too long" out-of-combat after 7.2.5
I've been getting a "script ran too long" error with several addons after 7.2.5 hit. Interestingly this happens out-of-combat which is strange because I thought that the addon execution time limit applied only in combat.
Here are pastes of the errors:
If you look at the lines where this is happening in Details, you'll notice that they are expected long-running functions (collectgarbage, UpdateAddOnMemoryUsage) that are surrounded by a `not InCombatLockdown()` clause. The Details author clearly had the same idea as me, that addon execution time limit is only enforced in-combat and it should be safe to call these expensive functions outside of combat. I know ArkInventory has some coroutine-stuff that yields in combat when it would otherwise hit the script execution time limit, but does not do so outside of combat. So does anyone know, what has changed in 7.2.5 that causes script execution time to sometimes be enforced out of combat? This doesn't seem to be a consistent thing since if I type in chat something like /run local x=1 for i=1,5*10^8 do x=x+i end it will happily run for 4 seconds without any errors (as long as I'm not in combat). |
I'm curious about this too. I have a configuration panel created on demand that contains quite a few textures and frames and can sometimes cause a small stutter when loaded for the first time. In almost all cases where that happens, this error is not produced, but as of 7.2.5 I've seen it once or twice.
These configuration panels are not accessible in combat, so the "script ran too long" error is truly pointless in this case. It also breaks the execution path and displays incomplete panels when it happens. I'm really wondering what the point is. Why break the code if it's executed out of combat and seemingly has more to do with the UI back end than how the code is written? The end user of an add-on probably prefers a small frame stutter over broken code and lua errors. Hopefully it's just a bug. |
Seems like it's applied out of combat now too, which is bad news for load on demand addons.
|
GetContainerItemLink and GetContainerItemInfo have been causing these errors for me in an addon I use, SmartBuff, especially after hearthing/portaling (ie. PLAYER_ENTERING_WORLD) but also at random times I've attributed to OnUpdate overload.
Basically cycling through bags and slots in a loop I've "de-compressed" the timing of these calls with a C_Timer.After as well as after the event which to-date has "fixed" this particular problem. |
Still could be an issue with InCombatLockdown() saying "yeah you are out of combat, kappa".
|
Yea, I've never trusted InCombatLockdown() by itself. There's actually other functions that can't be trusted, like IsInGroup() returning false while in a group. My addons that deal with combat restrictions combine that with a variable set by the REGEN events. Both the variable and the function return have to be false before I do things meant for out-of-combat.
|
Quote:
|
I had the error portaling from major city to major city after logging in.
|
Just logging in, moving/jumping around, and then doing the long-running thing (opening bags, opening WA options) can sometimes trigger it for me. No zoning, no combat. There may or may not have been combat log events, not 100% sure.
|
Quote:
|
Quote:
|
Quote:
|
Quote:
|
Quote:
It would be more retarded when you dc in a bossfight then not a single addon could build up their secure frames after you log back in. |
Quote:
Combat and lockdown are two separate things and the lockdown always fires after you enter combat. You can even use an event handler to do secure stuff in response to entering combat, which is useful for when you have some behaviour that happens on secure frames but should only happen in or out of combat. If your theory was true, any action bar addon, unit frame addon or anything else using secure templates would not work when you log in after a disconnect mid-combat. |
Quote:
|
It also occurs for just a moment whenever entering combat to give the UI time to react to being in combat. Showing target frame, a hidden actionbar, [combat] macros, etc.
|
Quote:
|
Yes. PLAYER_REGEN_DISABLED is the event to look for to know when you are entering combat.
event fires UI updates for combat InCombatLockDown() returns true |
FYI according to Infus in response to my ticket about this error with WeakAuras, this is a Blizzard error that will be fixed with 7.3.
https://www.wowace.com/projects/weakauras-2/issues/981 |
All times are GMT -6. The time now is 10:27 AM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI