Display MoreDisplay MoreSo we need to use clunky timers again for skill procs ? That is very unfortunate and means a lot of work.
I honestly don't see why this was seen as a problem in the first place.
Moreover, there seems to be a general issue with UnitBuffInfo after the patch, that is not directly related to hidden buffs.
I had to switch to UnitBuff for my stack-counters (for skills such as Forge-Effect from Champion) since UnitBuffInfo ceased to work. Forge-Effect is not a hidden buff, it is displayed and has both name and ID.
Not quite sure what causes this, but I suspect the latest change to hidden buffs prevents my function from iterating through my (ordinary) buffs as it should. Using UnitBuff it works.
Regarding timers, a friend of mine has found a solution to avoid timers.
Saving the current time when your skill was casted with "GetTime()" and then comparing the difference of that registered time against the current "GetTime()" with your condition is a very efficient way to avoid timers.
Not quite the solution you were looking for probably, but this works really well when there's no other way.
A simple (quick and dirty) example function that does something like this:
CodeDisplay Morelocal C_TIMERS = {}; -- Use in your condition function isTimedSkillReady(name, duration) -- No registered time, skill should be ready. if (not C_TIMERS[name]) then return true; end -- If the registered time + duration is less than or equal to the current time, skill should be ready. if ((C_TIMERS[name] + duration) <= GetTime()) then C_TIMERS[name] = nil; return true; end -- Skill is not ready. return false; end -- Use when casting the skill function setTimer(name) if (C_TIMERS[name] then return; end C_TIMERS[name] = GetTime(); end
This is the approach I'm already using and which I, technically incorrectly, referred to as a timer.
My point is all that additional code could have been a single, short line in the past and I still don't see why the latest change to UnitBuffInfo was necessary.
Appreciate it though Amzi!