WoW:API GetRaidRosterInfo: Difference between revisions
Jump to navigation
Jump to search
GetRaidRosterInfo Documentation by Totem
No edit summary |
No edit summary |
||
Line 62: | Line 62: | ||
: Regarding the corrispondance of raid indecies to players. Let C be the list of players in a raid ordered by their raid index. It appears that after any series of changes is made to the raid, at the end all players from C still in the raid will retain their original ordering (even if they left and rejoined the raid), with new members existing at any index 0<i<=40. | : Regarding the corrispondance of raid indecies to players. Let C be the list of players in a raid ordered by their raid index. It appears that after any series of changes is made to the raid, at the end all players from C still in the raid will retain their original ordering (even if they left and rejoined the raid), with new members existing at any index 0<i<=40. | ||
--[[User:Dekstra|Dekstra]] 09:11, 20 April 2006 (EDT)<br> | |||
''What is described in the "Description" paragraph, is logically wrong.''<br> | |||
''Let's assume it is right.''<br> | |||
''If the raid group was full, than player A at index X left the raid, then player B joined the raid, he/she would be placed at the X index of the raid, to maintain all the other indices, according to the assumption.''<br> | |||
''Then, if player C left the raid who was at index Y, and player A rejoined the raid, the only available index would be Y, while the assumption says it should join it at index X, which is already taken by player B.'' | |||
---- | ---- | ||
{{WoW API}} | {{WoW API}} |
Revision as of 13:11, 20 April 2006
Gets information about each raid member.
GetRaidRosterInfo();
- Arguments
- ID of raidmember (1 ... MAX_RAID_MEMBERS)
- Returns
- name, rank, subgroup, level, class, fileName, zone, online, isDead
- name
- Provides the name of the character as a string.
- Possible values: Any valid character name
- rank
- Provides an integer of the character's current rank in the raid. 0 is a standard member of the raid. 1 is the Assistant - labeled (A) in the standard raid window. 2 is the Leader of the raid - labeled (L) in the standard raid window.
- Possible values: 0, 1, 2
- subgroup
- Provides the raid group this character is currently a member of. Raid subgroups are numbered on the standard raid window.
- Possible values: 1, 2, 3, 4, 5, 6, 7, 8
- level
- Provides the level of the character. If this character is offline, the level will show as 0 (not nil).
- Possible values: 0, any valid character level
- class
- Provides a string of the class of character. Capitalization seems to be standard (ex: Priest). This function works as normal for offline characters.
- Possible values: Any valid character class
- fileName
- This seems to also provide the character class, but fully capitalized in English (ex: PRIEST). This function works as normal for offline characters. And useful to determine class regardless of localization.
- Possible values: Any valid character class, but capitalized and always in English.
- zone
- Provides the name of the zone this character is currently in. This is the same value you see if you mouseover their portrait (if in group). If the character is offline, this value will be the string 'Offline'.
- BUG (as of 2/26/2005): It seems that the person calling this function will have their Zone value returned as nil if they have not changed locations since last reloading their UI. Once you change locations (get the name to popup on screen), it seems to return as normal. This only seems to affect when you look at the zone value of yourself from the raid.
- Possible values: nil, 'Offline', any valid location
- online
- Player's current online status
- Possible values: 1, nil
- isDead
- Returns if raid member is dead or not
- Example
name, rank, subgroup, level, class, fileName, zone, online = GetRaidRosterInfo(Raid_Member_ID_Number);
- Result
- Description
- Regarding the corrispondance of raid indecies to players. Let C be the list of players in a raid ordered by their raid index. It appears that after any series of changes is made to the raid, at the end all players from C still in the raid will retain their original ordering (even if they left and rejoined the raid), with new members existing at any index 0<i<=40.
--Dekstra 09:11, 20 April 2006 (EDT)
What is described in the "Description" paragraph, is logically wrong.
Let's assume it is right.
If the raid group was full, than player A at index X left the raid, then player B joined the raid, he/she would be placed at the X index of the raid, to maintain all the other indices, according to the assumption.
Then, if player C left the raid who was at index Y, and player A rejoined the raid, the only available index would be Y, while the assumption says it should join it at index X, which is already taken by player B.