How To : Right click removing buff

[v6o]

Would hooking the header's OnEvent ensure that it's run after the default update so the vehicle updates do not happen to "early" ?

Edit: Should just had realized the problem lies in that the unit attribute is still player even when entering a vehicle and that's why it's not updating correctly. Just made it change unit on attribute whenever you enter or exit an vehicle.

When you change any attribute the header updates so there's not much else to do to it it seems

[v6o]

Anyone got experience with the sorting blizzard implemented? Is it working? More specifically is TIME working?

When I try it I get some weird orders...

[Mischback]

Originally Posted by v6o Anyone got experience with the sorting blizzard implemented? Is it working? More specifically is TIME working? When I try it I get some weird orders...

Same here, TIME doesn't seem to work...

[Dargen]

Originally Posted by v6o Should just had realized the problem lies in that the unit attribute is still player even when entering a vehicle and that's why it's not updating correctly. Just made it change unit on attribute whenever you enter or exit an vehicle. When you change any attribute the header updates so there's not much else to do to it it seems

One thing to remember is that you can't change the unit attribute if you are in combat when you get into or out of the vehicle.

[Dargen]

Originally Posted by Mischback Same here, TIME doesn't seem to work...

I believe sorting by time is working correctly. However, there is a bug that causes it to always separate the buffs you've cast from the buffs cast by other people, so it can look like the list is not properly sorted. It would be nice if there was a way to customize if buffs with no duration got sorted to the top or bottom.

[v6o]

Originally Posted by Dargen One thing to remember is that you can't change the unit attribute if you are in combat when you get into or out of the vehicle.

