• 0

    posted a message on UNIT_AURA on aura refresh?
    On another note - if I want to add right click cancel buff functionality (something I was playing with back in 3.2 but never finished) is that completely nuked now with the Secure Header Aura template thingo?

    Specifically, my frames (buff buttons) will change between which aura they need to cancel depending on the buff type in that category.

    Concrete Example:
    * I have a single icon for the '5% stats' category
    * If I have BoK then it shows the BoK icon in that category and a right click should issue CancelUnitBuff("player", "Blessing of Kings")
    * If I have MotW then it shows the MotW icon in that category and a right click should issue CancelUnitBuff("player", "Mark of the Wild")
    * now these things might change mid fight (fight starts with MotW on raid, someone dies, is brezd, then pally throws out BoK)
    Posted in: Lua Code Discussion
  • 0

    posted a message on UNIT_AURA on aura refresh?
    The way my UI was built was that I wanted to have an 'at a glance' idea of what buffs I did and did not have. I also wanted to know if they were good or bad versions of a buff category (eg. BoM > BS), etc, etc. And I wanted it to fit into my UI style. Now, I never got it working brilliantly, but it did ok and I'm just fixing up the code to work with the new buff categories in 4.0.

    This is an old image grab I had of it when it used to work. Time is shown in my own preference - 'xxm' for '<=99minutes', 'xx' for '<=99secs', 'xh' for > 99 minutes. Buff stack is shown as text on the left hand edge (not displayed).



    So, at a glance I could see what buff categories I was missing during the fight. The buff addon also allowed filtering, sorting, etc for buffs outside those categories. (things like my Div Sac, and bubble wall got filtered to a different area for tracking - I have a custom 'tell me when' type thing for buffs I track)

    It was a bit of fun to learn how the addon system worked. But it was never really stable enough to release to the greater curse community.

    Edit:
    The reason I ran elkbuffbar at the same time was because invariably something would go boom during a raid - sigh. And elkbuffbar to the rescue - although I really did like the look of my system. (it's not visible but there are invisible buff frames making up the complete 18x2 grid - these were used for buffs outside the categories)
    (and the system was reasonably neat - if say you had mana totem instead of BoW it would change the 'major MP5' category from the BoW icon to the totem icon)
    (and yeh - the 99m for infinite buffs is a bug - was very much one of those projects that used to orbit around 'almost finished' without ever quite getting there)
    Posted in: Lua Code Discussion
  • 0

    posted a message on UNIT_AURA on aura refresh?
    yeh i've been thinking of biting the bullet and having a look at the combat log again. When I had a look at it a while back it seemed to be the too hard basket due to all the special cases - but need to have another glance.

    I confess I hadn't realised that table instantiation was -- that expensive -- that once per UNIT_AURA would be something to be concerned about (especially when filtered). But I can definitely see the benefit of throttling UNIT_AURA responses if they can fire more than a few times a second.
    (I was under the impression that UNIT_AURA already had some throttle code within the API - I thought I'd seen it fire when multiple changes have occurred)
    Posted in: Lua Code Discussion
  • 0

    posted a message on UNIT_AURA on aura refresh?
    just had a chance to write some code to confirm this for myself - yep I was definitely wrong :) This code is what I use to provide a simple event based system for event changes. I've tried to minimise any table creation and lookup costs by reusing tables where possible, local generation in smart places and flat number lookups rather than use strings. It also uses a reasonably efficient mechanism for O(n) passthrough.
    (yep, I could use the combat log but that looked more difficult than doing this as a while back some buffs didn't behave properly through the combat log)

    function AutoUI:UNIT_AURA(e, player)
    	if (player ~= "player") then
    		return
    	end
    	self:Print("UNIT_AURA player")
    --	format is {name, icon, count, duration, expires, source, id}
    	local name,  icon, cnt, dur, exp, src, id 
    	local buff, oldbuff
    	numNewBuffs = 0
    	tblNewBuffs = {} -- create an empty table for lookups (cheaper to erase than discard?)
    --	scan through all the buffs as reported from UnitAura (no other way to identify whats changed)
    --	copy across all the relevant info into aryNewBuffs and add lookups to tblNewBuffs
    	for i = 1, 40 do
    		name, _, icon, cnt, _, dur, exp, src, _, _, id  =  UnitAura("player", i, "HELPFUL")
    		if(name == nil) then break end
    		numNewBuffs = numNewBuffs + 1
    		buff = aryNewBuffs [numNewBuffs] 
    		buff[1] = name
    		buff[2] = icon
    		buff[3] = cnt
    		buff[4] = dur
    		buff[5] = exp
    		buff[6] = src
    		buff[7] = id
    		tblNewBuffs[id] = buff
    	end
    --	now we walk through the old buffs checking to see whether a buff has been removed
    	for i=1, numOldBuffs do
    		oldbuff = aryOldBuffs[i]
    		id = oldbuff[7] 
    --		self:Print("looking up id = " .. id)
    		buff = tblNewBuffs[ id ]
    		if (buff == nil) then
    			self:Print(string.format("DELBUFF: %s", aryOldBuffs[i][1] ))
    		end
    	end
    --	now we walk through the new buffs checking to see whether a buff has been added
    	for i=1, numNewBuffs do
    		buff = aryNewBuffs[i]
    		id = buff[7] 
    		oldbuff = tblOldBuffs[id]
    		if (oldbuff == nil) then
    			self:Print(string.format("NEWBUFF: %s", buff[1] ))
    		else
    			if (oldbuff[ 3] ~= buff[3]) then  --check change in count
    				self:Print(string.format("CNTBUFF: %s %d:%d", buff[1] , buff[3], oldbuff[3]))
    			elseif (oldbuff[ 5] ~= buff[5]) then  --check change in expiry
    				self:Print(string.format("EXPBUFF: %s %d:%d", buff[1] , buff[5], oldbuff[5]))
    			end
    		end
    	end
    --	now we swap the arrays and do some cleanup
    	local tmp = aryOldBuffs
    	aryOldBuffs = aryNewBuffs
    	numOldBuffs = numNewBuffs
    	tblOldBuffs = tblNewBuffs
    	aryNewBuffs = tmp -- this is an optimisation so we dont need to recreate tables
    end
    Posted in: Lua Code Discussion
  • 0

    posted a message on UNIT_AURA on aura refresh?
    no it's obviously my mistake - I can't believe I made such a clunker. This will radically simplify the code for my addon! Many thanks for the tip. I remember thinking it was such a dumb thing for it not too do. Please ignore my snafu :)
    Posted in: Lua Code Discussion
  • 0

    posted a message on UNIT_AURA on aura refresh?
    hmm.. then that must have changed. I wrote an addon about 6 months ago for my custom UI - I had to add a timer event to scan for charges and time refreshes because they weren't being triggered. (eg. divine plea and the pally vengeance stack)

    If they are now working then that's hell win!

    (I'm more than willing to concede it's always behaved this way and I've screwed up somehow, but I distinct remember writing some wowlua code to test this. Used to fire every UNIT_AURA, and for player, compare buffs since previous event. Then it would list out all the auras that had changed in some way - ie. increased time, more/less charges, etc. You've made me curious - gonna write the code again to check it out - thanks for the tip)
    Posted in: Lua Code Discussion
  • 0

    posted a message on UNIT_AURA on aura refresh?
    but from memory, it won't fire if an aura gains a charge or has its duration altered (refreshed, reduced, whatever).

    P.S. I have NFI why my username changed but I can't fix it in the user settings. If a mod wants to feel generous and PM how to fix it, I'd be much obliged.
    Posted in: Lua Code Discussion
  • To post a comment, please or register a new account.