Has anyone ever tested exactly when the 2 events RAID_ROSTER_UPDATE and PARTY_MEMBERS_CHANGED fire? I'm working on a raid addon, so I need an up-to-date roster information (a table storing name, raidid and subgroup) all the time.
First I was only using RAID_ROSTER_UPDATE with bad results, then I tried PARTY_MEMBERS_CHANGED instead. Interestingly on rare occasions my roster isn't up to date when watching either of these events:
Roster setup code:
Code:
for i = 1,GetNumRaidMembers() do
name = UnitName("raid"..i)
Roster[name] = {}
Roster[name].name = name
Roster[name].raidid = "raid"..i
_,_,subgroup = GetRaidRosterInfo(i)
Roster[name].subgroup = subgroup
end
Sometimes UnitName(Roster[name].raidid) ~= name after a while...
wowwiki says:
RAID_ROSTER_UPDATE
Fired whenever a raid is formed or disbanded, players are leaving or joining a raid (unsure if rejected join requests also fire the event), or when looting rules are changed (regardless of being in raid or party!)
PARTY_MEMBERS_CHANGED
Fired when the player's party changes.
As of 1.8.3 this event also fires when players are moved around in a Raid and when a player leaves the raid. This holds true even if the changes do not affect your party within the raid.
4-2-05 Edit: This event is called twice when the event PARTY_LOOT_METHOD_CHANGED is called.
7-28-05 EDIT: This event is generated whenever someone rejects an invite and your in a group, also generated obviously when someone joins or leaves the group. Also, if for instance you have 3 people in your group and you invite a 4th, it will generate 4 events. If you call GetNumPartyMembers() it will return 0, 1, 2, and 3. First event returing zero, 2nd event returning 1, etc etc.
|
This logic sounds stupid. Additionally I wonder if 1.10 is borked (guess my server isn't the only one having problems with 1.10 CTRA builds showing wrong class information for people in a raid sometimes).
My theory is:
- RAID_ROSTER_UPDATE fires when any unit in a raid changes their raidid. This will happen if people join/leave the raid.
- PARTY_MEMBERS_CHANGED fires when any unit in a raid has a new subgroup (but no raidid changes)
Is my theory correct? If yes, I guess one has to track both events and to find a solution to PARTY_MEMBERS_CHANGED fireing 5 (or 40?) times, returning different GetNumPartyMembers() (maybe also GetNumRaidMembers()) all the time?
Additionally, is anyone aware of incomplete raid data on PLAYER_LOGIN? If I scan the roster information right after logging in (unsure if it also happenes on reloading ui or zoning), it can happen that with the above code Roster[UnitName("player")] is nil.
PS: don't ask why I'm storing my table via names. There's a long explanation to it (but the short one is: it makes it easier to also have it working in parties, and even if raidids change, the name will never change)...
Thanks in advance!
Linear Mode
