This is a very specific, focused blog post to address one specific issue.
I, like many others, do not like the default WoW user interface.
I prefer, no, scratch that, I LOVE the X-Perl UnitFrames UI addon.
The changes it implements, on the surface, seem relatively minor, but there is a ton of power lurking under the hood. I like minimalist designs that provide me with tons of tools, designs that leave the majority of the screen real estate for me to actually see the game. If I wanted to see a ton of text describing the action, I’d play Zork.
With the introduction of Patch 4.0.1, there is an existing known bug with Raid UnitFrames addons in general.
The problem is that if you try and right-click onto buffs to dispel them in your addon, it will introduce what is called a “Taint”, and that causes bad things.
In X-Perl UnitFrames, the ability to right-click to dispell buffs has been temporarily disabled to prevent “Taints” from occuring.
If you use X-Perl, it also currently prevents you from right-clicking buffs displayed by the normal UI.
For just a second, I’m going to quote a description of Taints, just so you know I’m not talking ’bout “Taint one thing nor the other”, ’cause I know my audience.
From a discussion on WoWwiki;
When WoW starts executing lua code, the execution starts off ‘secure’, and able to run protected functions. Execution remains secure until it encounters ‘taint’ – which is an indicator that a function or object came from an untrusted (AddOn or /script) source. The basic idea is that execution becomes ‘tainted’ as soon as it reads tainted data or executes tainted code, and any data written by a tainted execution is itself tainted. Protected functions refuse to operate when called from an execution path that is not secure.
When the UI first loads, all code and data from Blizzard signed FrameXML and AddOns (plus their saved variables) is secure, and all code and data from user provided AddOns (plus their saved variables) is tainted.
Okay, so right now, if you love and want to run X-Perl UnitFrames but run into buffs you need to be able to click off, you have to either logout your character to disable your addon, use another addon that allows you to temporarily disable addons from within the game without logging out, (such as Addon Control Panel), or specifically cancel the buff by using a line item command such as “/cancelaura Buffname”.
Is this earth shattering? Of course not.
At least, not unless, oh, they did something like release a All Hallows Eve holiday event a week after the patch that includes Trick or Treating, and the tricks gave you buffs of costumes that last an hour… some of which prevent you from mounting. Or spellcasting. Buffs that… needs to be canceled. Right click style canceling.
Oh wait… Doh!
So, for you few peeps out there that love your X-Perl as much as I do, and want to keep using it, but are sick and tired of having to disable the addon in order to right click your Tricks to dispell them, here’s a solution that finally works.
First, make sure you have the very latest beta build of X-Perl. To do this, you have to visit the project page for X-Perl UnitFrames at WoWAce. They’re posting fresh builds constantly as they make corrections.
Second, with your current X-Perl UnitFrames Options open, go to the Player Tab. Within the Player Tab, look at the Player Buffs section and UNCHECK the “Hide Default Buffs” checkbox.
What this has done is display the default WoW UI buff panel, in addition to your X-Perl setup. Yes, a second set of buffs. For me, it’s worth it.
Now, this alone has not fixed the problem. There is one extra step you have to take.
Remember the description of a “Taint”, from above? It all comes from running code that isn’t “secure”. Code that is secure comes from Blizzard’s FrameXML data, then takes input from addons.
Well, as a purely short term fix, here is what you can do;
Go to the official Blizzard download site for the Interface Addon Kit, and download the appropriate version for your language. In my case, that’s US-English.
When you unzip that file, you copy the FrameXML folder, and you place it in your World of Warcraft game folder, at C:Program FilesWorld of WarcraftInterface (or whatever your destination folder may be, ending within the Interface folder).
This establishes the correct baseline FrameXML data for you to fall back on when right clicking those buffs on the default WoW UI buff bar.
Now, this is strictly a short term solution for JUST until there is a new patch.
The reason for this is, FrameXML is establishing a set of frame data specific to the game build it was created for. If a significant patch is released changing the frames (or actually fixing the core issue causing the bug in the first place), leaving this FrameXML in there will cause you lots of headaches.
BUT… for the pure short term, it will correct the problem.
Can you believe the bug has annoyed me so much I went to these lengths to find a solution?
Wanna know what really annoys me? I start writing this, go to various websites looking up links to copy to send you to the right reference locations, and what do I find? A poster named Twintails over at WoWAce posted this solution already, just hours before I started the post.
I hereby proclaim this entire idea as belonging to Twintails, and I thank them very, very much for their helpfulness to the community. Especially since I don’t really know anything about addons, and I was only guessing at things to try and make it work, and clearly they actually knew what they were doing and went to the Interface Addon Kit intentionally.
I just wish I’da seen that before I started writing.
UPDATE: This post was correct as of X-Perl UnitFrames beta build r448, and the patch status as of 10/20/10.