WowAce

What steps will reproduce the problem?
1. Something to do with ADDON_MSG

What version of the product are you using?
Latest alpha

Do you have an error log of what happened?

<<code>> 2x ...own\libs\LibGroupInSpecT-1.1\LibGroupInSpecT-1.1-68.lua:753: attempt to index local 'talents' (a nil value) ...own\libs\LibGroupInSpecT-1.1\LibGroupInSpecT-1.1-68.lua:753: in function `eventhandler' ...own\libs\LibGroupInSpecT-1.1\LibGroupInSpecT-1.1-68.lua:129: in function <...own\libs\LibGroupInSpecT-1.1\LibGroupInSpecT-1.1.lua:127>

Locals: this = LibGroupInSpecT-1.1_Frame { 0 = <userdata> OnUpdate = <function> defined @BL_Cooldown\libs\LibGroupInSpecT-1.1\LibGroupInSpecT-1.1.lua:284 OnEvent = <function> defined @BL_Cooldown\libs\LibGroupInSpecT-1.1\LibGroupInSpecT-1.1.lua:127 } event = "CHAT_MSG_ADDON" eventhandler = <function> defined @BL_Cooldown\libs\LibGroupInSpecT-1.1\LibGroupInSpecT-1.1.lua:704 lib = <table> { DoPlayerUpdate = <function> defined @BL_Cooldown\libs\LibGroupInSpecT-1.1\LibGroupInSpecT-1.1.lua:640 GetCachedInfo = <function> defined @BL_Cooldown\libs\LibGroupInSpecT-1.1\LibGroupInSpecT-1.1.lua:895 PLAYER_ENTERING_WORLD = <function> defined @BL_Cooldown\libs\LibGroupInSpecT-1.1\LibGroupInSpecT-1.1.lua:601 BuildInfo = <function> defined @BL_Cooldown\libs\LibGroupInSpecT-1.1\LibGroupInSpecT-1.1.lua:494 GroupUnits = <function> defined @BL_Cooldown\libs\LibGroupInSpecT-1.1\LibGroupInSpecT-1.1.lua:933 INSPECT_READY = <function> defined @BL_Cooldown\libs\LibGroupInSpecT-1.1\LibGroupInSpecT-1.1.lua:573 Query = <function> defined @BL_Cooldown\libs\LibGroupInSpecT-1.1\LibGroupInSpecT-1.1.lua:385 GLYPH_ADDED = <function> defined @BL_Cooldown\libs\LibGroupInSpecT-1.1\LibGroupInSpecT-1.1.lua:815 UpdatePlayerInfo = <function> defined @BL_Cooldown\libs\LibGroupInSpecT-1.1\LibGroupInSpecT-1.1.lua:483 UNIT_LEVEL = <function> defined @BL_Cooldown\libs\LibGroupInSpecT-1.1\LibGroupInSpecT-1.1.lua:789 hooked = true UNIT_NAME_UPDATE = <function> defined @BL_Cooldown\libs\LibGroupInSpecT-1.1\LibGroupInSpecT-1.1.lua:825 PLAYER_SPECIALIZATION_CHANGED = <function> defined @BL_Cooldown\libs\LibGroupInSpecT-1.1\LibGroupInSpecT-1.1.lua:804 ProcessQueues = <function> defined @BL_Cooldown\libs\LibGroupInSpecT-1.1\LibGroupInSpecT-1.1.lua:416 state = <table> { } GuidToUnit = <function> defined @BL_Cooldown\libs\LibGroupInSpecT-1.1\LibGroupInSpecT-1.1.lua:372 commScope = "RAID" UpdateCommScope = <function> defined @BL_Cooldown\libs\LibGroupInSpecT-1.1\LibGroupInSpecT-1.1.lua:686 cache = <table> { } PLAYER_LOGIN = <function> defined @BL_Cooldown\libs\LibGroupInSpecT-1.1\LibGroupInSpecT-1.1.lua:251 GROUP_ROSTER_UPDATE = <function> defined @BL_Cooldown\libs\LibGroupInSpecT-1.1\LibGroupInSpecT-1.1.lua:613 NotifyInspect = <function> defined @BL_Cooldown\libs\LibGroupInSpecT-1.1\LibGroupInSpecT-1.1.lua:154 QueuedInspections = <function> defined @BL_Cooldown\libs\LibGroupInSpecT-1.1\LibGroupInSpecT-1.1.lua:877 UNIT_AURA = <function> defined @BL_Cooldown\libs\LibGroupInSpecT-1.1\LibGroupInSpecT-1.1.lua:839 UnregisterAllCallbacks = <function> defined @LibSharedMedia-3.0\CallbackHandler-1.0\CallbackHandler-1.0.lua:202 Rescan = <function> defined @BL_Cooldown\libs\LibGroupInSpecT-1.1\LibGroupInSpecT-1.1.lua:901 static_cache = <table> { } CacheGameData = <function> defined @BL_Cooldown\libs\LibGroupInSpecT-1.1\LibGroupInSpecT-1.1.lua:350 GetCachedTalentInfo = <function> defined @BL_Cooldown\libs\LibGroupInSpecT-1.1\LibGroupInSpecT-1.1.lua:323 StaleInspections = <function> defined @BL_Cooldown\libs\LibGroupInSpecT-1.1\LibGroupInSpecT-1.1.lua:886 Refresh = <function> defined @BL_Cooldown\libs\LibGroupInSpecT-1.1\LibGroupInSpecT-1.1.lua:404 UNIT_SPELLCAST_SUCCEEDED = <function> defined @BL_Cooldown\libs\LibGroupInSpecT-1.1\LibGroupInSpecT-1.1.lua:868 SendLatestSpecData = <function> defined @BL_Cooldown\libs\LibGroupInSpecT-1.1\LibGroupInSpecT-1.1.lua:647 PLAYER_LOGOUT = <function> defined @BL_Cooldown\libs\LibGroupInSpecT-1.1\LibGroupInSpecT-1.1.lua:275 GLYPH_REMOVED = <function> defined @BL_Coo <</code>>

Same here, getting it when accepting a group invitation

Although I don't experience this error myself, I am having many users reporting this issue.

Getting this all the time during raids.

Thanks for reporting - I'll get this looked at ASAP! Apologies for the delay - I've been away overseas.

Okay, I believe I've got this addressed now. I'll leave it open for a while yet, so if pain persists, please let me know!

you can get the name and the icon from GetTalentInfoByID and the spell id from tooltip scanning (SetTalent(talentID)), so the only thing you need inspect data for is tier/column, which I just suggest you'd just drop. (spell id is kind of redundant now, too)

  local talents = self.static_cache.talents[info.class_id] or {}
  ...
      if not talents[talent_id] then -- FIXME received sync data before caching the class's talents
        local _, name_localized, icon = GetTalentInfoByID(talent_id)
        tip:SetTalent (talent_id)
        local _, _, spell_id = tip:GetSpell ()
        talents[talent_id] = {
          spell_id = spell_id,
          talent_id = talent_id,
          name_localized = name_localized,
          icon = icon,
          tier = 0,
          column = 0,
        }
      end
      info.talents[talent_id] = talents[talent_id]

that's the work around i use locally

I'm not sure how helpful this is, but the number of talents out there isn't that great.
Here's a pastebin I generated a few days ago trying to find some specific ID's
http://pastebin.com/k8HhqJUD

You could loop through from about 15000 to 22000 to grab all of them. Just some information to throw out there.

@nebula169: Go

This is interesting. The spell ID I kept for backwards compatibility, but the tier/column I could be persuaded to drop if that's something that nobody is actually using at this point. How would I go about finding that out, without just ripping them out and listening for the screams? :)

@InKahootz: Go

I do have a page of all the talent IDs here: http://www.wowace.com/addons/libgroupinspect/pages/talent-ids/

The problems with just iterating through the probable number range include missing newly introduced/changed talents, and not finding out which class they belong to. The latter could most likely be worked around with some refactoring of the internals of LGIST, but the former is a big drawback that I'm not keen on introducing, especially since I haven't been playing WoW since mid-Cataclysm and don't stay up to date with changes myself.

Current API:

  .talents = {
    [<talent_id>] = { -- Note: Since 1.1 this is a talent_id, not a spell_id
      .talent_id -- Introduced in 1.1. This replaces the old 1.0.x .idx entry
      .tier
      .column
      .name_localized
      .icon
      .spell_id
    }

Speaking for my client (RaidBuffStatus):

We currently use talent.spell_id field to generate tooltips on-demand for a particular talent (which is not your player or current inspect target), but it seems GameTooltip:SetTalent(talent_id) also works for that now, so it's not essential. icon and name_localized are both easily obtained from either, so those fields are also non-essential. However I believe these fields are also all trivial for the library to continue providing, so I see no motivation to remove them (breaking backward compatibility).

We *DO* currently use the talent.tier field, mostly for display purposes to correctly "line up" the talents of multiple raid members of the same class, so you can easily see which decision each raid member made on a given tier. The talent.column field is unimportant to us, but talent.tier is kind of nice for this type of display. Without the talent.tier field for sorting purposes, the RBS raid-wide talent display will basically be reduced to an unordered jumble of spell icons that is harder to parse. That being said it's only a display issue for us and would not break core functionality if it's a maintenance/performance problem. However it would be unfortunate if more than one client addon ends up separately maintaining a tier table, when such a table makes more sense to reside as a database in the central library.

From a library development perspective, removing existing fields breaks backwards compatibility and therefore runs the risk of generating lua errors in clients when a newer library is loaded by a different addon. We've already changed the library major version number once for 6.0 (and as far as I know that change was completely unmotivated by API change and just generated useless work for clients), but I guess we can do it again if this API change is highly motivated. However a major version change runs the risk of several different versions of the library running concurrently on a single client on behalf of different addons, which is also unfortunate (mostly due to Blizzard's global inspect throttling that is shared by all addons and library instances)

In the near term, I'd be in favor of leaving all existing fields (to prevent some lua errors when trying to access them) and if tier/column are undesirable to maintain then "deprecate" them and just fill in some dummy values (like 0). Then perhaps when WoD drops or later when we have bigger API changes to make, remove the deprecated fields and increment the library version at that time.

wrt spell_id, found out today GetSpellDescription properly replaces placeholders now, so keeping spell_id around actually has some use

Thanks Oscar; Since there's clearly at least one useful use-case for the tier/column info, I'll leave everything as-is. I don't want to remove genuinely useful bits of info just because it's a bit hard to get it - that just pushes the hard work onto the addons themselves and multiplies the pain.

If the need arises we can always extend the comms protocol to ship those bits across too, but I see that largely as an optimization.

The version number bump was because I had to break backwards compatibility due to the switch from spell ID/idx to talent IDs, as well as a new comms proto. Whether it was fully necessary can of course be argued, but at $work our motto is that if we know we might break things downstream, we prefer to do so explicitly rather than have issues pop up late down the track in subtle (and often horrible) ways.