Battle For Azeroth Addon Changes

UI and Macro
1 2 3 5 Next
World of Warcraft: Battle for Azeroth
8.0 Release Notes for Wow Addon Developers

With the release of Battle for Azeroth Beta, the WoW User Interface team would like to highlight some upcoming changes that will affect addon developers. Many of these changes are already in place on the Beta realms, while some others will not be in place until the BFA pre-patch.

If you aren’t an addon developer, this list will probably not be of much interest to you:

Combat Log Event Changes
The COMBAT_LOG_EVENT & COMBAT_LOG_EVENT_UNFILTERED events no longer have any event payload. In order to get the information passed down previously with these events, please use the CombatLogGetCurrentEventInfo function.

Spell System API Changes
Due to a change we made on the backend, Spell System API & Events have several major changes. Please read the following if you are using Spell API or Events in your addons.

Spell text fields — such as its name’s subtext or description — are now loaded on demand, except for the spell’s name. This affects the following functions:
Function Name -- Return value affected
GetActiveArtifactByRace -- #5 (spell description)
GetArtifactInfoByRace -- #5 (spell description)
GetRecipeDescription -- #1(spell description)
GetSelectedArtifactInfo -- #5 (spell description)
GetSpellBookItemName -- #2 (spell name subtext)
GetSpellDescription -- #1 (spell description)
GetTrainerServiceAbilityReq -- #1(spell name subtext)
GetTrainerServiceDescription -- #1 (spell description)

If you call these functions, the listed return value may be nil or empty, since the data is not available at the time of the function call. We offer an interface in Lua —SpellMixin — that delays a call until the data is available. This interface lets you call functions from the previous list without the risk of returning empty data.

