It seems to occur only during instance: dungeon or raid, rarely, and not in open world.
Sorry, but, the only log that I have is the following, I hope that it would be sufficient.
Message: invalid key to 'next'
Time: Sat Mar 20 13:57:36 2021
Count: 1
Stack: invalid key to 'next'
[string "=[C]"]: in function `(for generator)'
[string "@Interface\AddOns\TellMeWhen\Lib\LibDogTag-Unit-3.0\LibDogTag-Unit-3.0.lua"]:49: in function <...MeWhen\Lib\LibDogTag-Unit-3.0\LibDogTag-Unit-3.0.lua:46>
[string "@Interface\AddOns\TellMeWhen\Lib\LibDogTag-Unit-3.0\LibDogTag-Unit-3.0.lua"]:56: in function <...MeWhen\Lib\LibDogTag-Unit-3.0\LibDogTag-Unit-3.0.lua:55>
I am trying this (Take a table copy before processing it):
local function fireEventForDependents(event, unit, ...)
local wackyDependents = normalUnitsWackyDependents[unit]
if wackyDependents then
local idx01 = 0
local wackyDependentsCopy = {}
for unit in pairs(wackyDependents) do
idx01 = idx01 + 1
wackyDependentsCopy[idx01] = unit
end
for idx02 = 1, #wackyDependentsCopy do
local unit = wackyDependentsCopy[idx02]
DogTag:FireEvent(event, unit, ...)
end
end
end
Yeah, that would fix it for sure but isn't very performant. Some of those tables can get up to be pretty large - 60+ entries in a 40 man raid from what I saw in testing last night.
This appears to actually correct the problem. But I totally agree with you that it is not efficient. However, you said earlier that this bug is at least 8 years old. So, while waiting for a more effective correction, this kind of patch would temporarily fix the problem. It's a little better, if it's a little slower, but bug-free. Finally, this is my personal opinion :) Anyway, thank you very much for your addon.
TellMeWhen v9.0.5.
It seems to occur only during instance: dungeon or raid, rarely, and not in open world.
Sorry, but, the only log that I have is the following, I hope that it would be sufficient.
Message: invalid key to 'next' Time: Sat Mar 20 13:57:36 2021 Count: 1 Stack: invalid key to 'next' [string "=[C]"]: in function `(for generator)' [string "@Interface\AddOns\TellMeWhen\Lib\LibDogTag-Unit-3.0\LibDogTag-Unit-3.0.lua"]:49: in function <...MeWhen\Lib\LibDogTag-Unit-3.0\LibDogTag-Unit-3.0.lua:46> [string "@Interface\AddOns\TellMeWhen\Lib\LibDogTag-Unit-3.0\LibDogTag-Unit-3.0.lua"]:56: in function <...MeWhen\Lib\LibDogTag-Unit-3.0\LibDogTag-Unit-3.0.lua:55>
Locals: (temporary) = {
}
(temporary) = "party1target"
ascott18
commented
3 years ago
ghost
commented
3 years ago
ascott18
commented
3 years ago
ghost
commented
3 years ago
ascott18
commented
3 years ago
- © Githubissues.
- Githubissues is a development platform for aggregating issues.
This is a bug in https://github.com/parnic/LibDogTag-Unit-3.0. It has been reported at least 8 years ago - https://www.curseforge.com/wow/addons/libdogtag-unit-3-0/issues/32
I am trying this (Take a table copy before processing it):
local function fireEventForDependents(event, unit, ...) local wackyDependents = normalUnitsWackyDependents[unit] if wackyDependents then local idx01 = 0 local wackyDependentsCopy = {} for unit in pairs(wackyDependents) do idx01 = idx01 + 1 wackyDependentsCopy[idx01] = unit end for idx02 = 1, #wackyDependentsCopy do local unit = wackyDependentsCopy[idx02] DogTag:FireEvent(event, unit, ...) end end end
Yeah, that would fix it for sure but isn't very performant. Some of those tables can get up to be pretty large - 60+ entries in a 40 man raid from what I saw in testing last night.
This appears to actually correct the problem. But I totally agree with you that it is not efficient. However, you said earlier that this bug is at least 8 years old. So, while waiting for a more effective correction, this kind of patch would temporarily fix the problem. It's a little better, if it's a little slower, but bug-free. Finally, this is my personal opinion :) Anyway, thank you very much for your addon.
You're posting this on the wrong addon. Again, this is a bug in LibDogTag-Unit-3.0, not TellMeWhen.