|
|
|
|
11/20/09, 2:07 PM
|
#228 | |
|
Happy October 19th!
|
|
|
|
|
|
11/21/09, 4:35 PM
|
#229 |
|
Glass Joe
|
The jerking lag issues occur whenever I cast any sort of spell... I also run WiseEclipse on the PTR, but I have tried WE without SSA, and SSA without WE, and both of them together, but alas, the lag is always there when SAA is present
 |
|
|
|
11/21/09, 5:37 PM
|
#230 | |
|
Glass Joe
|
|
|
|
|
|
|
11/21/09, 8:09 PM
|
#231 | |
|
Happy October 19th!
|
|
|
|
|
|
|
11/23/09, 9:45 PM
|
#232 |
|
Glass Joe
|
Last edited by mader : 11/23/09 at 10:02 PM. |
|
|
|
|
11/23/09, 10:00 PM
|
#233 | |
|
Happy October 19th!
|
|
|
|
|
|
|
12/04/09, 5:25 PM
|
#234 |
|
<Druid Trainer>
|
|
|
|
|
|
|
|
|
12/04/09, 6:13 PM
|
#235 | |
|
Happy October 19th!
|
UnitAura() is a call which, provided an index, returns information about the buff occupying that slot on a given unitID. This is a proactive call - you have to use it yourself. For hopefully obvious reasons calling this every onUpdate would be a bad idea unless you know that there's a buff you should be looking for. It does, however, contain a lot of information about the buff requested, including owner and time remaining. UNIT_AURA() is an event with a single parameter - unitID. This event is fired every time someone around you has their auras change. It is not, in itself, very useful, as there is no information about which aura changed, only which unit had a change. To get actual aura information, you would need to pair this with UnitAura(). SPELL_AURA_APPLIED/REMOVED is a combat log entry which provides all of the information about which buff was applied to which unit, by whom, and other similar info. No time-based information, though. SAA uses this event to determine when to start checking for buffs using UnitAura(), which is miles more useful than UNIT_AURA since it won't do any checks unless it knows the buff is going to be there. In 3.3, SPELL_AURA_APPLIED no longer shows in the combat log for Eclipse, which pretty much guts SAA. There are workarounds based on UNIT_AURA (or hell, even just calling UnitAura() every OnUpdate()), but it would be fairly silly to just toss that sort of thing in there for just Eclipse - I'd want to rewrite the engine entirely so that performance doesn't take a nosedive. That sort of a rewrite just isn't in the cards unless/until I resub. As for why they did it, my guess is that they're obfuscating the Eclipse buff by one level. When Eclipse procs, you actually gain an invisible buff (or debuff?) that cannot be removed so that you cannot proc the other Eclipse for 15 seconds (this is a separate mechanic from an internal cooldown). There's not much point in letting this buff into the combat log, so it doesn't show up. The crit/damage buffs you gain, and which can be seen on your buff bars, are then some sort of child of this first buff, and are also not shown in the combat log, likely as some sort of interaction with the first buff being protected/internal/whatever. It's probably not intentional that the buffs no longer show in the combat log, just a byproduct of the tech they needed to make the lockouts work properly. Eclipse likely still shows up in a UnitAura() run (hell, even the protected buff might) but, without a way of knowing to look for it, it's effectively invisible to SAA. |
|
|
|
|
|
12/04/09, 7:31 PM
|
#236 |
|
Glass Joe
|
I am really sad right now, I've used SquawkAndAwe for a year now, and it's been great. I don't want it to go!!
Edit: For what it's worth, I discovered that the jerking lag I experienced every time I cast a spell was caused by having the "show GCD" box checked off. Everything was dandy after I unchecked it. Last edited by Hyperion : 12/04/09 at 7:57 PM. |
|
|
|
|
12/04/09, 10:19 PM
|
#237 |
|
Great Tiger
|
The second argument to UnitAura can be an index or a name (according to wowwiki).
It looks to me as if TellMeWhen registers all buffs for UNIT_AURA() (among other things), and then uses the name-based call to UnitAura() when that event occurs.  elseif ( iconType == "buff" ) then
...
icon:RegisterEvent("UNIT_AURA");
icon:SetScript("OnEvent", TellMeWhen_Icon_Buff_OnEvent);
...
function TellMeWhen_Icon_Buff_OnEvent(self, event, ...)
...
elseif ( event == "UNIT_AURA" ) and ( select(1, ...) == self.unit ) then
TellMeWhen_Icon_BuffCheck(self);
...
function TellMeWhen_Icon_BuffCheck(icon)
if ( UnitExists(icon.unit) ) then
-- local buffName, rank, iconTexture, count, debuffType, duration, expirationTime, isMine, isStealable;
local buffName, _, iconTexture, count, _, duration, expirationTime, caster = UnitAura(icon.unit, icon.name, nil, icon.buffOrDebuff);
|
|
|
|
|
12/04/09, 10:56 PM
|
#238 | |
|
Happy October 19th!
|
|
|
|
|
|
|
12/08/09, 2:26 PM
|
#239 |
|
Von Kaiser
|
3.3 Changes
To make SAA work in 3.3, you have to modify it as follows:
1. Search for SquawkAndAwe:OnEnable() 2. Add this code in the function: self:RegisterEvent("UNIT_AURA")
3. Add this function anywhere you want, outside other functions: function SquawkAndAwe:UNIT_AURA(event,id)
if id ~= "player" then
return
end
local spellName,_,_,_,_,_,expirationTimeEclipse,_,_,_,spellID = UnitBuff("player",SquawkAndAwe.combat.procs.Eclipse.name);
if expirationTimeEclipse and (expirationTimeEclipse-GetTime())>13 then
-- Proc handler
for k,v in pairs(SquawkAndAwe.combat.procs) do
if spellID == v.id then
SquawkAndAwe:ProcBars(k,v)
return
end -- if spellID == v.id
end -- for k,v in pairs(procs)
end
end
PS. There will be some perfomance hit, because it's going to check for Eclipse everytime you gain/lose a buff. Last edited by copialinex : 12/08/09 at 2:37 PM. Reason: Grammar, Error pointed by Adoriele |
|
|