local spell = Spell:CreateFromSpellID(spellID);
spell:ContinueOnSpellLoad(function()
spellButton:SetText(GetSpellDescription(spell:GetSpellID());
end);

The SetText call is immediate if the spell text is loaded and available. If not, it delays the call until the data loads.

If you need to cancel a request at any point, use this interface:

local spell = Spell:CreateFromSpellID(spellID);
local spellDataLoadedCancelFunc = spell:ContinueWithCancelOnSpellLoad(function()
button:SetText(GetSpellDescription(spell:GetSpellID());
end);

When you're ready to cancel the request, call the cancellation function:

if spellDataLoadedCancelFunc then
spellDataLoadedCancelFunc();
spellDataLoadedCancelFunc = nil; -- for safety!
end

In addition to the ContinueOnSpellLoad functions, SpellMixin offers the following member functions to query various spell text fields:
GetSpellID() The Spell ID associated with this SpellMixin.
GetSpellName() The spell’s name.
GetSpellSubtext() The spell’s name subtext (often the spell rank).
GetSpellDescription() The spell’s description.

You should call these functions from your captured function body, as in the previous examples. The following is the first example, simplified using these functions.

local spell = Spell:CreateFromSpellID(spellID);
spell:ContinueOnSpellLoad(function()
spellButton:SetText(spell:GetSpellDescription());
end);

Function changes:
• GetSpellInfo - second parameter used to return Spell.nameSubtext -- now returns nil.
• GetTrainerServiceInfo - dropped second parameter (nameSubtext).
• GetShapeshiftFormInfo - dropped second parameter (name).
• GetMacroSpell - dropped first two parameters (name, and nameSubtext).
• GetPetActionInfo - dropped second parameter (nameSubtext).
• GetPossessInfo - second parameter changed from spell name to spell ID.
• CancelUnitBuff - no longer supports canceling by spell name.
• UnitBuff - dropped second parameter (nameSubtext). Also, no longer supports querying by spell name.
• UnitDebuff - dropped second parameter (nameSubtext). Also, no longer supports querying by spell name.
• UnitAura - dropped second parameter (nameSubtext). Also, no longer supports querying by spell name.
• UnitCastingInfo - dropped second parameter (nameSubtext).
• UnitChannelInfo - dropped second parameter (nameSubtext).
• GameTooltip:GetSpell - dropped second parameter (nameSubtext).
• GetAuraInfo - no longer supports querying by spell name.
• GetItemSpell - dropped second parameter (nameSubtext).
• GetSpellLink - no longer returns trade skill link as second parameter (see GetSpellTradeSkillLink below).

Functions removed:
• FindSpellOverrideNameByName
• FindBaseSpellNameByName
• SearchGuildRecipes

Functions added:
• CancelPetPossess
• FindSpellOverrideByID
• FindBaseSpellByID
• DoesSpellExist
• GetSpellTradeSkillLink
• GetSpellSubtext

Event changes:
• UNIT_SPELLCAST_SUCCEEDED - no longer provide spell name and rank.
• UNIT_SPELLCAST_FAILED_QUIET - no longer provide spell name and rank.
• UNIT_SPELLCAST_INTERRUPTED - no longer provide spell name and rank.
• UNIT_SPELLCAST_START - no longer provide spell name and rank.
• UNIT_SPELLCAST_FAILED - no longer provide spell name and rank.
• UNIT_SPELLCAST_STOP - no longer provide spell name and rank.
• UNIT_SPELLCAST_DELAYED - no longer provide spell name and rank.
• UNIT_SPELLCAST_CHANNEL_START - no longer provide spell name and rank.
• UNIT_SPELLCAST_CHANNEL_UPDATE - no longer provide spell name and rank.
• UNIT_SPELLCAST_CHANNEL_STOP - no longer provide spell name and rank.

World Map Changes
The World Map has been almost entirely re-written, and all map API was removed. It’s being replaced but we are currently still transitioning. worldMapAreaID, dungeonMapID, dungeonFloor have all been removed and replaced with just uiMapID. We have included a mapping between the old and new data in AddOns/Blizzard_Deprecated/UIMapIDToWorldMapAreaID.lua to help you translate your data.

Event Documentation
In addition to function and table API documentation, all events and their payload are now documented. The documentation can be accessed in-game by using the /api command. You can find the raw documentation files in /AddOns/Blizzard_APIDocumentation. They are exported through the existing ‘ExportInterfaceFiles code’ command.

UI Widgets are replacing the World State Frame (and much more to come)
UI Widgets are a new system that we have put in place to handle a wide variety of UI tasks going forward. As a result, WorldStateFrame is no longer needed and will be going away entirely. World State events will still be sent down as before, so don’t worry if you were relying on those. There are new events and UI Widget system API functions … see UIWidgetManagerDocumentation.lua in the documentation folder. For further information, see the lua & xml files in the \AddOns\Blizzard_UIWidgets folder.

Voice Chat
The new Voice Chat system is now live! Documentation for the Voice Chat API is in the normal documentation folder as listed above.

VoiceActivityManager is a Lua-side system that lets you register for the creation of notification frames when a member in voice chat starts talking. You can use the RegisterFrameForVoiceActivityNotifications and UnregisterFrameForVoiceActivityNotifications methods for this purpose.

Pool Collections
PoolCollections are a new Lua-side system that allows you to register multiple pools for creating frames using different templates and/or frame types and not have to keep a Pool around for each one. It works in much the same way that Pools do, you just need to make sure that you call CreatePool before you attempt to create an object of a particular type. Here is an example of how you might use PoolCollections:

-- First create the PoolCollection and call CreatePool for every template type you will be creating
self.myPools = CreatePoolCollection();
self.myPools:CreatePool("FRAME", parent, "FrameTemplateA");
self.myPools:CreatePool("FRAME", parent, " FrameTemplateB");
self.myPools:CreatePool("BUTTON", parent, "ButtonTemplateA");
self.myPools:CreatePool("BUTTON ", parent, " ButtonTemplateB");

-- Then creating any of those templates is as easy as calling Acquire on the PoolCollection
local frame1 = self.myPools:Acquire("FrameTemplateA");
local frame2 = self.myPools:Acquire("FrameTemplateB");
local frame3 = self.myPools:Acquire("FrameTemplateB");
local button1 = self.myPools:Acquire("ButtonTemplateB");
local button2 = self.myPools:Acquire("ButtonTemplateA");

-- And when you are done with the frames, you can release them one by one or use ReleaseAll
self.myPools:Release(frame3);
self.myPools:ReleaseAll();

Changes to Texture object API
• The SetRotation(radians) function now rotates the textures vertices instead of modifying the texture cords
• Added a GetRotation function
• Setting the rotation will no longer destroy texture coords set by SetTexCoord
• Unlike the old API, rotations will persist across anchor changes
• Textures created in XML can be initialized rotated with the “rotation” attribute, specified in degrees

Other changes to Frame API
• Texture, FontString and Line can now be scaled directly using the newly added SetScale, GetScale and GetEffectiveScale functions
• The Model XML attribute “scale” is now called “modelScale”

Miscellaneous Changes
• Attempting to register or unregister for an unknown event will now generate a Lua error
• We made several improvements to the performance of anchor-processing
• Anchor processing is also less likely to fail to resolve a valid rect
• xpcall now accepts arguments like pcall does
• The alert system was overhauled, allowing for there to be multiple independent alert/toast areas in the UI. We also added a new intrinsic type called ContainedAlertFrame to be used for alerts.
• Context menus can now have a custom frame imbedded into them.
• GetItemInfo now respects player’s link level for sell price
I'm very grateful for you assembling all this information and making this transition as smooth as possible.
can someone whose more fluent in addon speak clarify which addons (if any) are affected or may be broken by this?
04/24/2018 01:35 PMPosted by Lightwrath
can someone whose more fluent in addon speak clarify which addons (if any) are affected or may be broken by this?


I understood enough of that to know they appear to be saying "We changed everything. All your sh** is going to break."
04/24/2018 01:46 PMPosted by Coille
04/24/2018 01:35 PMPosted by Lightwrath
can someone whose more fluent in addon speak clarify which addons (if any) are affected or may be broken by this?


I understood enough of that to know they appear to be saying "We changed everything. All your sh** is going to break."


i figured that much
i moreo meant will it be repairable? or will it be broken? IE what they did that made Grand Conjuction much harder on Star Augur
04/24/2018 01:46 PMPosted by Coille
I understood enough of that to know they appear to be saying "We changed everything. All your sh** is going to break."


Not all, but the changes are significant and many addons will be effected with some that are no long being maintained, no longer usable (unless you update you own copy).

Some addons that are being updated will take (in some cases much) longer to fix than others and some authors may not release BfA compaitble addons until after the launch of the pre-patch (assuming there will be one, I havn't looked) or actual BfA launch.
04/24/2018 01:46 PMPosted by Coille
04/24/2018 01:35 PMPosted by Lightwrath
can someone whose more fluent in addon speak clarify which addons (if any) are affected or may be broken by this?


I understood enough of that to know they appear to be saying "We changed everything. All your sh** is going to break."

^
Like any major expansion patch really.

04/24/2018 01:55 PMPosted by Lightwrath
i figured that much
i moreo meant will it be repairable? or will it be broken? IE what they did that made Grand Conjuction much harder on Star Augur


Most of these changes aren't to break addons. They aren't removing anything like in cases with position in 7.1 and nameplates in 7.2. It's mostly refactoring geared toward performance improvements with a new async spell system. Likely to help with lag during spell heavy fights.
04/24/2018 01:55 PMPosted by Lightwrath
04/24/2018 01:46 PMPosted by Coille
...

I understood enough of that to know they appear to be saying "We changed everything. All your sh** is going to break."


i figured that much
i moreo meant will it be repairable? or will it be broken? IE what they did that made Grand Conjuction much harder on Star Augur


The combat log event changes will effect a lot of addons. If you're using an addon that does something based on anything in combat, then your addon will be effected. I expect practically everything having to do with this change will be repairable. And repairable by anyone with moderate addon writing/tweaking abilities. I'm not guaranteeing, I haven't seen how the new function works. But I would guess they're adding a step that effectively makes things less messy.

World map stuff looks like it will be the most different changes.
Three thoughts on "breaking" addons with this:

1) Much of what was done here can be undone with a conversion module - localizing (to the addon) functions that have been moved into the C_... structures for instance. Someone will likely come out with something like that similar to what happened with the soundkit changes. It won't be quite as efficient as properly changing the code (because in some cases a data pivot is also required and some processing might be needed to find the right data), but it will work.

2) Although this is going to cause certain AddOn development teams a LOT of work (WeakAuras comes to mind), the new and stronger focus on spellID versus spell Name as the identifer for spells should mean improved run-times for queries dealing with those.

3) Assuming the promised documentation is not vaporware then . . . "In addition to function and table API documentation, all events and their payload are now documented" should more than make up for any changes that have to be made to existing, event-driven addons.

