SquawkAndAwe - Page 10

Talsh · 11/19/09, 7:39 PM

Also having PTR issues here - I imagine it might have something to do with there being a new spell ID for eclipse, because for me, all bars are operating normally except for the eclipse bar.

JEL · 11/20/09, 1:41 PM

same issue @ me....
It seems to be because eclipse-procs dont appear @ combatlog @ ptr... dont know why

maybe someone can fix it - i cant

• Adoriele · 11/20/09, 2:07 PM

Originally Posted by JEL

same issue @ me....
It seems to be because eclipse-procs dont appear @ combatlog @ ptr... dont know why

maybe someone can fix it - i cant

If someone runs a log at a dummy where they know Eclipse procced, I can look through it to see if something changed. It'd be rather odd for it to not show up at all (and technically it would probably still throw a SPELL_AURA_APPLIED event, just now be listed in the log), though I also can't imagine what their idea would be for changing the spellIDs (actually, I can think of an idea, but people who use WiseEclipse won't be happy about it).

Hyperion · 11/21/09, 4:35 PM

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

mader · 11/21/09, 5:37 PM

Originally Posted by Adoriele

If someone runs a log at a dummy where they know Eclipse procced, I can look through it to see if something changed. It'd be rather odd for it to not show up at all (and technically it would probably still throw a SPELL_AURA_APPLIED event, just now be listed in the log), though I also can't imagine what their idea would be for changing the spellIDs (actually, I can think of an idea, but people who use WiseEclipse won't be happy about it).

Just did a test run on ptr and the combat log is not registering any events for eclipse. The eclipse buff and WiseEclipse appear to be functioning just fine. Can send you a log if you wish.

• Adoriele · 11/21/09, 8:09 PM

Originally Posted by mader

Just did a test run on ptr and the combat log is not registering any events for eclipse. The eclipse buff and WiseEclipse appear to be functioning just fine. Can send you a log if you wish.

Please do. I can probably pick out where Eclipse procced by looking at what spells you're casting, entry or no.

mader · 11/23/09, 9:45 PM

Sent you log in pm if you haven't checked. New patch is out though, ill try to get some logs but initial test eclipse still doesn't show up. Also wiseeclipse no longer works since they nerfed it (cant proc eclipse within 15s of previous proc).

WoWCombatLog - Google Docs

Posted new log but yea dont see anything diff. Hopefully it is just an oversight.

• Adoriele · 11/23/09, 10:00 PM

Originally Posted by mader

Sent you log in pm if you haven't checked. New patch is out though, ill try to get some logs but initial test eclipse still doesn't show up. Also wiseeclipse no longer works since they nerfed it (cant proc eclipse within 15s of previous proc).

I got the log and yeah, it's pretty much what I expected. Obviously they were gunning for WiseEclipse with the change, but unless they find a way to get Eclipse back in the Combat Log with the new tech that they're using, SAA is pretty much dead in the water as well. There are ways to get the same functionality out of it, but they require both a substantial rewrite requiring testing (which is hard to do when you have no account), and would likely involve a performance hit as well (take that as you will, this is a major killer for some people, especially if they're already having performance issues with SAA).

• Arawethion · 12/04/09, 5:25 PM

What log entries are missing now? This seems weird. You don't get UNIT_AURA or whatever even used to fire when Eclipse appears on you? Why would that change and what does it have to do with the WiseEclipse fix?

• Adoriele · 12/04/09, 6:13 PM

Originally Posted by Arawethion

What log entries are missing now? This seems weird. You don't get UNIT_AURA or whatever even used to fire when Eclipse appears on you? Why would that change and what does it have to do with the WiseEclipse fix?

There are three ways of determining buff status that I'm aware of:

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.

Hyperion · 12/04/09, 7:31 PM

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.

Erdluf · 12/04/09, 10:19 PM

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);

I currently use TellMeWhen for at least a couple of buffs (Eclipse, Clearcasting) as well as several cooldowns. I haven't run (have never installed) any profiling tools to determine if TellMeWhen is a performance hog.

• Adoriele · 12/04/09, 10:56 PM

Originally Posted by Erdluf

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.

Yeah, he's doing something similar to what I'd do given the change. It's still a complete rewrite of the buff detection engine, though. The specifics are pretty nifty, I'd have never thought to have the internal buff info structure register to check for itself. First glance makes me think that it'd be a little more performance heavy, as every buff has to check whether it's the one that got applied with UNIT_AURA.

copialinex · 12/08/09, 2:26 PM

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")

(i.e. at line 326)

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

(I added it at line 353)

PS. There will be some perfomance hit, because it's going to check for Eclipse everytime you gain/lose a buff.

• Adoriele · 12/08/09, 2:30 PM

Cop and I have been talking in PMs, this is a valid fix. I should note that the second parcel of code can't actually be placed anywhere you like, it needs to be outside of any other functions, but otherwise his instructions are perfectly valid. If you are having performance issues, please let me know how this fix affects you. If it's not a significant performance hit, I will add the code into the published addon on Curse and WoWI.

[edit] I should also note that, in the case that Eclipse does not spawn a UNIT_AURA event (which I'm not sure if it does, and don't know any way of testing), your Eclipse cooldown bar may be sliiightly off. We're talking on the order of however long it takes for you to have another aura change, which is likely milliseconds at most.

Knoway · 12/08/09, 2:38 PM

Added cop's fix to my SAA code, after the servers come up and I've had a chance to test it I'll report back with performance changes/any other relevant info.

copialinex · 12/08/09, 3:33 PM

Originally Posted by Adoriele

I should also note that, in the case that Eclipse does not spawn a UNIT_AURA event (which I'm not sure if it does, and don't know any way of testing), your Eclipse cooldown bar may be sliiightly off. We're talking on the order of however long it takes for you to have another aura change, which is likely milliseconds at most.

Tested, It does fire UNIT_AURA (Tested in PTR with a premade char without other procs (talents, items) than eclipse)

• Arawethion · 12/08/09, 4:10 PM

I'm not expecting a large performance hit. Everyone's probably already running multiple mods that hook UNIT_AURA (buff mods, unit frames, etc.).

• Adoriele · 12/08/09, 4:13 PM

Originally Posted by Arawethion

I'm not expecting a large performance hit. Everyone's probably already running multiple mods that hook UNIT_AURA (buff mods, unit frames, etc.).

No, neither am I, but I'd prefer confirmation before I make it official.

♦ Lord BEEF · 12/08/09, 9:05 PM

Caused a serious performance hit for me in testing whenever I put a hot on myself. It would hiccup.

Akutsito · 12/09/09, 2:18 AM

No noticeable performance hit here either.

Knoway · 12/09/09, 2:22 AM

No noticeable performance hit vs target dummies. Didn't get a chance to test it in a raid setting, if anything is different there I'll update this post.

Eilt · 12/09/09, 9:02 AM

I did not notice a performance change, I even applied hots to myself and had other druids do it as well (in a raid). However, I was capturing a lot of errors with squawk and awe, unfortunately I did not have time to look into it. I will get more info on that tonight though.

shibbytastic · 12/09/09, 9:56 AM

I had good luck with the fix that you posted, but was unable to test it in a raid environment because our raid and instance servers went down the instant i finished fixing my interface. Against a target dummy it was using about 1Mb of memory, which is more than it was using before, but less than a lot of other timer mods.

If you plan on editing your lua file be sure you have the most updated version of Squawk And Awe. If you do not have the most updated version you will get a large number of error messages.

Thanks for getting a fix out there so fast guys. I really didn't want to have to find and adjust a new moonkin timer when i enjoy using this one so much.

aldones · 12/09/09, 10:02 AM

Only tested on stray mobs and the test dummy, but worked flawlessly for me, without any performance hits.
Going to test on a raiding environment tonight.