Pre 2.4 the hunter pet info like % of damage done and top 3 mobs attacked did show on a mouseover of the hunter's name when the data was merged---it only does it now on very rare occasions.It shows the pet's name but says it did 0% of the damage. And the past fight data still hardly ever shows--only if you completely restart Wow does it ever work and not always even then
Hello, I installed Recount with the coming of patch 2.4 and so far it's a great addon.
However I've had also other reasons to install it. One of them was the ending functionality of
fu_DPS which one by far my most favourite addon.
With Recount I noticed the option to have RecountFU aswell, which allows displaying of
"last fight" dps. Perfect! On the other hand, it does not work. In the RecountFU tooltip
I notice that only session is both recorded and displayed.
Is there a way to have it display "last fight"?
Last night when I was playing with Recount a bit, I somehow managed to open realtime DPS graph,
I think that was pretty neat calculations, but I can't find it now. Now I just wish I could see
realtime dps calculated in RecountFU "fubar text".
I apologize if this has been answered in one way or another before. I'll keep waiting.
Alright. Here is what happened. There was a bug that when the main window was closed it would stop all recurring timers. This also unintentionally stopped the tick timer that is responsible for measuring out certain things (like combat time!). That broke in combat detection. That in turn broke all parts that needed combat detection to work, like the fight segmentation. Autohide broke itself because it closed the main window hence broke combat detection.
It's fixed now, per r66820. This should address a number of issues like low DPS counts, fight segmentation, autohide mode and possibly other aspects as well.
Thanks to everybody who helped me track down this bug.
Hey Elsia, following experiences with the yellow system message "There is no player with '_____' playing." and reports from others that they'd been having the same issue (especially in BGs, but also when logging onto raids with offline people), I did some experimentation with selectively disabling addons and was able to narrow down the cause to Recount.
It occurs repeatedly in battlegrounds (generally spamming 10+ messages for various players in the BG who are not on the same realm as I am), and (although I've not personally experienced this) also sometimes in raid groups with offline members.
Can you see about taking a look into any code that might be trying to communicate with other players but not checking if they're on the same realm, or offline? Or failing that, add an option to disable Recount automatically in battlegrounds?
A recent revision(in the last month) of recount has disabled it's acceptance of shared media. I was using shared media 2.0 and I tried to update to 3.0 to see if that would fix it, but unfortunately it did not.
Are there any plans in the future to reinstate that functionality?
@Aiiane: yes this is the sync code in recount. I'll by working on this a lot now and certainly hope that this particular message will be gone very soon, thanks for reporting. EDIT: Btw, have you tried a recent version. A while back I did fix one bug that caused that kind of spam, at least for disconnected raid members.
@Quisquis: Recount always acceptedf shared media, unfortunately there was confusion with how shared media is handled itself (independent of recount). The most current approach to shared media is using LSM-3.0 and SharedMedia for the media. This is in conflict to using LSM-2.0 and SharedMedia-2.0. So if you experience difficulty with your shared media, the fix is to get SharedMedia. SharedMedia will now also register with LibSharedMedia-2.0 so the SharedMedia-2.0 file is already obsolete. To be clean addons still should update their dependencies and possibly use LSM-3.0. But all this is independent of recount: In short for Recount users: Get SharedMedia (not 2.0) as your media repository and everything should work fine.
When raiding recount now does what is "lazy" syncing. That is it does not sync at all during combat and waits for combat to end to sync. This does make it appear as if it records data after combat but this extra data are corrections due to the sync.
The advantage of this approach is that it removes all addon traffic when you need it most: During combat, while still retaining syncing. The disadvantage is that it's not yet widely used so I understand that it can look like a bug at first.
The sync code is very new though and I still look for loads of reports on its functionality. I already got a good few leads for improvements on it.