Doh. Completely forgot about the secure restrictions.... Is it possible to change the unit attribute with secure code or should I just make a double and show/hide with a secure on-state handler (or whatever they're called)


Edit: Tried to test this in combat but not sure if I left as I was dismounted, any way to shorten this?

local sechan = CreateFrame("Frame", nil, nil, "SecureHandlerStateTemplate")
sechan:SetAttribute("_onstate-aurastate", [[
local buffs = self:GetFrameRef("auraframe1")
local debuffs = self:GetFrameRef("auraframe2")
if newstate == "invehicle" then
    buffs:SetAttribute("unit", "vehicle")
    debuffs:SetAttribute("unit", "vehicle")
elseif newstate == "notinvehicle" then
    buffs:SetAttribute("unit", "player")
    debuffs:SetAttribute("unit", "player")
end
]])

sechan:SetFrameRef("auraframe1", buffs)
sechan:SetFrameRef("auraframe2", debuffs)
RegisterStateDriver(sechan, "aurastate", "[vehicleui] invehicle; notinvehicle")

[Taroven]

local sechan = CreateFrame("Frame", nil, nil, "SecureHandlerStateTemplate")
sechan:SetAttribute("_onstate-aurastate", [[
local buffs = self:GetFrameRef("auraframe1")
local debuffs = self:GetFrameRef("auraframe2")
local state = newstate == "invehicle" and "vehicle" or "player"
buffs:SetAttribute("unit",state)
debuffs:SetAttribute("unit",state)
]])

sechan:SetFrameRef("auraframe1", buffs)
sechan:SetFrameRef("auraframe2", debuffs)
RegisterStateDriver(sechan, "aurastate", "[vehicleui] invehicle; notinvehicle")

Not sure about the framerefs, but that at least gets rid of the if statement.

[aX0rZ]

I'm currently trying to implement SecureAuraHeaderTemplates in my UnitFrame-AddOn. So I'm using it for "unit"-Attribute-Values != "player". But I'm having some problems with it. Generally my code is based on nivBuffs which is based on the code sigg posted.

1. When i have no unit in target and then target any unit, buffs are correctly shown. But when I then target another unit, the buffs of the old unit are shown. I call the "UpdateStyle"-function when targets change but it seems SecureAuraHeaderTemplates do no adjust the buff-frames (child1, ...) when switching target.
2. Sometimes new buffs are not shown on my player frame. This is true for being inside combat aswell as for not.

Did anyone implement anything like this yet. Is it a flaw in my code or in Blizzards? Or do you need to see my code to judge that?

[zork]

You need that only for player buffs. You cannot cancel buffs on your target anyway so those can be just normal textures.

[aX0rZ]

Well I think it simplyfies the code, for example its super easy to sort the buffs (just :SetAttribute call). Also if blizzard changes something about their buff api or how events are handeld for buffs i just have to use SecureAuraHandler witch makes it easier to maintain my code.

[aX0rZ]

Originally Posted by aX0rZ 1. When i have no unit in target and then target any unit, buffs are correctly shown. But when I then target another unit, the buffs of the old unit are shown. I call the "UpdateStyle"-function when targets change but it seems SecureAuraHeaderTemplates do no adjust the buff-frames (child1, ...) when switching target.

Managed to resolve this issue. A simple "SecureAuraHeader_Update(header)" inserted at the beggining of "UpdateStyle" fixed that. But when now applying a new buff in combat I get an error, so it only works ooc.

[v6o]

You will need to force an update from an secure environment whenever your target changes. I do not know how to do this.

[aX0rZ]

Originally Posted by v6o As you change target nothing happens to the auras because the unit is still "target". You will need to force an update but you need to remember that you will have to do it from secure code.

Well how do i force an update? With SecureAuraHeader_Update()? That doesn't work infight, probably because my Event-Handler is not secure code. But how do you react to events in a secure environment? I also tried force an update with "header:SetAttribute("unit", header:GetAttribute("unit"))", because SecureAuraHeader_OnAttributeChange updates the header everytime an attribute is changed, which should be secure code since it's frome blizzard, but that didn't work.

[MoonWitch]

Ok, I've been constantly trying... I've tried with XML, without, with SecureAuraHeader, with SecureActionButton .. quite frankly - my "solution" worked fine for Seerah she told me, but somehow - it doesn't work for me >.<

I can only disable first most left and most right buff. So could someone be kind and help me understand a bit more?

Code is at https://github.com/moonwitch/Furbish/tree/experimental

[Seerah]

I actually didn't need any solution other than to stop doing something stupid that was tainting after 4.0. I just changed my method to a better, smarter way.

I don't sort or filter my buffs, I only skin them. That's why it worked.

[aX0rZ]

Originally Posted by MoonWitch Ok, I've been constantly trying... I've tried with XML, without, with SecureAuraHeader, with SecureActionButton .. quite frankly - my "solution" worked fine for Seerah she told me, but somehow - it doesn't work for me >.< I can only disable first most left and most right buff. So could someone be kind and help me understand a bit more? Code is at https://github.com/moonwitch/Furbish/tree/experimental

As far as I understand SecureAuraHeaderTemplate the following is wrong:

1. When you use :SetScript("OnEvent", ...) on "addon", you overite the SecureAuraHeader Event-Handler, so removing its functionallity. Rather use :HookScript().
2. You don't need to register "UNIT_AURA" on "addon", since Blizzard does that for you.
3. It's not "addon" that needs :EnableMouse() and :SetScript("OnEnter/OnLeave") you need to do this for every buff frame
4. (I'm not sure on this) It seems like you want to use the default Blizzard Buff Frames, I don't know if thats possible, rather create your own (You already have in your .xml but you don't use them).
5. You miss a bunch of :SetAttribute() calls. As far as i remember there are atleast 3 or so needed to display any buffs in any way. You can get all the attribute names at http://wow.go-hero.net/framexml/1311...oupHeaders.lua line 614.
6. Once your BuffCount and DebuffCount reach BUFF_MAX_DISPLAY/DEBUFF_MAX_DISPLAY you unregister UNIT_AURA resulting in that Buffs are no longer updated

If you have any problems I recommend taking a look into nivBuffs it's very clean code and it's working.

[MoonWitch]

I have taken a look at nivBuffs, still no win.

I took out :
- the positioning
- the ref to UNIT_AURA
- the enablemouse (and tooltip part in the xml)
- max display was taken out as well

As far attributes go : I don't quite see which ones I am missing that are needed. Unless all of them are needed, then Blizz created a monster

@Seerah : Show me?

EDIT : Apparently Show() is key :P

[Ailae]

There really is no need to use the new SecureAuraHeaderTemplate if you are just moving and/or skinning the buff-buttons. It's only useful if you want to filter or sort buffs, since that would taint the original Blizzard BuffFrame.

So you seem to be mixing apples with oranges right now. Here's my local copy of Furbish, that I hacked a bit to also add a border. Maybe it'll help. To get the buffs where you want you must move both the BuffFrame and the ConsolidatedBuffs since Blizzards anchors the second row to ConsolidatedBuffs.

http://pastebin.com/axuBEh9G

Looking at your mission statement on what's different in your version of Furbish, it would be how the times are formatted, which is easily changed at the top of the paste I linked.

[MoonWitch]

Well, the mission statement was slightly outdated :P

Basically here's what the my version did :
- Skin buffs, debuffs
- relocate
- add timers

And apparently those 3 made sure I got taint >.< So I set out to solve it. (I really do need that right click) Now that being said, I could only get it partially working. It seems to have a mind of its own.

Thank you, Ailae, you solved it for me, I thought I had gone through all the global blizzy stuff, but apparently I missed one.

BUFF_WARNING_TIME <- causes taint. So it works fine now, thanks!

[Talyrius]

Does anyone know if the problems with temporary weapon enchants in the SecureAuraHeader have been fixed on the PTR?