6.2.4 Lua API Changes

UI and Macro
In the upcoming Patch 6.2.4, we're moving to a new Battle.net infrastructure. There are changes to many of the Battle.net-related Lua APIs, including Battle.net friends and Battle.net chat. If you maintain an AddOn that makes use of those features, you may want to log in to the PTR and test that your AddOn still functions correctly. To help AddOn authors troubleshoot potential compatibility issues, we’ve highlighted a few of the big changes to help direct you to areas that may need your attention.

Conversations
Support for conversations has been removed. This includes all C-functions (BNCreateConversation, BNGetConversationInfo, etc.) as well as all Lua/XML references to conversations.

Toons
The new Battle.net architecture doesn’t have the concept of “Toons”. Instead, we refer to “GameAccounts”. As a result, many functions with “Toon” in the name now refer to “GameAccount”
Examples:
BNGetToonInfo -> BNGetGameAccountInfo
BNGetFriendToonInfo -> BNGetFriendGameAccountInfo
BNGetNumFriendToons -> BNGetNumFriendGameAccounts

Presence IDs
Previously, “Presence IDs” could refer to either Battle.net accounts or individual toons. Most functions were able to accept either type of presence ID and, when passed the wrong type, tried to guess at what you were trying to do.

Presence IDs have been replaced with bnetIDAccount and bnetIDGameAccount. With this change, we’ve made all functions strict about whether they accept Account IDs or Game Account IDs. In order to make this easier, all Lua variables have been updated to specify which type of ID they are.

You can translate from a bnetIDGameAccount to a bnetIDAccount as follows:
bnetIDAccount = select(17, BNGetGameAccountInfo(bnetIDGameAccount));
You can find a player’s active bnetIDGameAccount from a bnetIDAccount as follows:
bnetIDGameAccount = select(6, BNGetFriendInfoByID(bnetIDAccount));
Current Realm Name
The “realmName” CVar no longer exists. You can get the name of the current realm using GetRealmName().
03/02/2016 12:13 PMPosted by Rygarius
Presence IDs have been replaced with bnetIDAccount and bnetIDGameAccount. With this change, we’ve made all functions strict about whether they accept Account IDs or Game Account IDs.

Do places that previously provided toon presence IDs now guarantee providing a game account ID? I'm specifically thinking of things like the arguments provided to the BN_CHAT_MSG_ADDON event handlers, as it's very useful to tie such in-game sent data to a specific game account source.

03/02/2016 12:13 PMPosted by Rygarius
The new Battle.net architecture doesn’t have the concept of “Toons”. Instead, we refer to “GameAccounts”.

Does this include events? Are BN_TOON_NAME_UPDATED, BN_FRIEND_TOON_ONLINE, BN_FRIEND_TOON_OFFLINE all renamed to BN_GAME_ACCOUNT_NAME_UPDATED, BN_FRIEND_GAME_ACCOUNT_ONLINE, BN_FRIEND_GAME_ACCOUNT_OFFLINE respectively?

I'll be making some tests later on the PTR to see whether the TOON events still register for frames properly, but it'd be nice to have it confirmed one way or the other.

03/02/2016 12:13 PMPosted by Rygarius
The “realmName” CVar no longer exists. You can get the name of the current realm using CurrentRealmName().

Do you mean GetRealmName(), the already-existing function? Or is this a new function that can (or must?) replace GetRealmName()?
Thank you for posting this.

Any other posts about API changes/additions would be a tremendous help to the addon community. Even just a technical overview of new systems like the coming nameplate overhaul or new drawing methods.

If it can become a bullet point for discussion with the UI team: do you guys think it's possible for Blizzard to help document the API even further? As we progress into further and further expansions, the community effort to document additions and changes lessens. wowpedia's "exhaustive list" API is still from 5.4 and doesn't include C_ToyBox, C_MountJournal and such. wowprogramming has them mentioned but with sparse documentation. This is of course the community's fault but a little boost may help re-invigorate the documenting efforts.

