MouseIsOver has been converted to a C function for increased efficiency (e.g. /dump PlayerFrame:IsMouseOver() ).
When an addon file is loaded, the addon name and an addon table are passed to the file through . The same addon table is passed to every file loaded by a particular TOC file (example at the top of a Lua file: local addonName, addonTable = ;.
motionScriptsWhileDisabled attribute added to buttons. This allows OnEnter; and OnLeave; to fire while the button is disabled.
GetFileHeight() and GetFileWidth() added to Texture objects. 0 is returned if no texture file is associated with the texture.
You can now query for a list of completed quests with QueryQuestsCompleted() then wait for the QUEST_QUERY_COMPLETE event, and call GetQuestsCompleted(<luatable>).
That's one of the features that I've always wished that Blizz would add to the addon API, assuming it means what I think it means.
I'm a bit confused as to why you'd pass a table as an argument to GetQuestsCompleted(), unless it's to force the caller to manage the table that GetQuestsCompleted() populates.
You get a table of questIDs according to a post on mmo-champion. Here's the post:
For anyone who's interested, GetQuestsCompleted(table) sets table to a list of only quest IDs, no extra information provided, and includes flags such as http://db.mmo-champion.com/q/13807/.
From a premade character (All quests wiped) who only completed Preparations for War:
When an addon file is loaded, the addon name and an addon table are passed to the file through . The same addon table is passed to every file loaded by a particular TOC file (example at the top of a Lua file: local addonName, addonTable = ;.
maybe a new entry in the .toc file? you could specify the global name for your addon in your toc as a table, then that gets passed down to every lua file and those files could insert themselves into that table... maybe?
maybe a new entry in the .toc file? you could specify the global name for your addon in your toc as a table, then that gets passed down to every lua file and those files could insert themselves into that table... maybe?
My wild-ass guess is that it's an empty table for each addon, for easy sharing of addon-local variables. Now you don't have to do the equivalent of "local myaddon = aceaddon:getaddon('foo')" at the top of every file just to have access to "private" data.
I could be so wrong as to make this post embarassing in retrospect. I have zero data to base that guess on, other than that the "..." argument to files is often used for this kind of thing in non-WoW Lua apps.
Personally, the only /facepalm moment I had while reading today's PTR notes was for "any party member can set raid icons".
Hopefully it's strictly only in 5-man groups, and while in raid you still need to be promoted. I hope that's what they meant. If all 25 people can set icons, it's going to be a mess. (Think DBM-type addons that try to programmatically choose targets for icons....)
My wild-ass guess is that it's an empty table for each addon, for easy sharing of addon-local variables. Now you don't have to do the equivalent of "local myaddon = aceaddon:getaddon('foo')" at the top of every file just to have access to "private" data.
I could be so wrong as to make this post embarassing in retrospect. I have zero data to base that guess on, other than that the "..." argument to files is often used for this kind of thing in non-WoW Lua apps.
just went on the PTR and dumped the ... the first arg is the addonname and the second a empty table which seams to be shared between each file in the addon
not to sure why they put that in seams to just replace one table for another (though their table might be local to just the addon as such wouldn't muck up _G)
not to sure why they put that in seams to just replace one table for another (though their table might be local to just the addon as such wouldn't muck up _G)
That's exactly what I expect; one table per addon, but shared between files in that addon. Less crap in _G.
Yes, the addon table is not a global, it's essentially a private namespace for you to use without all the mucking about with globals to share the table across multiple files.
Source: http://forums.worldofwarcraft.com/thread.html?topicId=20126978820&sid=1
Some interesting changes in there.
Couldn't find a source other than MMO-Champion. The official thread was the last place I looked :)
There's other UI/Interface changes but what you've listed is possibly the only ones relecant to addon authors :)
M
G
That's one of the features that I've always wished that Blizz would add to the addon API, assuming it means what I think it means.
I'm a bit confused as to why you'd pass a table as an argument to GetQuestsCompleted(), unless it's to force the caller to manage the table that GetQuestsCompleted() populates.
Source: http://www.mmo-champion.com/news-2/patch-3-3-ptr-build-10571/msg1592939/#msg1592939
C'mon guys !
Go fondle with the new API changes. I mean while will be away doing my Shopping :)
Me not know how to program. Me only just mastered Sed ! (sort of)
There's been interesting macro changes to :
Is this a sign of more complicated macros to come needing space?
IE 8 characters down to 1 :)
Possibly some traffic savings due to only having to send one character as opposed to 8 characters. Especially with people spamming macros everywhere.
No, someone just likes twitter.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWhat is this "AddonTable" it speaks of?
maybe a new entry in the .toc file? you could specify the global name for your addon in your toc as a table, then that gets passed down to every lua file and those files could insert themselves into that table... maybe?
Basicly, by seeing this we could figure out what quests we have left to complete in various zones and things like that? Am i right? AM I?!
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumMy wild-ass guess is that it's an empty table for each addon, for easy sharing of addon-local variables. Now you don't have to do the equivalent of "local myaddon = aceaddon:getaddon('foo')" at the top of every file just to have access to "private" data.
I could be so wrong as to make this post embarassing in retrospect. I have zero data to base that guess on, other than that the "..." argument to files is often used for this kind of thing in non-WoW Lua apps.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumHopefully it's strictly only in 5-man groups, and while in raid you still need to be promoted. I hope that's what they meant. If all 25 people can set icons, it's going to be a mess. (Think DBM-type addons that try to programmatically choose targets for icons....)
just went on the PTR and dumped the ... the first arg is the addonname and the second a empty table which seams to be shared between each file in the addon
not to sure why they put that in seams to just replace one table for another (though their table might be local to just the addon as such wouldn't muck up _G)
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThat's exactly what I expect; one table per addon, but shared between files in that addon. Less crap in _G.
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumlocal addon, namespace = ... LibStub("AceAddon-3.0"):NewAddon(namespace, "New Addon 1") setfenv(0,namespace)prolly got the setfenv() call wrong, but you get the idea :)
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumSeems we're getting the multi-boss encounters unitframes
on the default client.