• 0

    posted a message on Idea for an addon: Reminders for button bars
    That's a good idea - I'd suggest putting it in the FlexBar2 Official thread, feature requests, as FlexScript would be ideally suited to this task.

    Fixed spelling:
    Quote from Zareh »

    ...
    buttons when THEIR cooldown is over
    ...
    Posted in: Addon Ideas
  • 0

    posted a message on SpecialEventsAuras - Fix To Fire Events On Rebuff
    Please review the final changes here:
    http://ace.pastey.net/70727-x6rd:70726-1xiv

    This took longer than expected, due to the complete lack of event fired when a buff on player is refreshed. Upon digging into BuffFrame.lua to see how it updates the duration text I saw (to my horror) that it updates this using the OnUpdate handler - which queries the buff time left for every buff around 20 times per second. I ended up going with a scheduled scan of player buffs every second, to pick up the refreshes a little more efficiently.
    Posted in: Libraries
  • 0

    posted a message on Parrot? Link?
    Aw man, what happened to CombatParrot?
    Posted in: General AddOns
  • 0

    posted a message on SpecialEventsAuras - Fix To Fire Events On Rebuff
    Quote from Jerry »

    Quote from Nemes »

    If you can think of a more elegant way to achieve the above, I'd be really grateful...


    Do not store timeleft, but time when the buff should end.

    local endTime = GetTime() + timeLeft


    Make sure GetTime() is called only once per invocation of AuraScan().

    That should be enough.



    Thanks Jerry. I'll make the changes tomorrow, and get you to review once more.
    Posted in: Libraries
  • 0

    posted a message on SpecialEventsAuras - Fix To Fire Events On Rebuff
    Quote from Jerry »

    Why do you feel it's needed to do the following ?
     if timeLeft then
      timeLeft = floor(timeLeft + 0.5)
     end


    When you receive a timeLeft value from GetPlayerBuffTimeLeft, depending on the timing, it will be a decimal value, close to the total duration of the buff.

    I'm rounding it, to simplify the comparison below. If I used the raw decimal values, a rebuff with 59.8 seconds remaining will not be classed as a rebuff if the timeLeft value from the old buff is 59.9 seconds.


    Quote from Jerry »

    Also, I do feel it would be better to set a buff as refreshed only when
    the timeLeft is strictly superior (and not superior or equal) to the precedent.


    I'm going with >=, because the AuraScan method will usually not be called between the time of the buff first being cast, to the time of it's refresh, so the timeLeft value will not be updated.

    If you can think of a more elegant way to achieve the above, I'd be really grateful...
    Posted in: Libraries
  • 0

    posted a message on SpecialEventsAuras - Fix To Fire Events On Rebuff
    Please review the attached file.
    Posted in: Libraries
  • 0

    posted a message on SimpleSelfRebuff - official topic
    Excellent Addon Adirelle! Loving it on my priest and my warrior and not had a single problem yet.

    We need an icon for it though...
    Posted in: General AddOns
  • 0

    posted a message on SpecialEventsAuras - Fix To Fire Events On Rebuff
    Quote from Jerry »

    More importantly, the change you propose would, strictly speaking, require a major number change, as you are changing the meaning of the "SE_NewBuff" events. Creating a new event would not require this.


    In that case, it will be a new event.
    Posted in: Libraries
  • 0

    posted a message on SpecialEventsAuras - Fix To Fire Events On Rebuff
    Quote from Jerry »

    Why do you feel it is needed to get such a notification ?


    For my specific case, I'm writing an addon to track buff time remaining for the raid. Without this change, SEAura will only send a notification the very first time a buff is cast on a player; when each buff is refreshed as happens often during a raid, no notification will ever be received.

    Quote from Jerry »

    Why not defining a new event "SE_BuffRefreshed" for these cases ?


    I didn't create a new event, as it is really a new buff, which cancels and overwrites the old buff.
    Posted in: Libraries
  • 0

    posted a message on SpecialEventsAuras - Fix To Fire Events On Rebuff
    I'd use pastey, but it's stripping indenting at the moment...

    relevant buff section:
    		--
    		-- Update buffs for unit
    		--
    
    		-- check for new buffs
    		for i = 1, maxbuffs do
    			local name, rank, icon, count, duration
    			
    			-- Honest, there is no guaranteed correlation between the
    			-- result of GetPlayerBuff and the index used by UnitBuff.
    			-- GetPlayerBuff sucks, but we need it for backwards
    			-- compatability.
    			if unit == "player" then
    				local pindex = GetPlayerBuff(i, "HELPFUL")
    				name, rank = GetPlayerBuffName(pindex)
    				icon = GetPlayerBuffTexture(pindex)
    				count = GetPlayerBuffApplications(pindex)
    				duration = floor(GetPlayerBuffTimeLeft(pindex) + .5)
    			else
    				name, rank, icon, count, duration = UnitBuff(unit, i)
    			end
    
    			if name then
    				-- buffs are the same if their name, rank, and icon are the same
    				local buffIndex = string.format("%s_%s_%s", name, rank, icon)
    
    				-- handle multiple instances of the same buff (stacked HoTs)
    				while seenBuffs[buffIndex] do
    					buffIndex = buffIndex .. "_"
    				end
    
    				-- this is the only buff field that is allowed to change without triggering an event
    				buffs.index[buffIndex] = i
    
    				-- new buff?
    				if not buffs.name[buffIndex] then
    					buffs.name[buffIndex] = name
    					buffs.rank[buffIndex] = rank
    					buffs.icon[buffIndex] = icon
    					buffs.count[buffIndex] = count
    					buffs.duration[buffIndex] = duration
    
    					seenBuffs[buffIndex] = "new"
    					
    				-- did the count change?
    				elseif buffs.count[buffIndex] ~= count then
    					buffs.count[buffIndex] = count
    
    					seenBuffs[buffIndex] = "changed"
    					
    				-- was the buff refreshed?
    				elseif buffs.duration[buffIndex] and duration and buffs.duration[buffIndex] <= duration then
    					buffs.duration[buffIndex] = duration
    
    					seenBuffs[buffIndex] = "new"
    
    				-- no changes
    				else
    					seenBuffs[buffIndex] = true
    				end
    
    			end
    
    		end


    relevant debuff section:
    		--
    		-- Update debuffs for unit
    		--
    
    		-- check for new debuffs
    		for i = 1, maxdebuffs do
    			local name, rank, icon, count, dispelType, duration
    
    			if unit == "player" then
    				local pindex = GetPlayerBuff(i, "HARMFUL")
    				name, rank = GetPlayerBuffName(pindex)
    				icon = GetPlayerBuffTexture(pindex)
    				count = GetPlayerBuffApplications(pindex)
    				duration = floor(GetPlayerBuffTimeLeft(pindex) + .5)
    				dispelType = GetPlayerBuffDispelType(pindex)
    			else
    				name, rank, icon, count, dispelType, duration = UnitDebuff(unit, i)
    			end
    
    			if name then
    				-- debuffs are the same if their name, rank, and icon are the same
    				local debuffIndex = string.format("%s_%s_%s", name, rank, icon)
    
    				-- handle multiple instances of the same debuff
    				while seenDebuffs[debuffIndex] do
    					debuffIndex = debuffIndex .. "_"
    				end
    
    				-- these are the only debuff fields that are allowed to change without triggering an event
    				debuffs.index[debuffIndex] = i
    				debuffs.dispelType[debuffIndex] = dispelType or ""
    
    				-- new debuff?
    				if not debuffs.name[debuffIndex] then
    					debuffs.name[debuffIndex] = name
    					debuffs.rank[debuffIndex] = rank
    					debuffs.icon[debuffIndex] = icon
    					debuffs.count[debuffIndex] = count
    					debuffs.duration[debuffIndex] = duration
    
    					seenDebuffs[debuffIndex] = "new"
    
    				-- did the count change?
    				elseif debuffs.count[debuffIndex] ~= count then
    					debuffs.count[debuffIndex] = count
    
    					seenDebuffs[debuffIndex] = "changed"
    
    				-- was the debuff refreshed?
    				elseif debuffs.duration[debuffIndex] and duration and debuffs.duration[debuffIndex] <= duration then
    					debuffs.duration[debuffIndex] = duration
    
    					seenDebuffs[debuffIndex] = "new"
    
    				-- no changes
    				else
    					seenDebuffs[debuffIndex] = true
    				end
    			end
    		end
    Posted in: Libraries
  • 0

    posted a message on SpecialEventsAuras - Fix To Fire Events On Rebuff
    I've noticed that CTRA sends a message when a buff is re-applied, however oRA2 doesn't do this. I dug into SpecialEventsAuras and saw that it only fires on new auras i.e. ones that weren't previously present.

    Following is a change that will detect rebuffs and send them out as a new aura:

    SpecialEvents-Aura-2.0.lua patch:
    Index: SpecialEvents-Aura-2.0.lua
    ===================================================================
    --- SpecialEvents-Aura-2.0.lua	(revision 43271)
    +++ SpecialEvents-Aura-2.0.lua	(working copy)
    @@ -258,7 +258,8 @@
     				local pindex = GetPlayerBuff(i, "HELPFUL")
     				name, rank = GetPlayerBuffName(pindex)
     				icon = GetPlayerBuffTexture(pindex)
    -				count = GetPlayerBuffApplications(pindex)	
    +				count = GetPlayerBuffApplications(pindex)
    +				duration = floor(GetPlayerBuffTimeLeft(pindex) + .5)
     			else
     				name, rank, icon, count, duration = UnitBuff(unit, i)
     			end
    @@ -284,17 +285,24 @@
     					buffs.duration[buffIndex] = duration
     
     					seenBuffs[buffIndex] = "new"
    -
    +					
     				-- did the count change?
     				elseif buffs.count[buffIndex] ~= count then
     					buffs.count[buffIndex] = count
     
     					seenBuffs[buffIndex] = "changed"
    +					
    +				-- was the buff refreshed?
    +				elseif buffs.duration[buffIndex] and duration and buffs.duration[buffIndex] <= duration then
    +					buffs.duration[buffIndex] = duration
     
    +					seenBuffs[buffIndex] = "new"
    +
     				-- no changes
     				else
     					seenBuffs[buffIndex] = true
     				end
    +
     			end
     
     		end
    @@ -332,6 +340,7 @@
     				name, rank = GetPlayerBuffName(pindex)
     				icon = GetPlayerBuffTexture(pindex)
     				count = GetPlayerBuffApplications(pindex)
    +				duration = floor(GetPlayerBuffTimeLeft(pindex) + .5)
     				dispelType = GetPlayerBuffDispelType(pindex)
     			else
     				name, rank, icon, count, dispelType, duration = UnitDebuff(unit, i)
    @@ -366,6 +375,12 @@
     
     					seenDebuffs[debuffIndex] = "changed"
     
    +				-- was the debuff refreshed?
    +				elseif debuffs.duration[debuffIndex] and duration and debuffs.duration[debuffIndex] <= duration then
    +					debuffs.duration[debuffIndex] = duration
    +
    +					seenDebuffs[debuffIndex] = "new"
    +
     				-- no changes
     				else
     					seenDebuffs[debuffIndex] = true
    Posted in: Libraries
  • 0

    posted a message on Skinner
    Quote from Jncl »

    Hi X-buZZ & Nemes,

    I've tried both the versions of Bagnon that Skinner caters for and they both skin properly for me.

    The versions I have checked are: http://wowui.incgamers.com/ui.php?id=4060 & http://wow-en.curse-gaming.com/files/details/2090/vbagnon/ (http://wowui.incgamers.com/ui.php?id=3197 is the same version)

    What version do you use?


    I've finally figured this one out!

    I'm using the Bagnon version above, however it's actually an addon loading order issue. I was able to replicate the issue using only the following, with externals:
    Bagnon
    Bagnon_Forever
    Bagnon_Options
    FuBar - PerformanceFu
    FuBar 2.0
    Lib: Ace2
    Skinner

    The problem would not happen the first time the game is loaded with those addons and would not happen on a reload. It would occur perhaps 75% of the time on subsequent world entries from the loading screen.

    Bagnon is not LOD, however the LOD version of Bagnon was being "detected", via self:checkAndRunAddOn("Bagnon", true).

    The easy fix is to comment out lines 95, 320, 321, 322 in AddonFrames.lua - only detect non-LOD versions of Bagnon and vBagnon.

    If you want me to commit the change please let me know.
    Posted in: General AddOns
  • 0

    posted a message on Skinner
    Quote from X-buZZ »

    Hi Jncl,

    with the latest release, Bagnon isnt skilled any more.

    Best regards
    X-buZZ


    Skinner r42898:

    Error skinning Bagnon Interface\AddOns\Skinner\Skinner.lua:104: attempt to call method 'SetBackdrop' (a nil value)
    Posted in: General AddOns
  • 0

    posted a message on NShakedown - Organise Your UI - Official Thread
    Quote from And »


    Great! I would to explain my previous request about MA/oRA more in detail. I have a hard time figuring where my MainAssist and oRA Main Tanks frames will be, there is no way to have them as test on screen (at least I didn't figure how to do it). I use Align while in raid but it's not easy and often I have to arrange my windows while out of raid. Having both MA and oRA MT frames showing up in NShakedown would really help me. Yet I don't know if this is possible :)
    Thanks in advance!

    And :)


    No problems. It's just a matter of time for me to build and test it all...

    New support for the following will be added:
    • ag_UF (if practical)
    • oRA MT/PT
    • MainAssist
    • Mendwatch
    • Proximo
    • InFlight

    Movement support will be added for:
    • SCT
    • MSBT
    • DBM Warnings

    After that, I will make a decision on Alignment / Grid support and implement that.
    Posted in: General AddOns
  • 0

    posted a message on NShakedown - Organise Your UI - Official Thread
    Fixed the problem with Quartz - smarter LOD / loadmanaged addon detection.

    Added:
    Bongos2
    Chronometer
    PitBull
    Posted in: General AddOns
  • To post a comment, please or register a new account.