Error message in the castle of nathria
Johunn opened this issue ยท 5 comments
WowUp 2.03 / WoW 9.02
Describe the bug
I had an error message when I was in the castle of Nathria, I can't say exactly when because I saw this error message in BugSack at the end of the raid .
Do you have an error log of what happened?
14x DBM-StatusBarTimers\DBT.lua:1118: Action[SetPoint] failed because[Cannot anchor to a region dependent on it]: attempted from: DBT_Bar_7:SetPoint.
[string "=[C]"]: in function SetPoint' [string "@DBM-StatusBarTimers\DBT.lua"]:1118: in function Update'
[string "@DBM-StatusBarTimers\DBT.lua"]:947: in function SetElapsed' [string "@DBM-StatusBarTimers\DBT.lua"]:890: in function <DBM-StatusBarTimers\DBT.lua:886> [string "=(tail call)"]: ? [string "@DBM-CastleNathria\TheCouncilofBlood.lua"]:769: in function handler'
[string "@DBM-Core\DBM-Core-9.0.17.lua"]:896: in function <DBM-Core\DBM-Core.lua:883>
[string "=(tail call)"]: ?
[string "@DBM-Core\DBM-Core-9.0.17.lua"]:896: in function <DBM-Core\DBM-Core.lua:883>
Locals:
Skipped (In Encounter)
To Reproduce
IDK
Screenshots
//
Did you try having DeadlyBossMods as the only enabled addon and everything else (especially something like ElvUI) disabled?
I only have DBM, and yes I have Elvui last version, and I can't try without it because I don't know when exactly I had the error :s.
Which version of DeadlyBossMods are you using?
<DBM 9.017>
Was it working in a previous version? If yes, which was the last good one?
Can't say...
Additional context
//
I'll do more work on this issue tomorrow. The hack artemis put in would silence it but not fix core issue, I believe I identified actual issue and have some shotty code to fix it at source, but that needs testing.
it's a niche issue to say the last related to using a bar style that's not the default, on top of using a method that's seldom used (RemoveTime). the bug won't occur in situations there are no bar moving animations that are happening while time is being removed from a bar. You managed to find an issue that's existed since antorus but didn't affect anyone because it doesn't affect default options. Grats!
Based on my testing, this issue should be resolved in latest alpha, of course you need to use alpha to be sure of it, but all my internal testing allowed me to spam add/remove time for timers without any failures, even timers that were under the "moving" condition while they were updated when I was running the Classic bar behavior.