As title, I've found a bug of Target.MyBuff that effects dot classes (point at Necro) in raid.
So this TLO is a fabulous one for dot class to see if MY OWN dots on mobs or not. It can cut a load of code like scanning the debuffs 1-97 etc especially when you have multiple necros.
And it works flawlessly normally, ALTHOUGH when the debuff counts >56? 60? (I'm not sure about the exact upper limit, but I can reproduce this easily), weird things happen.
Say each necro has 12 dots to stack, there always will be a X between 1-12 (pretty random) and ${Target.MyBuff[${dotX}]} will return NULL no matter dotX is on mob or not.
(I've also notice that ${Target.Buff[${dotX}]}) will always be correct but it can not tell you it's your own dot or not---> then you will need use Target.Buff[].Caster, and scanning 1-97 debuff slots again, and that's exactly the loop I want to avoid)
Here is some screenshots for the scenario, see the red circle icon=dot7=Pyre of the Wretched, it's on mob, but ${Target.MyBuff[${dot7}]} still return as NULL.
So this TLO is a fabulous one for dot class to see if MY OWN dots on mobs or not. It can cut a load of code like scanning the debuffs 1-97 etc especially when you have multiple necros.
And it works flawlessly normally, ALTHOUGH when the debuff counts >56? 60? (I'm not sure about the exact upper limit, but I can reproduce this easily), weird things happen.
Say each necro has 12 dots to stack, there always will be a X between 1-12 (pretty random) and ${Target.MyBuff[${dotX}]} will return NULL no matter dotX is on mob or not.
(I've also notice that ${Target.Buff[${dotX}]}) will always be correct but it can not tell you it's your own dot or not---> then you will need use Target.Buff[].Caster, and scanning 1-97 debuff slots again, and that's exactly the loop I want to avoid)
Here is some screenshots for the scenario, see the red circle icon=dot7=Pyre of the Wretched, it's on mob, but ${Target.MyBuff[${dot7}]} still return as NULL.
