Thanks for the screenshot. That was very helpful. I experienced something like this during development and thought I squashed the bug. Essentially, what is occurring is that as a new raid begins, the addon is hooking a whisper event filter into the Blizzard chat handler. When a raid ends, it removes the hook. If the behavior above is occurring, the removal isn't occurring and it is adding additional hooks as each new raid starts (each hook adds an additional handler). This is bad. I'll try to see if I can pinpoint it and release a fix this coming week. Do you have other addons installed that manipulate the chat frame or whispers?
The wl tag was chosen because some of the prior wait list addons used that abbreviation and it is shorthand for wait list. Otherwise, there is no rhyme or reason to the keyword. I can look into making this keyword configurable.
I do have some chat mod stuff (prat 3.0). I turned every addon off except for headcount and I still got this problem. However, instead of 6 replies I got 3.
I did test this with only one raid in headcount, the active one. I got the same result. From what you were saying there should only be one hook per raid, right?
If I looked it up correctly, LDB is LibDataBroker? I honestly know little to nothing about LDB, but can add this to the wish list.
I can't offer any timetable for this. My only priorities for the next set of releases is to get the wait list functionality stablized and add some minor usability enhancements.
No biggie. I could get rid of the minimap button and put the icon on a broker display with Fubar2Broker, but that would mean installing an additional addon just to move a button. Kinda overkill. :D So your addon gets a premium position on my screen as the only minimap button left in my UI.
But anyway, I suggest taking a closer look at the many nice broker addons and displays out there. It's not just FuBar anymore.
I do have some chat mod stuff (prat 3.0). I turned every addon off except for headcount and I still got this problem. However, instead of 6 replies I got 3.
I did test this with only one raid in headcount, the active one. I got the same result. From what you were saying there should only be one hook per raid, right?
I have a better guess why this is occurring, but will need to do some testing to fix this.
On my machine, I have one chat frame so I am experiencing none of the whisper duplication you mention:
General chat frame - whispers, says, yells, guild, raid, officer, party, etc.
This isn't a given for all users. As you mentioned, you can modify the default Blizzard UI manually or via chat mods (Prat) to have multiple chat frames. I am handling incoming whispers via the chat filter event rather than a standard event which I think is causing problems. So, if you have 6 chat frames:
1. Whisper received.
2. Filter for chatframe 1 hits (user is added to wait list, whisper is sent back).
3. Filter for chatframe 2 hits (whisper is sent back that user is already on the wait list).
4. Filter for chatframe 3 hits (whisper is sent back that user is already on the wait list).
5. Filter for chatframe 4 hits (whisper is sent back that user is already on the wait list).
6. Filter for chatframe 5 hits (whisper is sent back that user is already on the wait list).
7. Filter for chatframe 6 hits (whisper is sent back that user is already on the wait list).
I need to modify the whisper handling code so the generic whisper event handles the whisper handling (verifying the whisper and sending back the whisper response), while the filter is only used for supressing the display of local wait list whispers if configured to do so. This is what is intended, but is not occurring right now.
I'll do more investigation and try to get this fixed soon.
I think you are exactly right on this one. I have 3 chat frames. So with no mods on I get 3 responses. When prat on I get 6, prat probably adds a 'virtual' frame for each 'real' frame to do its business. I'll mention this to my raid admins and they can work around the bug without too much spam for the time being.
No biggie. I could get rid of the minimap button and put the icon on a broker display with Fubar2Broker, but that would mean installing an additional addon just to move a button. Kinda overkill. :D So your addon gets a premium position on my screen as the only minimap button left in my UI.
But anyway, I suggest taking a closer look at the many nice broker addons and displays out there. It's not just FuBar anymore.
I am particularity fond of StatBlock as a broker addon. In the mean time try out MBB, Minimap Button Bag, to solve your minimap button problems. It works great but is a little rusty and in need of a new manager/write soon.
I just uploaded, hopefully, a fix for the multiple whisper issue. Try the 1.5.1 download and get back to me if any duplicate whisper issues are still present.
Hopefully this is the right place, I have some suggestions and questions. :)
http://www.wowace.com/projects/head-count/tickets/15-manual-boss-kill-addition/
Related to the above ticket, manual raid events or "snapshots" would be great. We currently award an "on-time" bonus for people in the raid group 5 minutes before the raid is scheduled to begin. We can manually create the event on our website, but the ability to snapshot the raid at any given time and name the event would be awesome.
http://www.wowace.com/projects/head-count/tickets/17-bidding-support/
Currently we use whisperbid for our bidding needs. And it works alright. Something largely similar built into headcount, but with the ability to set custom "opening bidding" messages, a minimum overbid amount, and a minimum starting bid would be nice.
With the waitlist, I would like to see the ability to have members on the waitlist be awarded the hourly value, boss kill value, or both. I haven't gotten a chance to test it very much, but I didn't see an option related to that.
A few other waitlist features I'd like to see are...
-Automatic purging
If someone on the waitlist goes offline for more then time period they are automatically removed from the waitlist.
-"afk checks"
The ability to send whispers to every person on the waitlist along the lines of, "Are you there?". If they don't reply with, "yes" (or somesuch) they are removed from the waitlist.
In the mean time try out MBB, Minimap Button Bag, to solve your minimap button problems. It works great but is a little rusty and in need of a new manager/write soon.
I can just turn HeadCount into a broker by installing Fubar2Broker again, or simply turn off the minimap button and control it via command line. No way I am installing MBB again. :)
Hi there seppyk, first of all let me thank you for the awesome work you're doing on this addon.
I have a question and a feature suggestion for you, regarding the waitlist feature:
Question:
Currently, when someone joins manually the waiting list, he has immediately the End Time being set as the Start time, and the Wait list time under "Time Information" in the Member information is stuck on 00:00:00. If a member currently in waitlist is invited, the "End Time" disappear, the Start Time remains the one when he joined the waiting list, and on the raid end the total time displays only the amount of time he's actually been in the active raid (and not the one he was also in waitlist) . Is the time tracking for waitlist "spots" not fully implemented yet, or am I doing something wrong? I tried with both disabling and enabling the waitlisttime function in /headcount datetime timetotals, but the result is the same.
Suggestion:
it would be nice, as another option for the guys in wait list, to have something like a "wl contact" option, so that they can whisper in example the name of one of the alt characters they will be found on, or something like Ventrilo, or IRC. This would actually allow the raid leaders to know where to contact the guy if he's needed without forcing someone in wait list to necessarily stay logged on their main character.
Of course the "contact" method should be also displayed somewhere, could be in example in brackets when the wait list is listed.
Should the stuff I wrote be confusing, I am sorry, here's a simple example of what I mean:
- Wally enter wait list with "wl add"
- After a while Wally decide to watch a movie, but he will be available for raid and can be called on Ventrilo should he be needed.
- Wally whispers "wl contact Ventrilo"
- After a while the raid leaders need a replacement for a raider, the waitlist is listed and the string would show something like: [Headcount] Wait List: Bob, Wally (contact - Ventrilo), Rob
I am trying to integrate the wait list functionality into my DKP application. I do this by parsing the XML, but I am having difficulty understandin quite how its meant to work.
So for example, here is the relevent XML snippet from someone who joined the wait list at 18:47, then the raid at 19:52 to 22:00.
Like I say I can work all this out but it seems like this or probably not as intended so I'd appreciate a clarification before I fix my code. Can send you my saved vars if it helps?
I am trying to integrate the wait list functionality into my DKP application. I do this by parsing the XML, but I am having difficulty understandin quite how its meant to work.
So for example, here is the relevent XML snippet from someone who joined the wait list at 18:47, then the raid at 19:52 to 22:00.
Like I say I can work all this out but it seems like this or probably not as intended so I'd appreciate a clarification before I fix my code. Can send you my saved vars if it helps?
Thanks in advance.
I wouldn't touch that just yet. :)
I still need to integrate some info on the wait list into some of the export strings (wait list players and the time they joined). I'll see if I can add this soon. Durations can only be determined for users who are actually in the raid group.
If some custom logic is needed to determine how long someone was on the wait list, I would do the following:
1. Determine the wait list join time for a user.
2. Determine the end time for the raid.
3. Determine the time difference to determine how long they were waitlisted for.
Hopefully this is the right place, I have some suggestions and questions. :)
http://www.wowace.com/projects/head-count/tickets/15-manual-boss-kill-addition/
Related to the above ticket, manual raid events or "snapshots" would be great. We currently award an "on-time" bonus for people in the raid group 5 minutes before the raid is scheduled to begin. We can manually create the event on our website, but the ability to snapshot the raid at any given time and name the event would be awesome.
http://www.wowace.com/projects/head-count/tickets/17-bidding-support/
Currently we use whisperbid for our bidding needs. And it works alright. Something largely similar built into headcount, but with the ability to set custom "opening bidding" messages, a minimum overbid amount, and a minimum starting bid would be nice.
With the waitlist, I would like to see the ability to have members on the waitlist be awarded the hourly value, boss kill value, or both. I haven't gotten a chance to test it very much, but I didn't see an option related to that.
A few other waitlist features I'd like to see are...
-Automatic purging
If someone on the waitlist goes offline for more then time period they are automatically removed from the waitlist.
-"afk checks"
The ability to send whispers to every person on the waitlist along the lines of, "Are you there?". If they don't reply with, "yes" (or somesuch) they are removed from the waitlist.
Yea, the events structure would have to be modified to allow manual snapshots to occur. I don't have a timetable for this right now.
There is a ticket open for bidding support, but that seems more useful for a standalone mod. I know integration would be nice, but it's a low priority at this time.
There is another open ticket which will be addressed soon (next release) so users can define who automatically is given credit for a boss kill. Currently, only members in raid list groups are given credit, but the modification will allow the user to define which groups of players are automatically given credit. This would allow standby players to get some credit for attending a boss kill.
Automatic purging is not possible since there is no simple, consistent and generic method to determine if a player goes offline if they are outside of the raid group.
I agree with the use of making a wait list AFK check. I'd like to do this eventually.
Hi there seppyk, first of all let me thank you for the awesome work you're doing on this addon.
I have a question and a feature suggestion for you, regarding the waitlist feature:
Question:
Currently, when someone joins manually the waiting list, he has immediately the End Time being set as the Start time, and the Wait list time under "Time Information" in the Member information is stuck on 00:00:00. If a member currently in waitlist is invited, the "End Time" disappear, the Start Time remains the one when he joined the waiting list, and on the raid end the total time displays only the amount of time he's actually been in the active raid (and not the one he was also in waitlist) . Is the time tracking for waitlist "spots" not fully implemented yet, or am I doing something wrong? I tried with both disabling and enabling the waitlisttime function in /headcount datetime timetotals, but the result is the same.
Suggestion:
it would be nice, as another option for the guys in wait list, to have something like a "wl contact" option, so that they can whisper in example the name of one of the alt characters they will be found on, or something like Ventrilo, or IRC. This would actually allow the raid leaders to know where to contact the guy if he's needed without forcing someone in wait list to necessarily stay logged on their main character.
Of course the "contact" method should be also displayed somewhere, could be in example in brackets when the wait list is listed.
Should the stuff I wrote be confusing, I am sorry, here's a simple example of what I mean:
- Wally enter wait list with "wl add"
- After a while Wally decide to watch a movie, but he will be available for raid and can be called on Ventrilo should he be needed.
- Wally whispers "wl contact Ventrilo"
- After a while the raid leaders need a replacement for a raider, the waitlist is listed and the string would show something like: [Headcount] Wait List: Bob, Wally (contact - Ventrilo), Rob
The start and end time is the same because there's no simple way to determine the start and end times for a raid member if they are not in the raid itself. The only things that the addon can be aware of in terms of the raid is when the player joins the wait list (and in turn the raid). I guess a workaround to determine total wait list time would be doing a difference between when the raid ends and when the player joined the wait list via whisper.
I'll see what I can do about allowing the user to define a short note or contact name when they add themselves.
I would just like to add my support to the wl contact suggestion. Adding a generic string value would work very well for my guild, allowing a robust selection of information to be attached
wl contact "some string"
Where some string could be:
a phone number
alternative vent info
alt characters
afk time ranges
anything else handy
My guild really doesn't give a damn what you do, no need to punish people for not playing, so if we can find you in a timely manor is all that matters. This would be perfect for us.
I think this makes the AFK suggestion pointless.
Lastly, in response to the bidding support comment:
I am currently looking for a generic bidding/loot request system. We use loot council, so we are just looking to see if anyone has a functional system right now, or if we have to build it. See my post here if you have input/interest.
I guess a workaround to determine total wait list time would be doing a difference between when the raid ends and when the player joined the wait list via whisper.
Yes, or alternatively the difference between when the player joined the wait list and when he left it still via whisper.
i wrote these to comments part on main addon page, i will copy paste here because i am not sure if it was seen.
"i have several stuff in mind, however i dont know how much they are implementable. Let me begin.
1) It would be better if we could see the long term activity of a player, when we click on his/her name in the list(At the moment, it shows how long that person was in this current raid which i personally dont find very useful but it is not so bad either). Instead of showing data like "Name, Guild, Level, Gender, Race" which has no use for tracking the activity, you can add a string like RRRMRRRWRM. This string is for last 10 raids (you can do even more raids in this format), R= Joined to Raid, M= Missed Raid, W=Was in waitlist. you can also add other stuff for replaced or whatever. But this can help a guild leader to see how active that person is with one click on the name of the person. I admit this string is a simple idea, if you have better idea which shows activity better and simple, you can implement that as well.
2) It would be very good to have synchronization between the class leaders/officers/gm who are all using this addon. So that if any of these people gets "wl add" whisper for being added to wait list, it will update waiting list on all officers team's addons.
3) Binding names of the alts with a main character would also be very useful. because some people would like to join waiting list with their alt chars. "
My guild is using some short of mainspec, offspec, trash, DE and bank loot rules.
Means your choose your spec (ret pala for example), and if a ret pala item drops, you and every other Ret pala + Other people that can use that item for their main spec can roll. If you get something for your mainspec, you cant roll on another main spec item until everyone else have got one or pass on it.
Pretty much the same for offspec. Trash is for everyone, DE and Bank is pretty clear ;)
Now people got short memory, and quickly forget if they got anything during the raid week already.
Plan was to use a addon to count who got what, and put it on our forums.
We tried NRT and headcount so far. NRT have the + that it shows the notes you typed in for a item, but it isnt really the best for it, as it have notes for every item, instead of a item + player that got it. Means if "Gloves of pwnage" drops, and i get is as mainspec and type it into NRT, and someone else get the same item as offspec, it whould say for both mainspec or offspec, whatever i typed in last.
Headcount dosent show notes at all in the output, and thats the only problem with it.
So i wonder, seppyk, can you please just add a small option to allow notes showed for the PHPBB export? Thats pretty much all we need.
Whould be even nice to have loot shorted by player, so everyone can see right away what items someone got.
I'm curious if there was any further consideration for the sync feature discussed earlier in the thread. The problem we're facing is that we have a raid leader handling loot via master looting and the raid continues clearing the instance. This means that loot events are often missed by the master looter's instance of HC but are captured by another. We then have to merge XML exports to get a complete picture of the run or manually add individual items (thanks for that element!).
The sync feature would also provide some redundancy for the hard crash situation also discussed earlier when an entire loot log is lost. Reloading the UI periodically is possible but other mods such as our DKP tools may not recover as well as HC is currently.
Another consideration would be to provide an API for receiving loot events and costs. We could add something to DKPmon/Bidder (the loot mods we use) to send HC a message as loot is awarded. We like the UI and overall tracking HC provides.
If any of this has merit, I'm happy to write up the appropriate ticket(s).
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
I do have some chat mod stuff (prat 3.0). I turned every addon off except for headcount and I still got this problem. However, instead of 6 replies I got 3.
I did test this with only one raid in headcount, the active one. I got the same result. From what you were saying there should only be one hook per raid, right?
No biggie. I could get rid of the minimap button and put the icon on a broker display with Fubar2Broker, but that would mean installing an additional addon just to move a button. Kinda overkill. :D So your addon gets a premium position on my screen as the only minimap button left in my UI.
But anyway, I suggest taking a closer look at the many nice broker addons and displays out there. It's not just FuBar anymore.
I have a better guess why this is occurring, but will need to do some testing to fix this.
On my machine, I have one chat frame so I am experiencing none of the whisper duplication you mention:
General chat frame - whispers, says, yells, guild, raid, officer, party, etc.
This isn't a given for all users. As you mentioned, you can modify the default Blizzard UI manually or via chat mods (Prat) to have multiple chat frames. I am handling incoming whispers via the chat filter event rather than a standard event which I think is causing problems. So, if you have 6 chat frames:
1. Whisper received.
2. Filter for chatframe 1 hits (user is added to wait list, whisper is sent back).
3. Filter for chatframe 2 hits (whisper is sent back that user is already on the wait list).
4. Filter for chatframe 3 hits (whisper is sent back that user is already on the wait list).
5. Filter for chatframe 4 hits (whisper is sent back that user is already on the wait list).
6. Filter for chatframe 5 hits (whisper is sent back that user is already on the wait list).
7. Filter for chatframe 6 hits (whisper is sent back that user is already on the wait list).
I need to modify the whisper handling code so the generic whisper event handles the whisper handling (verifying the whisper and sending back the whisper response), while the filter is only used for supressing the display of local wait list whispers if configured to do so. This is what is intended, but is not occurring right now.
I'll do more investigation and try to get this fixed soon.
Cheers,
Decima
I am particularity fond of StatBlock as a broker addon. In the mean time try out MBB, Minimap Button Bag, to solve your minimap button problems. It works great but is a little rusty and in need of a new manager/write soon.
http://www.wowace.com/projects/head-count/tickets/15-manual-boss-kill-addition/
Related to the above ticket, manual raid events or "snapshots" would be great. We currently award an "on-time" bonus for people in the raid group 5 minutes before the raid is scheduled to begin. We can manually create the event on our website, but the ability to snapshot the raid at any given time and name the event would be awesome.
http://www.wowace.com/projects/head-count/tickets/17-bidding-support/
Currently we use whisperbid for our bidding needs. And it works alright. Something largely similar built into headcount, but with the ability to set custom "opening bidding" messages, a minimum overbid amount, and a minimum starting bid would be nice.
With the waitlist, I would like to see the ability to have members on the waitlist be awarded the hourly value, boss kill value, or both. I haven't gotten a chance to test it very much, but I didn't see an option related to that.
A few other waitlist features I'd like to see are...
-Automatic purging
If someone on the waitlist goes offline for more then time period they are automatically removed from the waitlist.
-"afk checks"
The ability to send whispers to every person on the waitlist along the lines of, "Are you there?". If they don't reply with, "yes" (or somesuch) they are removed from the waitlist.
I have a question and a feature suggestion for you, regarding the waitlist feature:
Question:
Currently, when someone joins manually the waiting list, he has immediately the End Time being set as the Start time, and the Wait list time under "Time Information" in the Member information is stuck on 00:00:00. If a member currently in waitlist is invited, the "End Time" disappear, the Start Time remains the one when he joined the waiting list, and on the raid end the total time displays only the amount of time he's actually been in the active raid (and not the one he was also in waitlist) . Is the time tracking for waitlist "spots" not fully implemented yet, or am I doing something wrong? I tried with both disabling and enabling the waitlisttime function in /headcount datetime timetotals, but the result is the same.
Suggestion:
it would be nice, as another option for the guys in wait list, to have something like a "wl contact" option, so that they can whisper in example the name of one of the alt characters they will be found on, or something like Ventrilo, or IRC. This would actually allow the raid leaders to know where to contact the guy if he's needed without forcing someone in wait list to necessarily stay logged on their main character.
Of course the "contact" method should be also displayed somewhere, could be in example in brackets when the wait list is listed.
Should the stuff I wrote be confusing, I am sorry, here's a simple example of what I mean:
- Wally enter wait list with "wl add"
- After a while Wally decide to watch a movie, but he will be available for raid and can be called on Ventrilo should he be needed.
- Wally whispers "wl contact Ventrilo"
- After a while the raid leaders need a replacement for a raider, the waitlist is listed and the string would show something like: [Headcount] Wait List: Bob, Wally (contact - Ventrilo), Rob
+1
Eventually as "wl add <note>"
I am trying to integrate the wait list functionality into my DKP application. I do this by parsing the XML, but I am having difficulty understandin quite how its meant to work.
So for example, here is the relevent XML snippet from someone who joined the wait list at 18:47, then the raid at 19:52 to 22:00.
Now I can work this out in my code, but I wonder if its meant to be like this or is bugged? So can you confirm/explain please:
Like I say I can work all this out but it seems like this or probably not as intended so I'd appreciate a clarification before I fix my code. Can send you my saved vars if it helps?
Thanks in advance.
I wouldn't touch that just yet. :)
I still need to integrate some info on the wait list into some of the export strings (wait list players and the time they joined). I'll see if I can add this soon. Durations can only be determined for users who are actually in the raid group.
If some custom logic is needed to determine how long someone was on the wait list, I would do the following:
1. Determine the wait list join time for a user.
2. Determine the end time for the raid.
3. Determine the time difference to determine how long they were waitlisted for.
Yea, the events structure would have to be modified to allow manual snapshots to occur. I don't have a timetable for this right now.
There is a ticket open for bidding support, but that seems more useful for a standalone mod. I know integration would be nice, but it's a low priority at this time.
There is another open ticket which will be addressed soon (next release) so users can define who automatically is given credit for a boss kill. Currently, only members in raid list groups are given credit, but the modification will allow the user to define which groups of players are automatically given credit. This would allow standby players to get some credit for attending a boss kill.
Automatic purging is not possible since there is no simple, consistent and generic method to determine if a player goes offline if they are outside of the raid group.
I agree with the use of making a wait list AFK check. I'd like to do this eventually.
Feel free to add feature requests as tickets:
http://www.wowace.com/projects/head-count/tickets/
The start and end time is the same because there's no simple way to determine the start and end times for a raid member if they are not in the raid itself. The only things that the addon can be aware of in terms of the raid is when the player joins the wait list (and in turn the raid). I guess a workaround to determine total wait list time would be doing a difference between when the raid ends and when the player joined the wait list via whisper.
I'll see what I can do about allowing the user to define a short note or contact name when they add themselves.
wl contact "some string"
Where some string could be:
a phone number
alternative vent info
alt characters
afk time ranges
anything else handy
My guild really doesn't give a damn what you do, no need to punish people for not playing, so if we can find you in a timely manor is all that matters. This would be perfect for us.
I think this makes the AFK suggestion pointless.
Lastly, in response to the bidding support comment:
I am currently looking for a generic bidding/loot request system. We use loot council, so we are just looking to see if anyone has a functional system right now, or if we have to build it. See my post here if you have input/interest.
Yes, or alternatively the difference between when the player joined the wait list and when he left it still via whisper.
"i have several stuff in mind, however i dont know how much they are implementable. Let me begin.
1) It would be better if we could see the long term activity of a player, when we click on his/her name in the list(At the moment, it shows how long that person was in this current raid which i personally dont find very useful but it is not so bad either). Instead of showing data like "Name, Guild, Level, Gender, Race" which has no use for tracking the activity, you can add a string like RRRMRRRWRM. This string is for last 10 raids (you can do even more raids in this format), R= Joined to Raid, M= Missed Raid, W=Was in waitlist. you can also add other stuff for replaced or whatever. But this can help a guild leader to see how active that person is with one click on the name of the person. I admit this string is a simple idea, if you have better idea which shows activity better and simple, you can implement that as well.
2) It would be very good to have synchronization between the class leaders/officers/gm who are all using this addon. So that if any of these people gets "wl add" whisper for being added to wait list, it will update waiting list on all officers team's addons.
3) Binding names of the alts with a main character would also be very useful. because some people would like to join waiting list with their alt chars. "
Just a little request for the output:
My guild is using some short of mainspec, offspec, trash, DE and bank loot rules.
Means your choose your spec (ret pala for example), and if a ret pala item drops, you and every other Ret pala + Other people that can use that item for their main spec can roll. If you get something for your mainspec, you cant roll on another main spec item until everyone else have got one or pass on it.
Pretty much the same for offspec. Trash is for everyone, DE and Bank is pretty clear ;)
Now people got short memory, and quickly forget if they got anything during the raid week already.
Plan was to use a addon to count who got what, and put it on our forums.
We tried NRT and headcount so far. NRT have the + that it shows the notes you typed in for a item, but it isnt really the best for it, as it have notes for every item, instead of a item + player that got it. Means if "Gloves of pwnage" drops, and i get is as mainspec and type it into NRT, and someone else get the same item as offspec, it whould say for both mainspec or offspec, whatever i typed in last.
Headcount dosent show notes at all in the output, and thats the only problem with it.
So i wonder, seppyk, can you please just add a small option to allow notes showed for the PHPBB export? Thats pretty much all we need.
Whould be even nice to have loot shorted by player, so everyone can see right away what items someone got.
Thanks :)
The sync feature would also provide some redundancy for the hard crash situation also discussed earlier when an entire loot log is lost. Reloading the UI periodically is possible but other mods such as our DKP tools may not recover as well as HC is currently.
Another consideration would be to provide an API for receiving loot events and costs. We could add something to DKPmon/Bidder (the loot mods we use) to send HC a message as loot is awarded. We like the UI and overall tracking HC provides.
If any of this has merit, I'm happy to write up the appropriate ticket(s).