Alternately, do you think the UI & Macro forum could get a replacement for Slouken? He was a huge help in answering technical questions and explaining things. A new UI & Macro forum blue may bring back the experienced addon authors who have drifted off to other forums or no longer post.
Another change i noticed, any function that returned btag now only returns string and strips # and numbers. This is actually somewhat problematic for the way I store conversation history in WoW instant Messenger. On live I can store Adam#1234 and Adam#4321 separately but in 6.2.4 Both will simply be "Adam" and wim won't know one from other and the history for both wlll be combined. :\

I can't imagine what reason you strip the number from battletag in these functions but can that be changed?

BNGetFriendInfo (BNGetFriendInfoByID in 6.2.4)

Or any other function that returns btag

Bor, it's kind of silly on addon end now to separate game and toon info. You basically have to do additional calls now.

For example in WIM I had to do this

Live
local pid = BNet_GetPresenceID(from)
if pid then
local _, _, btag, _, toonName = _G.BNGetFriendInfoByID(pid)
from = btag or toonName or from
end


Legion/6.2.4
local pid = BNet_GetPresenceID(from)
if pid then
local gameId = _G.BNet_GetBNetIDGameAccount(from)
local _, _, btag, _, toonName = _G.BNGetFriendInfoByID(gameId)
from = btag or toonName or from
end


Another thing, BNGetToonInfo always requires gameid, not presenceID (which it currently accepts on live), which means you often find yourself having to request both pid and gameid. You basically have to play it by ear until you're used to what needs pid and what needs gameid. compared to live which lets pretty much everything use pid.
03/02/2016 02:11 PMPosted by Bor
The “realmName” CVar no longer exists. You can get the name of the current realm using CurrentRealmName().

Do you mean GetRealmName(), the already-existing function? Or is this a new function that can (or must?) replace GetRealmName()?

The "realmName" CVar is no longer there, but the function to get the name of the current realm is still GetRealmName. Correction made to the post, thanks for asking.
Are we going to get the long awaited appear offline mode in this new Battle.net infrastructure
-Nevermind! reading comprehension, it's a thing.-
I'll be making some tests later on the PTR to see whether the TOON events still register for frames properly, but it'd be nice to have it confirmed one way or the other.

I've now checked, and so far the BN TOON events have not been renamed. The TOON events still register, and replacing TOON with GAME_ACCOUNT (or GAMEACCOUNT) does not register.

Rygarius, is this going to stay this way to live (and beyond), or are we going to have to also change events for a future build?
When do we get appear offline for

Starcraft
Diablo
Overwatch
HoTs
Hearthstone
What's going on with BNGetFriendInfo()? The third return value used to give a BattleTag for the player, now if I dump BNGetFriendInfo() I get something like this...

Dump: value=BNGetFriendInfo(1);
[1]=6,
[2]="|Kf4|k00000|k",
[3]="|Kf4|k00000|k", <== Battletag used to be here.
etc
etc

Is this intentional?
Has anyone succesfully sent a BNSendGameData on the PTR? I've not had any success.
local accountID = BNet_GetBNetIDAccount("Name")
local gameID = select(6,BNGetFriendInfoByID(accountID))

BNSendGameData(gameID,"Prefix","test")

Where "Name" is the battletag (minus the "#number") and "Prefix" is the prefix registered on both clients.
Using accountID it's throwing a usage error to use the "game account presence id".
Using gameID throws no error but there's no event firing on the recipient side.

The traditional SendAddonMessage is working fine.
03/03/2016 07:07 AMPosted by Gello
Has anyone succesfully sent a BNSendGameData on the PTR? I've not had any success.

I haven't tested it (I don't have anyone on my Btag on PTR), but have you checked which game account ID you're getting from BNGetFriendInfoByID()?

At least on live, there's a separate toon ID for the Battle.net desktop client -- I'm not sure if the same is true on PTR or not. Checking the output of BNGetGameAccountInfo() might help; if the third return value is "WoW", then it's definitely getting the proper game account ID. If it's "App" (or pretty much anything else), then it's not and you might have to iterate through BNGetFriendGameAccountInfo() to find the correct one.
Do places that previously provided toon presence IDs now guarantee providing a game account ID? I'm specifically thinking of things like the arguments provided to the BN_CHAT_MSG_ADDON event handlers, as it's very useful to tie such in-game sent data to a specific game account source.

