How To : Right click removing buff
 

Hello

I know that the new SecuredAuraheader is quite complicated to use, this is a helper to show you how RDX handle that.

Create a file AuraButtonTemplate.xml :
The secureAuraengine need a xml template to create buttons on the fly :

Important tags description :
Size This will define the height and width of your buff, example: <Size x="30" y="30"/>
Attribute : indicate the button is a cancelaura type.
<Attributes>
<Attribute name="type" value="cancelaura"/>
</Attributes>


Create the SecureAuraHeader handler :

create a new handler to update the style of each button

I hope this will help you in your addons.

Cheers
Sigg

Nice post ! I need that :)

Great, but you could even pray for people like me who have not much idea of it, explain in what folder is it?:confused::confused:

this is a sample code for developer LUA.

:eek:

I'm trying to set up your example code as a standalone addon right now. I had to change some of these CreateTexture/CreateFontString calls. Also the events fire and call the updateStyle function. However I don't see any buffs ingame. Am I missing something?

Which one of these lines would do that red thing? :confused:

Also I did a quick search for any documentation on the SecureAuraHeaderTemplate, like.. eh.. usage maybe. ^^ Came up with basically nothing, I can't even find it in the Blizz UI Source Code..

**edit: After your example and explanation it really doesn't sound so complicated anymore, thank you for that! If only I could see my buffs. :D

Woot, thanks :)

http://github.com/tekkub/wow-ui-sour...oupHeaders.xml
http://github.com/tekkub/wow-ui-sour...oupHeaders.lua

Thanks for the code, gonna play around with it a bit. But why does the update have to happen "on next frame"?

Hello

About the style function, you have to call it in the next frame call, because the engine auraheader also use the event "UNIT_AURA" to update itself.

What I saw, was the style function is called before the auraheader update.

Goes to right :
headerAura:SetAttribute("xOffset", 30);
headerAura:SetAttribute("yOffset", 0);

Goes to left :
headerAura:SetAttribute("xOffset", -30);
headerAura:SetAttribute("yOffset", 0);

Goes to down :
headerAura:SetAttribute("xOffset", 0);
headerAura:SetAttribute("yOffset", -30);

Goes to up:
headerAura:SetAttribute("xOffset", 0);
headerAura:SetAttribute("yOffset", 30);

You should be able to move your mouse on the button and see the gametooltip.

the SecureAuraHeaderTemplate is located in the SecureGroupHeaders.lua

Thanks to both of you (Ailae and sigg)!

The reason why I didn't see anything was because I forgot to call :SetPoint on the header.. *cough* It's working now.

Now let's talk about the weapon enchant.

The system is still buggy and Blizzard has not finished it.
- Rightclick on the weapon enchant is not working (bug blizzard SecureTemplates.lua:395: attempt to call global 'CancelItemTempEnchant' (a nil value)).
- The gametooltip of the second enchant always show the main hand. (file SecureGroupHeaders.lua, line 777, local slot = GetInventorySlotInfo("MainHandSlot");, replace MainHandSlot by SecondaryHandSlot)
- The third weapon enchant button is not implemented yet in the new securedauraheader

Add this in the header :

In the style function :

:p

These are the issues that I've encountered so far with the current implementation of the SecureAuraHeader:

SecureTemplates.lua:
- You cannot cancel a weapon enchantment since the CancelTempEnchantment() function is spelled incorrectly.

SecureGroupHeaders.lua:
- Does not update the buttons if using a unit like "target" and the target changes, etc.
- The "consolidateDuration" attribute mentioned in comments never gets used.
- The "sortDir" attribute mentioned in the comments is spelled as "sortDirection" in the actual code.
- The comments for the xOffset attribute say the default is width, however the code sets the default to 0.
- The comments for the yOffset attribute say the default is height, however the code sets the default to 0.
- sortFactory(): If the "separateOwn" attribute is 0 it will be handled as if it were -1.
- configureAuras(): Setting the "wrapAfter" attribute to nil or 0 results in a divide by nil or 0 error.
- configureAuras(): Cannot use a string template name for the "consolidateProxy" attribute or "consolidateHeader" attribute because the code tests the return value of type() for an uppercase 'STRING'.
- configureAuras(): Assigns the slot number for the MainHandSlot to the off hand enchant button's "target-slot" attribute and :SetID(). You can work around this by comparing the child frame's value to header:GetAttribute("tempEnchant2") and supplying your own inventory slot number.
- extractTemplateInfo(): Does not properly separate a template name from a widget type when both are specified in a template name string.
- SecureAuraHeader_OnUpdate(): Does not track consolidated buffs in order to move them out of consolidation when time remaining is short.
- SecureAuraHeader_Update(): Setting the "includeWeapons" attribute to 0 will cause weapon buttons to be displayed if they have previously been created.
- SecureAuraHeader_Update(): The logic that decides which buffs to add to the consoliation frame is adding buffs with short rather than long time remaining values.
- SecureAuraHeader_Update(): Due to a bug in the loop that parses the "groupBy" attribute, only the last filter in a comma separated list will be used.

Blizzard updates the aura header anytime it is shown, it receives a UNIT_AURA event, or an attribute is assigned to it.

When setting a number of attributes in the header you can minimize the number of times Blizzard updates the header by setting the "_ignore" attribute first (or you can hide the header since the OnAttributeChanged script also ignores attribute updates when the header is not visible).

As long as the "_ignore" attribute is set, Blizzard will not update the header. When you're finished changing attributes, restore the original "_ignore" attribute value. To force a header update you can then set any other attribute.

I just uploaded a first version of a very lightweight buff frame replacement using SecureAuraHeaders:

http://www.wowinterface.com/download...-nivBuffs.html

Rightclicking buffs off works like a charm (except for weapon enchants, as already said). If something doesn't work, feel free to flame me.

(No seriously, don't. :p )

This is a great guide to help me understand what I need to learn ... BIG THANK YOU!!

For my addon ProcWatch I have one bar that shows certain buffs on more than one unit (player, target, focus). From reading your guide I guess this will no longer work when I want cancleaura to work. Am I right ?

Someone make sure Elkano sees this, ElkBB! :banana:

You don't need those calls to Show() and Hide() for buttons in the updateStyle() function. The headers do that on their own and the calls cause taint errors in combat.

Btw. how would I make it work with the consolidation feature, when Blizzards code to create the consolidation button from a template is broken?

I'm playing with cancelaura ... why on earth do I have to set "unit" ?
Are there other units than player where I can cancel an aura ? ;)

You can cancel vehicle buffs, and possibly pet

ups, never thought of that or tried it :) thanks for the tip :D

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

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...

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.

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.

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?

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

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?

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

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.

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.

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

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.

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

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.

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.

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

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.

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!

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