LibSpecRoster
LibSpecRoster is a very lightweight library to keep track of group (party/raid) specializations, roles, talents, and glyphs.
Blizzard made some nice changes with 5.0. All spec changes by group members trigger the PLAYER_SPECIALIZATION_CHANGED event, and group members can always be inspected, no matter where they are, as long as they are online.
This means that there is no longer any reason for complex libraries that watch group members' casts to see if they cast a spec change, and that invalidate their data if they go out of range or out of zone. This also means that it is not efficient to send spec changes over addon comm, since less data will be flying around if you DON'T do so.
The library makes an effort not to issue any unnecessary inspect requests. There is a small delay before requests are issued, and requests by other addons are tracked and not duplicated when possible. All relevant inspect data that comes in to the client is used to keep data up to date.
Library Methods:
lib.RegisterMessage(yourObject, "LSR_callbackMessageName", yourMethod) lib.UnregisterMessage(yourObject, "LSR_callbackMessageName") lib.UnregisterAllMessages(yourObject) lib.getInspectData(guid) - returns specName, specID, class, role, blizzRole, talents, glyphs lib:getSpecialization(guid) - returns specName, specID, class lib:getRole(guid) - returns role, blizzRole
Callback Messages:
"LSR_SpecializationChanged" - params: eventName, guid, unit, specID, talents, glyphs "LSR_RoleChanged" - params: eventName, guid, unit, role "LSR_TalentUpdate" - params: eventName, guid, unit, specID, talents, glyphs "LSR_GlyphUpdate" - params: eventName, guid, unit, specID, talents, glyphs
Method / Callback Details:
Roles are "tank" or "healer" or "melee" or "ranged".
Blizzard roles are "TANK" or "HEALER" or "DAMAGER".
Class is always the non-localized class name, i.e. the second return from UnitClass().
Talents are returned as a simple array of the form {[talentLine] = SpellID | false}, i.e. if no talent has been selected on a given line, the array holds a value of false for that line.
The glyph array has the form {[glyphSlot] = { spellID = SpellID, rank = 1 | 2} | false}. rank==1 is a minor glyph, rank==2 is a major glyph (as in Blizzard returns). Again, if a slot is empty, the entire entry for that slot is set to false.
Caveats:
There is currently no way to detect talent changes that do not involve changing spec. They do not trigger an event (except to that player), and there is no spellcast. Addon comm could be used for this, but unless all clients were running this library, the information would be partial and so, not reliable, which I find greatly limits its usefulness. So I kept it simple.
The talent and glyph update callbacks are triggered whenever inspect data comes in that shows a change, but, again, talent and glyph changes are not and cannot reasonably be tracked.
The library captures all relevant inspects, so, if your addon calls NotifyInspect() for a unit and there is a change, the update callbacks will trigger. Do be conservative with this, though.
Comments
-
_ForgeUser1960144 Owner
-
View User Profile
-
Send Message
Posted May 29, 2013I too was looking for libraries to handle unit spec, etc. info and came across both this and LibGroupInSpecT and was trying to get a quick view of their differences and which would fit best for me.
Without yet downloading both and reviewing code (would love to hear from others that have though), initial differences look like the info structure from LibGroupInSpecT has a few more fields in it, like realm, race, gender, and some additional uncooked or differently cooked values for specs, talents, glyphs, etc. It also does use an addon channel to communicate talent changes, with the same caveats mentioned here. What I don't yet know is relative performance, size of code, and general stability/correctness. Both look relatively active.
I'll update if/when I look at both more closely, if someone else hasn't already.
short update: Scanned the projects as of 5/29/13.
They aren't drastically different in size. Lua code is 29K for LibGroupInSpecT, 20K for LibSpecRoster. Code for both looks similar and clean, with the caveat that it was only a cursory inspection and that I'm far from experienced. Looked like most of the code length difference is due to the extra fields handled by LibGroupInSpecT and the comm channel feature.
They use a very different method of finding the spell id for a glyph. LibSpecRoster's version certainly looks cleaner to me. LibGroupInSpecT scans the tooltip to get the ID. It looks like it was a workaround, but not sure if it is still needed.
May be wrong, but the LibGroupInSpecT comm functionality looks like it sends info repeatedly vs. only in the situation that a talent or glyph change is made without a spec change. The amount of data it sends is pretty small, so probably not an issue(?).
Both require the same libraries - LibStub and CallbackHandler. Both hook the NotifyInspect so that other code doing inspection will cause the library to not duplicate the inspect. Both do some version of burst inspect handling while still throttling over longer time frames.
My initial reaction would be to use LibGroupInSpecT if I wanted any of the extra fields handled without me having to do the work, or if I expected my addon to be used by multiple people in a group/raid *and* needed to know if glyph/talents changed without a spec change. If I didn't care about any of that, I'd probably use LibSpecRoster to save a bit of code size. Again this is based on quick look, without actually using either (that happens now…)
-
View User Profile
-
Send Message
Posted Jan 6, 2013@Greltok
No, thats the specialization id like returned by GetInspectSpecialization. I would need the spec index (like from GetSpecialization). But I'am using LibGroupInspecT now, which does just this.
-
View User Profile
-
Send Message
Posted Jan 6, 2013@Jitter88
Isn't that the second return value for :getSpecialization()?
-
View User Profile
-
Send Message
Posted Dec 11, 2012Could you add the specindex as returned by GetSpecialization() please?
-
View User Profile
-
Send Message
Posted Nov 28, 2012Could you comment the differences between LibSpecRoster and LibGroupInSpecT ? I got an addon that needs spec/talents/glyphs from raid members, and do not see which one would be the best for that usage.
-
View User Profile
-
Send Message
Posted Oct 19, 2012Thanks for this library. Using it in GladiusEx, working well so far.