Yes, BN_CHAT_MSG_ADDON is now guaranteed to give a bnetIDGameAccount. All other chat events will provide a bnetIDAccount.

Does this include events? Are BN_TOON_NAME_UPDATED, BN_FRIEND_TOON_ONLINE, BN_FRIEND_TOON_OFFLINE all renamed to BN_GAME_ACCOUNT_NAME_UPDATED, BN_FRIEND_GAME_ACCOUNT_ONLINE, BN_FRIEND_GAME_ACCOUNT_OFFLINE respectively?

These events are no longer used. BN_FRIEND_INFO_CHANGED will fire for changes to both account and game-account data.

03/02/2016 02:34 PMPosted by Omegal
Another change i noticed, any function that returned btag now only returns string and strips # and numbers.

Thanks for the heads-up! This should be fixed in a coming build to work the same way that it does on live.
What do I need to change in this code?

function GWL:CHAT_MSG_BN_WHISPER(Event, Message, Sender, p4, p5, p6, p7, p8, p9, p10, LineID, p12, p13, PresenceID)
local Command, Args = strsplit(' ', strlower(Message), 3)

if Command ~= WaitListWhisperCommand then
return
end

local ToonID, Client = select(6, BNGetFriendInfoByID(PresenceID))

if Client ~= 'WoW' then
BNSendWhisper(PresenceID, ModName .. 'Must be in WoW to send command')
else
local _, ToonName, Client, RealmName = BNGetToonInfo(ToonID)

if RealmName ~= GetRealmName() then
BNSendWhisper(PresenceID, ModName .. 'Must be on same realm as the queue leader')
else
local Msg = DoCommand(Args, ToonName)

if Msg then
BNSendWhisper(PresenceID, ModName .. Msg)
end
end
end
end
03/03/2016 01:30 PMPosted by Galvin
What do I need to change in this code?

Something like this:
function function GWL:CHAT_MSG_BN_WHISPER(event,...)

local message = select(1,...)

local Command, Args = strsplit(' ', strlower(message), 3)

if Command ~= WaitListWhisperCommand then
return
end

local bnetIDAccount = select(13,...)
local bnetIDGameAccount = select(6,BNGetFriendInfoByID(bnetIDAccount))
local _,toonName, client, realmName = BNGetGameAccountInfo(bnetIDGameAccount)

if client ~= 'WoW' then
BNSendWhisper(bnetIDAccount, ModName .. 'Must be in WoW to send command')
else
if realmName ~= GetRealmName() then
BNSendWhisper(bnetIDAccount, ModName .. 'Must be on same realm as the queue leader')
else
local Msg = DoCommand(Args, toonName)
if Msg then
BNSendWhisper(bnetIDAccount, ModName .. Msg)
end
end
end
end


However, BNGetGameAccountInfo is "Anasterian(US)" and the GetRealmName is "Anasterian (US)" so they'll always be unequal. I don't know if this is PTR specific or not. Could be.
03/03/2016 11:51 AMPosted by Bor
I haven't tested it (I don't have anyone on my Btag on PTR), but have you checked which game account ID you're getting from BNGetFriendInfoByID()?

