Thanks Talyrius :)

Lua string comparisons are O(1); in fact, inside the scripting engine, they are a simple pointer comparison, as equal string values are guaranteed to be at the same place in the string pool.

That said, I agree they're likely doing something special with unit IDs, and wouldn't expect this function to work on random strings (although my armchair guess is that, given the way string "interning" works, it wouldn't be Too Difficult to make it work...).

[Bug] SecureAuraHeader

UnitClass() has a 3rd return, classID.

Decided to get the info from what specs have what IDs from GetSpecializationInfoByID()

Here is the list:

Thank you for this one. Less work for me :P

UnitAura seems to have changed but I couldn't find this mentioned anywhere. More importantly it's behaving in a really horrible way.

On live there's 13 return values (name through to isBossDebuff) plus an additional 3 return values for tooltip information.

In the latest build there's a minimum of 14 return values, the last one being a boolean. You'd expect the 3 tooltip values to then be values 15-17, however here's how it works for the following two buffs:

Legacy of the White Tiger:

14 return values, last one is a boolean. Values 15-17 aren't returned (so they're nil, effectively).

Life Cocoon:

17 return values, however 14-16 are the tooltip values, whereas this mystery boolean is #17.

Basically it's a major pain now because whereas we could (hopefully) have assumed #14-16 to be nil/number values, we now have to check if #17 is not nil in order to determine whether or not tooltip values exist.

Of course I could be completely missing something here so do correct me if I'm wrong :)

/dump's of the returns:
In short the stack needs 0's or nil's at 14-16 for the first case :)

Been looking through globalstrings.lua and so far i have not been able to find the strings for the friendship levels. I hoped that there would be something similar to FACTION_BAR_COLORS and FACTION_STANDING_LABEL in there.

I did some digging and according to Nat Pagle (ref: http://www.elsanglin.com/nat_pagle.html) there are 6 ranks called: "Stranger", "Pal", "Buddy", "Friend", "Good Friend", and "Best Friend" in English.

I can't post on the US-forums, so im kindly asking Talyrius :) if he can do another post.
Is this a oversight by the devs or is there some other method to get this info?

The 6th return from GetFriendshipReputationByID(id) gives you the standing name of an NPC.
Also, the colors for bars are green all the way, since you can't go neutral or below with them.

To see how it could be implemented, here is a link to framexml and my addon, oUF_Friendship:

https://github.com/p3lim/wow-ui-sour...Frame.lua#L171
https://github.com/p3lim/oUF_Friends...ndship.lua#L80

As for the ID used for this function, you can gather them into a table by using this:

If any of you are wondering, like me, what the point of these values are when the 2nd return value is already locale-independent, the answer seems to be: the numeric form is fed to talent-related functions. So far I see it passed to GameTooltip:SetTalent() and to GetTalentLink().

AFAICT there are no named constants for these values yet.

I only just got the beta, so this is probably "old", but I noticed a new event BAG_UPDATE_DELAYED firing, which I haven't seen any mention of so far. Not sure of the exact details, but basically seems to fire once per batch of BAG_UPDATE, presumably letting us no longer worry about throttling bag update event spam. Passes no arguments.

Look at the class order for the updated version of Interface\MINIMAP\POIICONS.BLP:

Cute. I wonder if we'll start seeing function wrappers to do modulo math and return the texcoords, rather than a series of hardcoded texcoords like CLASS_ICON_TCOORDS.

Calling GetTransmogrifySlotInfo during PLAYER_LOGIN on a 64-bit client crashes the client. (still, so might not be wholly relevant to this thread) Could anyone perhaps file a US report on this? I mentioned it in the 64 bit feedback thread when they launched that, but didn't seem to help.

5.0.4 on Live servers the 28th of August.

Cool, all thats missing then are localized strings for the titles (stranger, pal, buddy etc).

There is nothing in _G about this at the moment so the only thing you can get is the current value from the function itself.

In other words: You can't get the next/previous level of friendship titles like you can with faction rep and FACTION_STANDING_LABEL1, FACTION_STANDING_LABEL2, etc

(some pseudocode to show what im trying to do).

GetSpellBookItemName(index, booktype) will cause an error ("... invalid spell slot ...") instead of returning <nil> values for non-existant spell slots it seems. I solved this by using pcall for the moment, but that's just not very smart. Is there way to tell how many slots there are?

I used that in one of my addons earlier but managed to bypass it somehow but can't remember how but now I see that same error for GetSpellInfo as well in nUI. Not double checked my own addons yet. Something for tonight me thinks.

GetSpellInfo(spellId) is still working fine for me for some reason. I remember some people reporting inconsistent return values for some of the GetSpellxxx functions on official forums these days.

I just took a look at my post in the nUI forums about my investigations yesterday and I found that somehow the way Scott has coded it to build the spell database for cool downs wow no longer likes it twice as the first time it goes through fine but the second time it errors out.

For no apparent reason barring it is a different event. Which makes it difficult if SPELLS_CHANGED isn't called when you learn a spell as if you tried to also run through the update routine when LEARNED_SPELL_IN_TAB event is fired it would error out. Or any such other Spell related event required an update to the table the way it currently does it in nUI.

If it isn't a blizzard oversight I may have to recode how it builds the spell database so that it could be dynamically built rather than rebuilt everytime.