I think the pain is most going to be felt, outside of the AddOn development community, by the WeakAuras user community if the development team for WeakAuras doesn't focus their adaptations on making legacy triggers work correctly.

That's not necessarily a bad thing either.

There's a lot going on in WeakAuras that has been "cutting four inches of the end of the roast" and really needs to be rethought from the point of view of "What do we want this to do" rather than "How can we change this and not break anything."

Sometimes, you gotta shake the bad juju out of your code to make it better.

This is definitely gonna do that.
Can someone clarify if this is the way we're supposed to do /cancelaura macros now?

/script local ind =0; for i=1,40 do if UnitAura("player", i)=="Divine Shield" then ind = i end end; CancelUnitBuff("player", ind);
/cast Divine Shield
04/24/2018 03:15 PMPosted by Ehiztari
Although this is going to cause certain AddOn development teams a LOT of work (WeakAuras comes to mind), the new and stronger focus on spellID versus spell Name as the identifer for spells should mean improved run-times for queries dealing with those

It really won't. we'll just do this, because most of the time when we look up by spell name we really mean spell name.
function DBM:UnitDebuff(uId, spellName)
if wowTOC == 80000 then
for i = 1, 40 do
local bfaspellName = UnitDebuff(uId, i)
if not bfaspellName then return end
if spellName == bfaspellName then
return UnitDebuff(uId, i)
end
end
else
return UnitDebuff(uId, spellName)
end
end

