Is it possible to exclude warlock pets from the 'pet' class?
Is it possible to 'bucket' all raid members by class or group number?
The mod I wrote uses RosterLib but has to create a copy of the roster categorized by class, basically recreating it on every update.
I would say no. The idea of the library is to provide an access to tables. Right now, tables are accessed through thier names. That's it.
If you want to filter by class, group, or what not. Just listen to the events and keep only the name of the unit in your table. The use Roster API to get other information about the unit. This is the most effective way to do it, because not all addons that use Roster needs all thoses sorting options.
That being said, GetRaidRosterInfo() is being extended for TBC. Several new informations are going to be available, like the "role" of the unit (maintank, mainassist) and wether the unit is the master looter or not. Integrating thoses additions in Roster can be done without breaking the API, hopefully. It's probably best to fire specific events when the "role" change, as a loot of "MT list" type addons will want to know about this specific type of change. I don't feel like a complete overhaul of the API is necessary, but maybe now's the right time to ask the question.
RosterLib and Banzai (afaik the only addon/library that actually stores info in the roster tables) need to be changed so that they work similarly to how SEEA works now.
Storing additional/custom per-unit data would be handled through RL:SetAttribute(unitName, attributeName, value) and RL:SetUnitAttribute(unitid, attributeName, value) with the corresponding Get functions.
Is there a reason why RosterLib_UnitChanged gets triggered twice for every unit when you leave or join a group?
Here's my function:
function PallyPower:RosterLib_UnitChanged(unitid, name, class, subgroup, rank, oldname, oldunitid, oldclass, oldsubgroup, oldrank)
if not name then
self:Debug("UnitLeft", unitid, name, class, subgroup, rank, oldname, oldunitid, oldclass, oldsubgroup, oldrank)
elseif not oldname then
self:Debug("UnitJoined", unitid, name, class, subgroup, rank, oldname, oldunitid, oldclass, oldsubgroup, oldrank)
else
--nothing
end
end
When someone invites me into a group:
>Name has invited you to join a group
(DEBUG) PallyPower:[17:47:46.968] UnitJoined party1 Name PALADIN 1 0 nil nil nil nil nil
>Dungeon difficulty set to Heroic
(DEBUG) PallyPower:[17:47:46.125] UnitJoined party1 Name PALADIN 1 0 nil nil nil nil nil
> joining Warsong BG
(DEBUG) PallyPower:[17:48:41.687] UnitLeft nil nil nil nil nil Name PALADIN 1 0
> Looting changed to free-for-all.
>You have joined a raid group.
>Dungeon difficulty set to Normal
(DEBUG) PallyPower:[17:48:41.733] UnitLeft nil nil nil nil nil Name PALADIN 1 0
(DEBUG) PallyPower:[17:48:42. 93] UnitJoined Name2 ROGUE 2 2 nil nil nil nil nil
(DEBUG) PallyPower:[17:48:42.147] UnitJoined Name2 ROGUE 2 2 nil nil nil nil nil
I think it would be better if it would trigger different events for unit leaves, unit changes unitid, unit joins, unit joins etc... this would make it possible to save much logic if you are not interested in changed unitid's and just register to the events you need.
I found a really extreme example while debugging my addon:
If you leave alterac valley as the last person Roster_UnitChanged can fire up to 820 times just from the leaving persons.
the first person leaves, up to 39 people get a new raid id .. so for everybody the event is triggerd that they get a new raid id ( old raid40 -> new raid39, old raid39 -> new raid38 ) ..
for every call I have to do some comparisions in my addon to find out why the heck the event fired and have to compare everything to find out what happened.. I can't believe this is good if many addons use roster if every addon has to do it itself.
I found a really extreme example while debugging my addon:
If you leave alterac valley as the last person Roster_UnitChanged can fire up to 820 times just from the leaving persons.
the first person leaves, up to 39 people get a new raid id .. so for everybody the event is triggerd that they get a new raid id ( old raid40 -> new raid39, old raid39 -> new raid38 ) ..
for every call I have to do some comparisions in my addon to find out why the heck the event fired and have to compare everything to find out what happened.. I can't believe this is good if many addons use roster if every addon has to do it itself.
Well, if the unitid changes, RosterLib should be telling you. If you'd like to suggest non-backwards-compatible changes, there's Roster-2.2 thread over here.
Any word on a fix for these duplicate triggers yet? I updated to 2.1 as 2.0 is being removed but now I get duplicate events every time. I would rather stick with 2.0 if that is the case. Thx
I'd like to request RosterLib be updated to be Battleground friendly.
In a nutshell all code like:
local name = UnitName(unitid)
should be replaced with code like:
local shortname, realm = UnitName(unitid)
local name = nil
if realm and realm ~= "" then
name = shortname .. "-" .. realm
else
name = shortname
end
Blizzard's UNIT_SPELLCAST_SENT returns the player's name in this Name-Realm format so it is important that any mods that use the player's name as an index also adhere to this format.
I'd be glad to make the changes myself if the people with access do not have the time.
Thanks for your time and for this great library!
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
The new library is already documented in the wiki :
http://www.wowace.com/wiki/Roster-2.1
Of particular interest to author is the last section,
http://www.wowace.com/wiki/Roster-2.1#Difference_between_RosterLib-2.0_and_Roster-2.1
You'll see that the difference is minimal.
Please be aware that, as requested by Rabbit, I will modify http://svn.wowace.com/wowace/trunk/RosterLib/RosterLib.toc to point to the new library.
This change in the API allows the library to stop having to recycle table.
Is it possible to exclude warlock pets from the 'pet' class?
Is it possible to 'bucket' all raid members by class or group number?
The mod I wrote uses RosterLib but has to create a copy of the roster categorized by class, basically recreating it on every update.
I would say no. The idea of the library is to provide an access to tables. Right now, tables are accessed through thier names. That's it.
If you want to filter by class, group, or what not. Just listen to the events and keep only the name of the unit in your table. The use Roster API to get other information about the unit. This is the most effective way to do it, because not all addons that use Roster needs all thoses sorting options.
That being said, GetRaidRosterInfo() is being extended for TBC. Several new informations are going to be available, like the "role" of the unit (maintank, mainassist) and wether the unit is the master looter or not. Integrating thoses additions in Roster can be done without breaking the API, hopefully. It's probably best to fire specific events when the "role" change, as a loot of "MT list" type addons will want to know about this specific type of change. I don't feel like a complete overhaul of the API is necessary, but maybe now's the right time to ask the question.
Storing additional/custom per-unit data would be handled through RL:SetAttribute(unitName, attributeName, value) and RL:SetUnitAttribute(unitid, attributeName, value) with the corresponding Get functions.
UnitIsConnected(unitid)
Here's my function:
function PallyPower:RosterLib_UnitChanged(unitid, name, class, subgroup, rank, oldname, oldunitid, oldclass, oldsubgroup, oldrank)
if not name then
self:Debug("UnitLeft", unitid, name, class, subgroup, rank, oldname, oldunitid, oldclass, oldsubgroup, oldrank)
elseif not oldname then
self:Debug("UnitJoined", unitid, name, class, subgroup, rank, oldname, oldunitid, oldclass, oldsubgroup, oldrank)
else
--nothing
end
end
When someone invites me into a group:
>Name has invited you to join a group
(DEBUG) PallyPower:[17:47:46.968] UnitJoined party1 Name PALADIN 1 0 nil nil nil nil nil
>Dungeon difficulty set to Heroic
(DEBUG) PallyPower:[17:47:46.125] UnitJoined party1 Name PALADIN 1 0 nil nil nil nil nil
> joining Warsong BG
(DEBUG) PallyPower:[17:48:41.687] UnitLeft nil nil nil nil nil Name PALADIN 1 0
> Looting changed to free-for-all.
>You have joined a raid group.
>Dungeon difficulty set to Normal
(DEBUG) PallyPower:[17:48:41.733] UnitLeft nil nil nil nil nil Name PALADIN 1 0
(DEBUG) PallyPower:[17:48:42. 93] UnitJoined Name2 ROGUE 2 2 nil nil nil nil nil
(DEBUG) PallyPower:[17:48:42.147] UnitJoined Name2 ROGUE 2 2 nil nil nil nil nil
and so on
I think it would be better if it would trigger different events for unit leaves, unit changes unitid, unit joins, unit joins etc... this would make it possible to save much logic if you are not interested in changed unitid's and just register to the events you need.
If you leave alterac valley as the last person Roster_UnitChanged can fire up to 820 times just from the leaving persons.
the first person leaves, up to 39 people get a new raid id .. so for everybody the event is triggerd that they get a new raid id ( old raid40 -> new raid39, old raid39 -> new raid38 ) ..
for every call I have to do some comparisions in my addon to find out why the heck the event fired and have to compare everything to find out what happened.. I can't believe this is good if many addons use roster if every addon has to do it itself.
Well, if the unitid changes, RosterLib should be telling you. If you'd like to suggest non-backwards-compatible changes, there's Roster-2.2 thread over here.
On a German client will you get back HUNTER or JAGER from data.class?
Thanks
I'd like to request RosterLib be updated to be Battleground friendly.
In a nutshell all code like:
local name = UnitName(unitid)
should be replaced with code like:
local shortname, realm = UnitName(unitid)
local name = nil
if realm and realm ~= "" then
name = shortname .. "-" .. realm
else
name = shortname
end
Blizzard's UNIT_SPELLCAST_SENT returns the player's name in this Name-Realm format so it is important that any mods that use the player's name as an index also adhere to this format.
I'd be glad to make the changes myself if the people with access do not have the time.
Thanks for your time and for this great library!