[Bug] SecureGroupHeaders.lua, configureAuras function

Interface and Macros
There is a bug in SecureGroupHeaders.lua file in PTR build 14911 (was probably present in earlier build as well) in the secure aura header section with the local function "configureAuras" and when we enable consolidated or weapons (enchants) into the header.

First of all, I'm sorry for the external link for details about it, but as a developer myself, I like to have detailed bug report with screenshots inside, etc. Something I'm not really able to do on the WoW forums.

The bug is detailed at this address, post #1:
http://www.tukui.org/forums/topic.php?id=17050

An "how to fix it" in include in the post #2

Thank you for reading! Hoping to see it fixed in the next PTR builds before 4.3 goes live else we (addons authors) will have some problem with our buffs addons.

Tukz

Thank you
I would like to bump this topic.

Nothing was done with this bug from the latest build. (14911 to 14942)

There is a bug with secure aura header in SecureGroupHeaders.lua. When the header use "consolidateTo" or "includeWeapons" attribute, some of the latest buffs buttons is not fading and hiding correctly after the timer is dead or is cancelled by the player if some weapons or consolidated buffs button is active.

A bad change was made in a 4.3 ptr build, moving this part of code (below) under weapons/consolidated codes in configureAuras function. It need to be above weapon/consolidated codes, like it was in 4.2.

Code in 4.2 (at line #711 of SecureGroupHeaders.lua over weapons/consolidated codes)
local deadIndex = #buttons + 1;
local button = self:GetAttribute("child"..deadIndex);
while ( button ) do
button:Hide();
deadIndex = deadIndex + 1;
button = self:GetAttribute("child"..deadIndex)
end


Current code in PTR 4.3 (moved at line #711 to #812 of SecureGroupHeaders.lua, under weapons/consolidated)
local deadIndex = display + 1;
local button = self:GetAttribute("child"..deadIndex);
while ( button ) do
button:Hide();
deadIndex = deadIndex + 1;
button = self:GetAttribute("child"..deadIndex)
end


You need to revert this change, or secure aura header won't be able to use "consolidateTo" or "includeWeapons" anymore.

2 screenshots of the bug itself, as seen & described in the first post, one just a couple of seconds before the bug happen and the second with the bug.

http://www.tukui.org/storage/viewer.php?id=307309WoWScrnShot_110111_160128.jpg
http://www.tukui.org/storage/viewer.php?id=478768WoWScrnShot_110111_160150.jpg

Please fix this issue. It's a simple bug to fix and we already gave the solution.

Thank you.
Bump, again... not fixed yesterday PTR build (4.3 build #14966). This bug exist since #14732 and nothing have been done in the latest 7 PTR builds.
Addon developers needs to work around Blizzards code changes not the other way round
Not Blizzards problem it's for addon developers to adjust to Blizzards code changes not the other way round
20/11/2011 10:57Posted by Nekoko
Not Blizzards problem it's for addon developers to adjust to Blizzards code changes not the other way round

... its def a blizzard mistake.

in the us forums there are tons of reports about blizzard code changes.
And that means on this occasion they should fix it?

They haven't done in before when they have made code revisions in patches, what makes you think they will start now?
*bump until it's fixed*

They haven't done in before when they have made code revisions in patches, what makes you think they will start now?


If enough people demand a change, Blizzard will react. It has always and will always be this way.

Blizzard does listen, but it takes like 10k people screaming into their ear till a thing like that gets fixed. Don't know why. They def. got the man power to attend to such matters in a flash.
Just for reference i'll link other posts on the same issue:


http://us.battle.net/wow/en/forum/topic/3424690010 (US)
http://us.battle.net/wow/en/forum/topic/3580989647 (US)
http://us.battle.net/wow/en/forum/topic/3580989649 (US)

Also, requested for sticky, this bug have been in the game since 4.2
It's not a bug it's a code change
Whatever you want to call it, its still a flaw in the code and needs to be fixed =)

Blizz? You there?
Does someone need to start a flame war in this thread to get some attention?
Really, any blue can at least say to us that they are passing this to whoever concerns? Please?
Hey there all,

This matter has been noticed just as an FYI. We're currently looking into getting a fix in for this in an upcoming patch. So hopefully it will be sorted out in the not-so-distant future. ^^
20/11/2011 10:57Posted by Nekoko
Not Blizzards problem

Nakatoir
Community
Hey there all,

This matter has been noticed just as an FYI. We're currently looking into getting a fix in for this in an upcoming patch. So hopefully it will be sorted out in the not-so-distant future. ^^


Nekoko, if it is not their problem, why are they going to fix it?

I allready lost all faith in Blizz when it comes to bug fixing.
They simply choose to release content faster without bug proofing it beforehand.
Thats the reason they ignore our simple troubleshooting, and use 7 or more ptr builds to respond to bugs.
It's pretty apparent they dont care what their subscribers say.
Having the Report a Bug option ingame is a joke, and could simply be removed.
Or atleast rename the function to:

Feeling lucky? Roll the dice and see if you can get a valid response for a bug report today!
(Free cookies and server transfers to all who win)

Rant over.

I read the whole post and im dissapointed overall..

And Nakatoir, im glad they have finally woke up.
Only took them like what? Little over a month.

Join the Conversation

Return to Forum