I didn't see anything under Damage Taken; both the magnifying glass and back/forward arrows did nothing. But assuming it is supposed to display, and is displayed in the same style as critical hits, I'm more interested in, say, the % of all attacks dodged, rather than the separate % of each type of attack dodged.
Hi Elsia.
I just took a look in the PoM tracking in Recount, and i think it forget a lot of event.
According to this:
-- Sequence is:
-- A casts Prayer of Mending
-- B gains Prayer of Mending
-- B's Prayer of mending heals B for x
-- B casts Prayer of Mending
-- B loses Prayer of Mending
-- C gains Prayer of mending
--local POM_CastQueue={}
--local POM_AboutToCast={}
-- Elsia: Additions: Using cast success to contain original caster
-- Added 30 second buff length to streamline heuristics. Less false positives
-- Added 5 buff stack size to tracking, again less false positives
you are tracking pom only when the aura is applied.
But, here is the funny part, PoM often occurs *without* the aura_applied_event, mostly when the jump happens when the target it taking damage, then it jump again directly.
anyway the real sequence is
-- A(priest) casts Prayer of Mending (cast_success)
-- B gains Prayer of Mending
-- B's Prayer of mending heals B for x
-- B casts Prayer of Mending
-- B loses Prayer of Mending
-- C gains Prayer of mending
[...]
or
-- A(priest) casts Prayer of Mending (cast_success)
-- B gains Prayer of Mending
-- B's Prayer of mending heals B for x
-- B loses Prayer of Mending
-- C's Prayer of mending heals C for x (<- directheal (!!))
-- D gains Prayer of Mending
-- D's Prayer of mending heals D for x
-- D loses Prayer of Mending
[...]
I dont know how accurate you wish to push recount, but i think you may be interested by that.
Thanks for this. Actually Recount actually already does what you ask for. I just hadn't removed Cryect's original comments to the code of the pre-2.4 way of handling PoM. Same goes for lifebloom and earthshield, those too have been rewritten to match the post 2.4 situation.
Is there any way to display the order in which people die (a flat death list) as part of this mod? I know based on the breakdowns/graphs you can do for individual players it does track when someone died, but I only see the display that shows how many deaths someone has.
If there isn't, is this feature under consideration?
Sorry if this is a repeat question, I've been browsing forums for 3 hours now looking for a flat death list, not going through another 109 pages of replies.
Got a purely cosmetic feature request for ya, Elsia.
Would it be too much pain to ask for a way to hide the top buttons and/or category text until hovering the mouse over the Recount window(s)?
I can set up kgpanels for any other visual effect I want, but those buttons are really kinda obnoxious to have visible full-time in an otherwise clean UI.
...With that said and rolling restarts happening (Boulderfist hates those, always down for over an hour), methinks I'm gonna look into hacking up a temporary solution for my beloved meter. ^_^
I've recently started using Recount, and I'm amazed at the amount of data it collects. It's the staple meter of my guild, and I'd like to thank you for doing a great job with it!
I do have a question, however: Is there a way it must be set up in order for it to sync properly? I believe I have syncing on, but my readings are always significantly different from those of my fellow raid members. I know damage meters are never perfectly identical for different players, but sometimes the gulf between our results is quite large.
Is this just the nature of the beast, or are we doing something wrong with the add-on?
When someone posts a meter thats very different from yours, does the gap widen as raid time progresses? I ask because Recount will store data in segments covering the last couple of fights, and if you're looking at the overall data while they post a fight specific...
You can tell what segment you're looking at based on the little page icon between the cog/options and the delete data buttons.
You can tell what segment is being posted by the top line of the announcement, the line will read "Recount - <stat in question> for <data segment>".
I've checked that syncing is turned on... is there any inherent reason for Recount not to be syncing with other raid members (who have Recount also) in the Kalecgos fight? I know that when we're split up between the dragon and demon areas we don't see each other in the combat logs, but I thought Recount's syncing would take care of this...
When someone posts a meter thats very different from yours, does the gap widen as raid time progresses? I ask because Recount will store data in segments covering the last couple of fights, and if you're looking at the overall data while they post a fight specific...
Heya, thanks for the reply!
It's almost always significantly different for individual fights. Actually, things seem to normalize a bit when looking at entire-raid-length totals. For a given fight, the numbers for the top four or five DPS will be quite different on seemingly every member's meter.
Recount only syncs combatants who also have recount and it does so only after combat ends. Also there is a known issue if you do not see your own contribution in the combat log (DoTs, HoTs).
Recount decides if it needs to sync or not depending on whether it can see units or not, because the new combat log range are as far as you can see units. I do know that there are pathological situations where this test can fail.
Really the cleanest fix for this would be if blizzard would just send combat events to everybody in raid, irregardless of visibility. Clean ways to get around them not doing that is very expensive. My current philosophy for sync code in recount is that playability in heavy load situations like 25-man raiding trumps sync accuracy.
I've whipped up a bit of a hack to hide the Recount main window buttons until they are moused over. They appear individually, but with a little creative kgPaneling they're just as easy to get to and use as before.
Here's the addon that does it. It just does a little texture voodoo. Hope it's useful to someone.
Note: The commented areas were my first attempt at showing/hiding them all at once. Unfortunately it didn't work as planned due to using Show() and Hide() instead of something more graceful. I know there's a better way of doing it, I just didn't want to figure it out after 40+ hours awake. =P
Recount only syncs combatants who also have recount and it does so only after combat ends. Also there is a known issue if you do not see your own contribution in the combat log (DoTs, HoTs).
Recount decides if it needs to sync or not depending on whether it can see units or not, because the new combat log range are as far as you can see units. I do know that there are pathological situations where this test can fail.
Really the cleanest fix for this would be if blizzard would just send combat events to everybody in raid, irregardless of visibility. Clean ways to get around them not doing that is very expensive. My current philosophy for sync code in recount is that playability in heavy load situations like 25-man raiding trumps sync accuracy.
*confused* So, are you saying for the Kalecgos fight, Recount should sync at the end of combat with other raid members (assuming they also have Recount installed)? Will it sync if they are dead or ghosts? Is the "visibility" factor determined at start of combat or end?
Visibility is determined all the time. If at any time visibility is broken there will be a sync at the end of the raid. If will sync with you if you are dead or a ghost too. It sends out yourself, your pet and boss data, nothing else. It never syncs any data related to combatants that do not have recount, because they cannot be sending their own data of course.
Note that on Kalecgos it is very hard to determine the correct combat log, because to do that you'd have to make sure you have 100% coverage of both realms and faithfully remove any duplication. That is either a hard, or a very expensive task. Given that Kalecgos is the only fight in current raiding content that has this kind of raid separation, it's hardly worth the effort to do this.
So, after an automatic, post-combat sync, should our meters be showing the same readings (for that fight)? Because that doesn't seem to be the case for my guild...
Is it perhaps a version conflict? Should we go back and make sure we're all using the exact same version of Recount?
Older versions of Recount had lazysync bugs that got fixed later, but even now there is no guarantee that the readings will be the same. If it detects that another combatant saw more of ones damage than oneself it doesn't sync because the inherent assumption of the sync model has failed hence show discrepancies even between Recount users.
In any case having Recount users with out of date versions certainly has a good chance of making things worse.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
is that what you have looked at? It has hit/miss/parry/block etc etc percentages.
I just took a look in the PoM tracking in Recount, and i think it forget a lot of event.
According to this:
you are tracking pom only when the aura is applied.
But, here is the funny part, PoM often occurs *without* the aura_applied_event, mostly when the jump happens when the target it taking damage, then it jump again directly.
anyway the real sequence is
-- A(priest) casts Prayer of Mending (cast_success)
-- B gains Prayer of Mending
-- B's Prayer of mending heals B for x
-- B casts Prayer of Mending
-- B loses Prayer of Mending
-- C gains Prayer of mending
[...]
or
-- A(priest) casts Prayer of Mending (cast_success)
-- B gains Prayer of Mending
-- B's Prayer of mending heals B for x
-- B loses Prayer of Mending
-- C's Prayer of mending heals C for x (<- directheal (!!))
-- D gains Prayer of Mending
-- D's Prayer of mending heals D for x
-- D loses Prayer of Mending
[...]
I dont know how accurate you wish to push recount, but i think you may be interested by that.
If there isn't, is this feature under consideration?
Sorry if this is a repeat question, I've been browsing forums for 3 hours now looking for a flat death list, not going through another 109 pages of replies.
Would it be too much pain to ask for a way to hide the top buttons and/or category text until hovering the mouse over the Recount window(s)?
I can set up kgpanels for any other visual effect I want, but those buttons are really kinda obnoxious to have visible full-time in an otherwise clean UI.
...With that said and rolling restarts happening (Boulderfist hates those, always down for over an hour), methinks I'm gonna look into hacking up a temporary solution for my beloved meter. ^_^
I've recently started using Recount, and I'm amazed at the amount of data it collects. It's the staple meter of my guild, and I'd like to thank you for doing a great job with it!
I do have a question, however: Is there a way it must be set up in order for it to sync properly? I believe I have syncing on, but my readings are always significantly different from those of my fellow raid members. I know damage meters are never perfectly identical for different players, but sometimes the gulf between our results is quite large.
Is this just the nature of the beast, or are we doing something wrong with the add-on?
Thanks!
When someone posts a meter thats very different from yours, does the gap widen as raid time progresses? I ask because Recount will store data in segments covering the last couple of fights, and if you're looking at the overall data while they post a fight specific...
You can tell what segment you're looking at based on the little page icon between the cog/options and the delete data buttons.
You can tell what segment is being posted by the top line of the announcement, the line will read "Recount - <stat in question> for <data segment>".
Edited for clarity... I think.
-Pach
It's almost always significantly different for individual fights. Actually, things seem to normalize a bit when looking at entire-raid-length totals. For a given fight, the numbers for the top four or five DPS will be quite different on seemingly every member's meter.
I hope that's the info you were looking for!
Recount decides if it needs to sync or not depending on whether it can see units or not, because the new combat log range are as far as you can see units. I do know that there are pathological situations where this test can fail.
Really the cleanest fix for this would be if blizzard would just send combat events to everybody in raid, irregardless of visibility. Clean ways to get around them not doing that is very expensive. My current philosophy for sync code in recount is that playability in heavy load situations like 25-man raiding trumps sync accuracy.
Here's the addon that does it. It just does a little texture voodoo. Hope it's useful to someone.
Note: The commented areas were my first attempt at showing/hiding them all at once. Unfortunately it didn't work as planned due to using Show() and Hide() instead of something more graceful. I know there's a better way of doing it, I just didn't want to figure it out after 40+ hours awake. =P
*confused* So, are you saying for the Kalecgos fight, Recount should sync at the end of combat with other raid members (assuming they also have Recount installed)? Will it sync if they are dead or ghosts? Is the "visibility" factor determined at start of combat or end?
Note that on Kalecgos it is very hard to determine the correct combat log, because to do that you'd have to make sure you have 100% coverage of both realms and faithfully remove any duplication. That is either a hard, or a very expensive task. Given that Kalecgos is the only fight in current raiding content that has this kind of raid separation, it's hardly worth the effort to do this.
A while back I wrote a more technical thread discussing sync strategies http://www.wowace.com/forums/index.php?topic=12991.0.
Is it perhaps a version conflict? Should we go back and make sure we're all using the exact same version of Recount?
In any case having Recount users with out of date versions certainly has a good chance of making things worse.