Spell Id matching is good for certain things but other things there might be like 8 different debuff Ids for a single spell, we don't want to check 8 diff spell ids we just want to check one name. Besides, you can't just do UnitDebuff(unitId, spellid) either. we still need to itterate over all auras now since api no longer does it automatically, thus the wrapper above I wrote for DBM at least to basically replicate old behavior.
04/24/2018 06:19 PMPosted by Omegal
04/24/2018 03:15 PMPosted by Ehiztari
Although this is going to cause certain AddOn development teams a LOT of work (WeakAuras comes to mind), the new and stronger focus on spellID versus spell Name as the identifer for spells should mean improved run-times for queries dealing with those

It really won't. we'll just do this, because most of the time when we look up by spell name we really mean spell name.
function DBM:UnitDebuff(uId, spellName)
if wowTOC == 80000 then
for i = 1, 40 do
local bfaspellName = UnitDebuff(uId, i)
if not bfaspellName then return end
if spellName == bfaspellName then
return UnitDebuff(uId, i)
end
end
else
return UnitDebuff(uId, spellName)
end
end

Spell Id matching is good for certain things but other things there might be like 8 different debuff Ids for a single spell, we don't want to check 8 diff spell ids we just want to check one name. Besides, you can't just do UnitDebuff(unitId, spellid) either. we still need to itterate over all auras now since api no longer does it automatically, thus the wrapper above I wrote for DBM at least to basically replicate old behavior.
I had a short discussion on the WA board t'other day about this.

As far as I'm concerned, they should just pull all (potentially) 40 auras for the player each time there's an aura event - I mean, most of what you're going to need is there - then they could table it locally and index it by anything they want (they could make it alphabetical by sock color if that suits them).

The point is, that since getting aura data is going to require iterating through the universe of auras anyway, and that addon is so entangled with aura processing, why not just DO it - assume that anyone looking at auras is at least going to want auras about themselves - and build it into the addon.

My own addon - a . . . not exactly competitor - a replacment for part of the functionality of WeakAura already does that - every 20th of a second (maximum - no point in faster), I pull the whole aural list and store it in a table tied to character data (and pet if any) and it's from that table that any reference to auras is pulled.

I'm seeing that I'll need some changes, but I already have my addon highly compartmentalized - modules for item processing, ability processing, talent processing, pvptalent processing, macro parsing, lots more - all information about those little slices of data are handled through query functions I have built in there - all I need to mess with is the bit where I go get the data from Blizzard and since all that's in one place, it shouldn't be hard to update.
Ehiztari:
"cutting four inches of the end of the roast" .
I don't know how many people understand that but cudos for the succinct reference to method-inertia.
Any ETA on the new worldmap API?
04/25/2018 12:01 AMPosted by Bitanga
Ehiztari:
"cutting four inches of the end of the roast" .
I don't know how many people understand that but cudos for the succinct reference to method-inertia.
You may be the first person I've ever used that phrase with who recognized it without an explanation.

I did, just a few days ago, retell the story in a thread here - my assumption was that folks who follow this board would have read it - but yeah - one of the things I fight in systems I work on is that.

