Is there an API call that can pull down the raidID's of guild members to determine what raid gorup they are in?
We run two kara groups and it's a fair amount of work to keep tabs on who is in what group each night.
I'd like to see something where it would keep a running tab for officers of what raids the guild is locked into, and see what members are in each raidID.
So say..
RAIDID: 12345678 Karazhan
---Person A
---Person B
---Person C
RAIDID: 987543121 Karazhan
---Person D
---Person E
---Person F
RAIDID: 20923481 Gruul's Lair
---Person A
---Person B
---Person C
---Person D
---Person E
---Person F
Maybe even have a section for "Unlocked" people that we can see who is not locked into any raid ID, or the raidID of that particular dropdown.
There is not an API to pull info for others.
There is an API to pull info for "yourself".
An addon that does this would have to be installed by all concerned (as already mentioned),
and to share that data through addon communication.
I too would find such an addon extremely useful.
Gui code scares me to death, but I would be very much willing to work on the back-end.
My desired feature-set would be something along these lines: Front-end
A window that contains a tree. (or a button for each instance-id that shows the list of saved members)
Nodes:
+"Instance Name" - RaidId
-Member1
-Member2
..
Example:
+"Karazhan" - 1234567
-Member1,
-
-
-Memberx
+"Karazhan" - 1234568
-Membery,
-
-Memberz
and so on for all raidids communicated by the addon.
A button to request a "refresh" that will pull info from online members.
The ability to set some filters on information presented:
Instance Name, (I might want to leave heroics out of it fx), Level, Guild Rank.
Back-end:
When the addon user requests info, it should send a request to other addons,
and get a response with info returned from GetSavedInstanceInfo
for i=1,GetNumSavedInstances() do
instanceName, instanceID, instanceReset = GetSavedInstanceInfo(i)
end
The addon should "purge" outdated info either by matching with a hardcoded time reference of resets
(based on raid-calendar eu or us)
or by compairing timestamp of last request for info with instanceReset.
There should be 2 ways the addon updates its lists:
- monitor guild login/logout messages like some guild greet addons do, and queue requests for information.
(prioritize older timestamps)
- on demand from the addon user (button press?)
There is obviously alot of room for optimization in the communication department.
For example each local addon could monitor "INSTANCE_SAVED" messages
and actively send out new the new raidids or just store a "new" flag and timestamp to compare with requests
and only send new info.
I'm babbling here sorry :)
I'll try to start something, I really think such an addon would be extremely helpful in some situations.
There is enough addons spamming sync channels these days, if you make such an addon try keep it as minimal as possible, preferably only sync after a 'request' like a version query.
EDIT: Had I not been devoid of sleep and actually read the post above, I'd have noticed that I just reiterated everything that was just said.....GG
Yeah, obviously everyone needs to have the addon installed, but is that really that different than saying everyone needs to have oRA2, Omen, BigWigs, etc?
As for syncing, I originally was only thinking raid timers, so once a week it wouldn't have to update again. I had not considered Heroics, which are daily raid IDs also.
One solution could be to have it only broadcast IDs upon say login (or monitoring the "You are now saved" chat line). The mod would then remember this data statically until the time expires. This way, the only automatically sent raid info occurs during people's occasional login throughout the day. On a manual action, a user can request the raidID DB from all online members and compile a complete list (which obviously in turn can be passed on to another user). When i mean request the raidID DB I mean pull down all information the user has from all users online. That way, people who are offline at the time of the request will have their data added if they were ever online at the same time as someone who is online now.
I don't know how much traffic this would be otherwise, but users logging in would not pull down data automatically, only submit their own PERSONAL data. They would have to manually request it. (Similar to NECB. You can spam the NECB chat comm channel for people to see, but you don't know who has NECB installed unless you manually run a version check.)
Why can't you schedule raids and put people on them in groups? You can even do it in a forum thread with imagination? It takes an equal amount of energy to look at the roster as it does to log into the game, so if you make it a requirement I see no problem :D.
Why can't you schedule raids and put people on them in groups? You can even do it in a forum thread with imagination? It takes an equal amount of energy to look at the roster as it does to log into the game, so if you make it a requirement I see no problem :D.
Hope it's a rhetorical question :)
Apart from the well-oiled raiding machine guilds,
there's a few out there that walk a tight-rope between the social side and the raiding side,
and are comprised by seasoned raiders and "casuals" (for lack of a better word) at the same time.
In these situations you don't have the luxury of fixed "Team A" "Team B" "Team C" scenarios.
You mix and match and try to form viable raids on what's available.
Quote from Shadowed »
Well I was bored and did the entire thing anyway so moot point, just don't have a way to test it for a few days.
That's great news, hope after you've had a chance to test it, you'll be in a giving mood :)
Hope it's a rhetorical question :)
Apart from the well-oiled raiding machine guilds,
there's a few out there that walk a tight-rope between the social side and the raiding side,
and are comprised by seasoned raiders and "casuals" (for lack of a better word) at the same time.
In these situations you don't have the luxury of fixed "Team A" "Team B" "Team C" scenarios.
You mix and match and try to form viable raids on what's available.
That's great news, hope after you've had a chance to test it, you'll be in a giving mood :)
This is exactly why. By the end of the week, both groups will be comprised of 15 people locked in, (whom of which are filled in on a need basis thoughout the week) and if there still something to do, say Netherspite, I'd like to know who is available at a glance and not have to A) look it up on a forum, or B) update a post every single time I add someone for the week. This is also complicated by the fact that peoples ALTS will be saved to different groups, making for a bit of mental confusion as officers try to remember what alt is saved to what instance. There's no guarantee that an actual officer was even present for the run, or the fact that some members might try to PuG it on their own in order to get loots from bosses already cleared.
It's not that updating a forum post or enforcing a schedule is hard, it's just a lot of overhead for a casual guild that could be better served by a mod.
I'll be trying out this mod with the guild officers tonight and tommorrow. If it works well, I'll prob expand to the rest of the guild. We might try it out on some heroics or ZG to see if it'll pick up the timers correctly.
I assume that I need all 4 files into the folder? I'm not familar with them, but they look like dongle GUI libs?
Just an idea, but you could probably make do without everyone installing the mod if you keep a database of players and the raids they're saved to. E.g. when you kill a boss in an instance (or just see the 'saved to this instance' message), you mark down everyone in the raid and in the zone as having the same ID as you.
OptionHouse is thhe place to put configurations, HousingAuthority is what actually makes the configuration widgets, they aren't exactly Dongle GUI libraries though, they just used to use DongleStub, and were moved over to LibStub when it came out.
Mostly, because i'm lazy and didn't feel like doing the GUI work.
That would prob explain why it's erroring out. If I knew anything about lua, I'd give you a hand on the GUI. I'll look though some of the ACE/Rock libs and see if I can make a gui. At least we can get the backend working till then.
TBH, I think it should just forgo all GUI work and just have it output to console till we know it works well.
We run two kara groups and it's a fair amount of work to keep tabs on who is in what group each night.
I'd like to see something where it would keep a running tab for officers of what raids the guild is locked into, and see what members are in each raidID.
So say..
RAIDID: 12345678 Karazhan
---Person A
---Person B
---Person C
RAIDID: 987543121 Karazhan
---Person D
---Person E
---Person F
RAIDID: 20923481 Gruul's Lair
---Person A
---Person B
---Person C
---Person D
---Person E
---Person F
Maybe even have a section for "Unlocked" people that we can see who is not locked into any raid ID, or the raidID of that particular dropdown.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIf yes, that's fine.
There is an API to pull info for "yourself".
An addon that does this would have to be installed by all concerned (as already mentioned),
and to share that data through addon communication.
I too would find such an addon extremely useful.
Gui code scares me to death, but I would be very much willing to work on the back-end.
My desired feature-set would be something along these lines:
Front-end
A window that contains a tree. (or a button for each instance-id that shows the list of saved members)
Nodes:
+"Instance Name" - RaidId
-Member1
-Member2
..
Example:
+"Karazhan" - 1234567
-Member1,
-
-
-Memberx
+"Karazhan" - 1234568
-Membery,
-
-Memberz
and so on for all raidids communicated by the addon.
A button to request a "refresh" that will pull info from online members.
The ability to set some filters on information presented:
Instance Name, (I might want to leave heroics out of it fx), Level, Guild Rank.
Back-end:
When the addon user requests info, it should send a request to other addons,
and get a response with info returned from
GetSavedInstanceInfo
for i=1,GetNumSavedInstances() do
instanceName, instanceID, instanceReset = GetSavedInstanceInfo(i)
end
The addon should "purge" outdated info either by matching with a hardcoded time reference of resets
(based on raid-calendar eu or us)
or by compairing timestamp of last request for info with instanceReset.
There should be 2 ways the addon updates its lists:
- monitor guild login/logout messages like some guild greet addons do, and queue requests for information.
(prioritize older timestamps)
- on demand from the addon user (button press?)
There is obviously alot of room for optimization in the communication department.
For example each local addon could monitor "INSTANCE_SAVED" messages
and actively send out new the new raidids or just store a "new" flag and timestamp to compare with requests
and only send new info.
I'm babbling here sorry :)
I'll try to start something, I really think such an addon would be extremely helpful in some situations.
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorYeah, obviously everyone needs to have the addon installed, but is that really that different than saying everyone needs to have oRA2, Omen, BigWigs, etc?
As for syncing, I originally was only thinking raid timers, so once a week it wouldn't have to update again. I had not considered Heroics, which are daily raid IDs also.
One solution could be to have it only broadcast IDs upon say login (or monitoring the "You are now saved" chat line). The mod would then remember this data statically until the time expires. This way, the only automatically sent raid info occurs during people's occasional login throughout the day. On a manual action, a user can request the raidID DB from all online members and compile a complete list (which obviously in turn can be passed on to another user). When i mean request the raidID DB I mean pull down all information the user has from all users online. That way, people who are offline at the time of the request will have their data added if they were ever online at the same time as someone who is online now.
I don't know how much traffic this would be otherwise, but users logging in would not pull down data automatically, only submit their own PERSONAL data. They would have to manually request it. (Similar to NECB. You can spam the NECB chat comm channel for people to see, but you don't know who has NECB installed unless you manually run a version check.)
ORLY?
Apart from the well-oiled raiding machine guilds,
there's a few out there that walk a tight-rope between the social side and the raiding side,
and are comprised by seasoned raiders and "casuals" (for lack of a better word) at the same time.
In these situations you don't have the luxury of fixed "Team A" "Team B" "Team C" scenarios.
You mix and match and try to form viable raids on what's available.
That's great news, hope after you've had a chance to test it, you'll be in a giving mood :)
If it doesn't error right away, I'd be amazed though.
This is exactly why. By the end of the week, both groups will be comprised of 15 people locked in, (whom of which are filled in on a need basis thoughout the week) and if there still something to do, say Netherspite, I'd like to know who is available at a glance and not have to A) look it up on a forum, or B) update a post every single time I add someone for the week. This is also complicated by the fact that peoples ALTS will be saved to different groups, making for a bit of mental confusion as officers try to remember what alt is saved to what instance. There's no guarantee that an actual officer was even present for the run, or the fact that some members might try to PuG it on their own in order to get loots from bosses already cleared.
It's not that updating a forum post or enforcing a schedule is hard, it's just a lot of overhead for a casual guild that could be better served by a mod.
I'll be trying out this mod with the guild officers tonight and tommorrow. If it works well, I'll prob expand to the rest of the guild. We might try it out on some heroics or ZG to see if it'll pick up the timers correctly.
I assume that I need all 4 files into the folder? I'm not familar with them, but they look like dongle GUI libs?
Yes you need all 4 files in a folder named like the .toc file <RaidID>.
I'm still looking for some lab-rats in the guild to test this out :)
OptionHouse is thhe place to put configurations, HousingAuthority is what actually makes the configuration widgets, they aren't exactly Dongle GUI libraries though, they just used to use DongleStub, and were moved over to LibStub when it came out.
Mostly, because i'm lazy and didn't feel like doing the GUI work.
Also you have a few typos, look for thhen =P
That would prob explain why it's erroring out. If I knew anything about lua, I'd give you a hand on the GUI. I'll look though some of the ACE/Rock libs and see if I can make a gui. At least we can get the backend working till then.
TBH, I think it should just forgo all GUI work and just have it output to console till we know it works well.
I could do a seperate UI if I really wanted, OH/HA work fine.