Here's some dumps from one separate account that's entirely separate (different email/login, absolutely no ties to the other account other than they are bnet friends) with one bnet friend logged in (my main account):
Dump: value=BNGetNumFriends()
[1]=1,
[2]=1
Dump: value=BNGetFriendInfo(1)
[1]=2,
[2]="|Kf1|k00000|k",
[3]="|Kf1|k00000|k",
[4]=true,
[5]="Raor",
[6]=3,
[7]="WoW",
[8]=true,
[9]=1457039746,
[10]=false,
[11]=false,
[12]="",
[13]="",
[14]=true,
[15]=0,
[16]=false,
[17]=false,
[18]=false,
Dump: value=BNGetGameAccountInfo(3)
[1]=true,
[2]="Raor",
[3]="WoW",
[4]="Anasterian(US)",
[5]=3296,
[6]="Alliance",
[7]="Worgen",
[8]="Druid",
[9]="",
[10]="Moonglade",
[11]="90",
[12]="",
[13]="",
[14]=0,
[15]=true,
[16]=3,
[17]=2,
[18]=true,
[19]=false
Dump: value=BNGetFriendInfoByID(2)
[1]=2,
[2]="|Kf1|k00000|k",
[3]="|Kf1|k00000|k",
[4]=true,
[5]="Raor",
[6]=3,
[7]="WoW",
[8]=true,
[9]=1457039746,
[10]=false,
[11]=false,
[12]="",
[13]="",
[14]=true,
[15]=0,
[16]=false,
[17]=false,
[18]=false


This does not appear to trigger anything on the receiving end (Roar from the above data):
BNSendGameData(3,"Rematch","test")

I have an /eventtrace running to watch for any event in case something other than BN_CHAT_MSG_ADDON is now firing. Nothing.

Any value other than 3 for the first parameter gets a usage error (which is nice that it's checking!):
Message: [string "..."]:13: Usage: BNSendGameData(id,prefix,text) id must be a game account presence id.


This works flawlessly:
SendAddonMessage("Rematch","test","WHISPER","Raor")

Both characters are on the same realm (Anasterian(US)) and same faction (Alliance). The sender is a level 1 in Gnomeregan, the recipient is a level 90 in Moonglade. The level 1 is a full account (trial accounts don't have full bnet access).

edit: created a level 100 template character as a sender and same behavior: nothing for BNSendGameData to the bnetIDGameAccount and an error trying to send to bnetIDAccount.

TL;DR: It seems BNSendGameData is not working. I'm more and more convinced that it's bugged. But maybe I'm missing something. If anyone's addon depends on BNSendGameData they may want to log onto the PTR and try too.
03/03/2016 02:44 PMPosted by Gello
It seems BNSendGameData is not working. I'm more and more convinced that it's bugged. But maybe I'm missing something.

As far as I can see, you're using it right and it's definitely getting the WoW game account ID. Since the SendAddonMessage() works, I'm assuming you did RegisterAddonMessagePrefix("Rematch"), which is the only other thing I can think of there.

From what I can see, it should be working. Best guess is that, yeah, there's some sort of bug going on there. Rygarius, is this a known issue? Or are there other changes that we need to account for with BNSendGameData()?
03/03/2016 03:37 PMPosted by Bor
03/03/2016 02:44 PMPosted by Gello
It seems BNSendGameData is not working. I'm more and more convinced that it's bugged. But maybe I'm missing something.

As far as I can see, you're using it right and it's definitely getting the WoW game account ID. Since the SendAddonMessage() works, I'm assuming you did RegisterAddonMessagePrefix("Rematch"), which is the only other thing I can think of there.

From what I can see, it should be working. Best guess is that, yeah, there's some sort of bug going on there. Rygarius, is this a known issue? Or are there other changes that we need to account for with BNSendGameData()?

We're aware of an issue with BNSendGameData() not working correctly in the current build. The issue has been tracked down and should be fixed in an upcoming PTR build.
03/03/2016 05:29 PMPosted by Rygarius
We're aware of an issue with BNSendGameData() not working correctly in the current build. The issue has been tracked down and should be fixed in an upcoming PTR build.

Excellent, thanks for keeping us up to date on these things!
03/02/2016 12:13 PMPosted by Rygarius
Conversations
Support for conversations has been removed. This includes all C-functions (BNCreateConversation, BNGetConversationInfo, etc.) as well as all Lua/XML references to conversations.


Can this be elaborated on? Is this just taking away the ability for third party sources to access the API but the client retaining the ability for b.net conversations to be created by other unexposed functionality? Or is the ability to create conversations being completely removed from the client. If so this seems counterproductive and could cause some outbursts from the RP community.

Join the Conversation

Return to Forum