I'm more an "extract the desired functionality and shared interface parameters and then rewrite it" sort of guy.

It's not always applicable - but on any complex system that has not had that approach taken to it in a few years, it usually is.

It's expensive in time and effort, but it almost always results in a far better (by any measure you want to consider - efficiency, future maintainability, flexibility, others).

I worked in IT for more than 30 years, most of the time as a high end consultant ($450 an hour was my going rate with a 40 hour minimum per week and a 12 week minimum per assignment).

Once I'd made my bones with a client (either on that assignment or an earlier one), they generally accepted my approach - it never failed them. It's a little shocking to traditional IT project managers because it is so far outside the norm, but it works.

I generally took no more than one or two other people with me on a project and these were people like me - willing and able to dig into a project, stay on it two or two-and-a-half shifts a day until it was done - it takes a sort of hunger, possibly describable as an obsession, to be able to do that happily.

I think the last project I worked on (2008 - I eventually ended up with unrelated health issues that forced me out of the job market) was the billing system for a big insurance company. Myself and one other guy took 18 months to completely rewrite it - more than 12 million lines of code.

That company recently (like last year) finally dumped it in favor of a non-mainframe solution (something I warned them about and am closely monitoring through friends in the company - it's going to be nearly impossible to meet some of the regulatory reporting requirements with a widely distributed system like that).

During the intervening ten years, there wasn't one ticket opened on the the code we wrote for an error.

Sure, there were regulatory changes that had to be implemented and the company opened up new lines of business that had to be accounted for in the billing system, but the code I wrote that David helped me analyze, in ten years, not one error popped up.

Modern IT management doesn't like "A" work. They want "C" work. They seem to think that doing things "just good enough" is more cost effective than doing it right and they may be right.

One of the reasons I never accepted any of the offers to be a manager in an IT department was that I can't stand "C" work.

The only time I broke that rule, I accepted a position as Senior Vice-President for Technical Development for a tech company for a bit - right up until I confronted the CIO of the company with making fraudulent claims about the capability of the software development tools we sold.

This little guy was a former Marine and seemed to think he could bully me around because of that.

I'm former military myself and I daresay I've killed more people up-close-and-personal than he has. I'm 6'4" tall and at the time I was a solid wall of muscle.

I don't bully well, but I can be taken down by someone who knows what he's doing.

He did it in about four seconds. Don't ask me how. He did it right in the middle of a board meeting. No kidding.

I still remember him screaming at me, standing over my nearly-unconscious body, "You are not the reason I'm going to jail!"

Needless to say, I got a really nice severance package out of that and I swore off ever taking a management position again.

Oh, and the company (no names)?

Within a month of my having left (and, thank g-d, after I cashed the severance check), their $50 a share stock was trading for pennies. Someone (not me, I swear), leaked the story to the financial press. My guess is that it was the poor clod they "promoted-from-within" who they asked to sign the papers I refused to sign about the capabilities of the product.
Is Blizzard going to be giving out beta invites to addon authors via sites like WoWInterface.com and Curse like in the past? I really need to get on so I can get my addons up and working.

Edit: Admin on WoWInterface posted that they are talking with Blizzard about getting keys for authors.
Ehiztari:
Modern IT management doesn't like "A" work. They want "C" work. They seem to think that doing things "just good enough" is more cost effective than doing it right and they may be right.
You'll probably recognize this question: Why is there never enough time to do it right but always enough time to do it over?

I fought the "A" vs "C" work mentality constantly; it was soul-crushing -- more than a few meetings I would have preferred being knocked unconscious. It still grates on me when I see it in products I use.

04/25/2018 07:31 AMPosted by Urnn
Is Blizzard going to be giving out beta invites to addon authors via sites like WoWInterface.com and Curse like in the past? I really need to get on so I can get my addons up and working.
I'd be astonished if they didn't but they usually do that after beta's been officially cooking for a while.
So previously you were able to use GetWorldStateUIInfo() to grab score data in BGs and stuff.. can someone point me to the equivalent now?
Any chance us addon authors can get priority beta invites? I have lots of users telling me that my addon is broken, but I can't get in to fix any of it.

https://www.curseforge.com/wow/addons/neuron
Authors on WoWInterface generally get beta invites. They're walking w/ Blizzard about it now but they aren't collecting names yet.

Join the Conversation

Return to Forum