Not sure where to ask this. So please move it somewhere else, if appropriate.
- Fixed
UnitBuffInfo
was able to access hidden buffs information unintentionally.
Could a DEV explain why this change was necessary ?
Not sure where to ask this. So please move it somewhere else, if appropriate.
UnitBuffInfo
was able to access hidden buffs information unintentionally.Could a DEV explain why this change was necessary ?
Not sure where to ask this. So please move it somewhere else, if appropriate.
- Fixed
UnitBuffInfo
was able to access hidden buffs information unintentionally.Could a DEV explain why this change was necessary ?
Yes pls explain. How should players read out buffs now, that prevent specific buffs. For example the 15sec CD of Warden 104 ISS was triggert of a hidden buff
It was a mistake of creators of initial function. There never were supposed to be a way to read hidden buffs, because like their name says, they are hidden. So no player should have access to them. All other functions have them always hidden already. So it was a bug.
Greetings
Not sure where to ask this. So please move it somewhere else, if appropriate.
- Fixed
UnitBuffInfo
was able to access hidden buffs information unintentionally.Could a DEV explain why this change was necessary ?
Yes pls explain. How should players read out buffs now, that prevent specific buffs. For example the 15sec CD of Warden 104 ISS was triggert of a hidden buff
And how we should do that? grox
So 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.
Display 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.
I agree and had the same problems. Seems like UnitBuffInfo now only works on buffs which have a BuffTime. Permanent Buffs, without a BuffTime won't be detected by UnitBuffInfo, only UnitBuff.
Edit: I mean the ID of a permanent buff. Names still work.
Change included only using same checker for if buff is displayed in same way like in UnitBuff.
Please remember that indexes in UnitBuffInfo and UnitBuff will be different, since UnitBuffInfo includes both buffs and debuffs, while UnitBuff is separate to UnitDebuff.
Greetings
Display 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:
local 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
Display More
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!