They weren't looking at tanks. They were looking at white damage only, and the breakdown of that white damage (that is, how much of it is hit, crit, glance, miss... etc). Hence the use of the detailed view, to isolate melee attacks only.
As to partial blocks, they are considered blocks as far as the Blizzard attack table is concerned, even though they do damage. At least that's my understanding of it. So I would think they should be included with full blocks. Of course, as you say, where would the damage done by these partial blocks go? Would it be possible to add another category that's just for partial blocks and includes the damage done? Sort of best of both worlds?
Those who did those tests were crit-capped and were seeing hits show up on Recount anyway. I guess now we know those were partial blocks. But it led many to believe that there was some hidden conversion of crits into hits. That's actually been going on since LK came out, but it hadn't mattered much until recently since the gear wasn't available to be crit-capped. Once that gear became available, people re-tested this and were able to more closely observe that phenomenon.
Hi,
may I suggest making the death log a little more readable? I'm mainly having a hard time figuring out how much HP you have after any given action, but imo it could use a complete (not that it's a huge feature, I guess) redesign. I'm thinking, rather than "copy pasted" combat log entries, there could be straight forward columns for "who inflicted this damage", "with which spell", "how much damage", and "how much HP remains".
And also, could you make the main frame's visibility stick when you've manually opened (or closed?) it when changing zones, regardless of zone settings?
@vor: Persistent Shield http://www.wowhead.com/?spell=26467 is already tracked. You linked a different ID. Can you confirm from the combat log that yours is correct and the above is wrong?
Hmm, strange, I'm fairly sure that's the correct one (using the brooch gives you a buff which causes a spell cast on others to trigger that linked spell, like val'anyr). The spell you linked is the self buff that you get when you use the trinket, causing targets to receive the actual absorb effect I linked. The only reason I posted is because I was using it and GuessedAbsorbs wasn't showing any absorbs for it.
I'll check the combatlog in game and check it for sure and report back.
They weren't looking at tanks. They were looking at white damage only, and the breakdown of that white damage (that is, how much of it is hit, crit, glance, miss... etc). Hence the use of the detailed view, to isolate melee attacks only.
As to partial blocks, they are considered blocks as far as the Blizzard attack table is concerned, even though they do damage. At least that's my understanding of it. So I would think they should be included with full blocks. Of course, as you say, where would the damage done by these partial blocks go? Would it be possible to add another category that's just for partial blocks and includes the damage done? Sort of best of both worlds?
Those who did those tests were crit-capped and were seeing hits show up on Recount anyway. I guess now we know those were partial blocks. But it led many to believe that there was some hidden conversion of crits into hits. That's actually been going on since LK came out, but it hadn't mattered much until recently since the gear wasn't available to be crit-capped. Once that gear became available, people re-tested this and were able to more closely observe that phenomenon.
I see, well I am looking at this from a different angle. Recount reports what the combat log reports, not what can be measured knowing or having guessed certain mechanisms. The attack table is not a transparent mechanism, and may be subject to change etc.
Recount actually accurately reports things as the combat log reports it. Partial blocks are hits with a partially blocked component to it. That is a different beast completely from a miss to which a full block belongs. In the same spirit, partial absorbs and partial resists are also reported as hits. They are all partially mitigated hits. But because apparently (is this proven?) they do not enter into how the attack table is calculated they do not enter this discussion. But I think it's a good example to highlight why it isn't so simple to just say that this is actually a flaw in Recount.
Currently Recount keeps this relationship transparent from the combat log and does not assume any attack table whatsoever. I.e. it is a faithful representation of the semantics of the combat log. The advantage of this is that this will remain robust against any redesign of internal mechanisms. The disadvantage is that if people look to unearth internal mechanisms they may unearth a mismatch between how it's presented in the combat log and how it works internally.
Basically what people have discovered is that hits with partial block component are treated as blocks from an attack table perspective. That's fine. It could have also turned out the other way and there is no way to tell from the combat log!
In either case it doesn't mean that it's a miss-type (block) from a combat log perspective at all right now! I'm inclined to think that people who understand the nuance of these mechanisms understand that there are two representations here and that combat log analysis tools might want to opt to stay agnostic to internal mechanisms in favor of always portraying the combat log behavior faithfully.
I'm two minds about this. On the one hand I can see people wanting to do these kind of measurements. I could disambiguate partial mitigation effects (something like "hit (partial block)", "hit (partial absorb)" and "hit (partial resist)"). There are some complications about this that I don't have to go into right now.
On the other hand I do not like this because offensive stats are not the right place to leak in defensive mechanisms. The current separation of offense and defense is clean. People would have to check the defensive stats of their target to learn of the partial mitigation effects that contributed to what they want to measure elsewhere. I also don't like that it will increase the data accumulation size when most people simple do not need this nuance, and even people who do care about this nuance mostly want it in specific settings (when checking theories of mechanisms).
Maybe the right thing to do is offer a module for people who want to do attack table measurements and don't want to switch between defensive and offensive stats to do it. Or I'll just add it, haven't made my mind yet. I can also see just leaving things as they are. I don't really agree that there is a substantial problem here. Basically people assume that Recount should encode the attack table and I kind of disagree for very similar reasons why I don't want to encode boss-encounter specific stuff either. It is somewhat beyond the scope of a combat log analysis tool and will limit its generality when mechanisms are changed around.
@Lombra: I agree a rework of the death log would be nice. The way I look at it though is that it's nice enough and that I'd have to have substantial time on my hands to make it better and no more important thing to fix first. Given that I think it's unlikely I'll touch the death log in the near future and if I do it will mostly be to reduce data accumulation size.
@Vorvonox: Thanks, let me know which one shows in the combat log and I'll be happy to fix the ID if I got the wrong one.
I don't think anyone wants Recount to change. Quite the contrary. By reporting what the Combat Log says, it highlights discrepancies between what we know and expect and what actually happens. This is what happened here.
The reason there's a link between Recount and the attack table is that there are only so many possible outcomes for a melee attack. And that's how they're labeled in Recount: hit, miss, crit, glancing hit, parry, dodge, block. What else could you call them? That's their name. The attack table and Recount are linked by definition.
I don't think offense and defense are cleanly separated, otherwise there wouldn't be partial xxxx mechanics in WoW. Heck, Resilience is a perfect example of a defensive mechanic affecting offense.
Anyway, not trying to argue here. It was just a suggestion to add partial stuff. It's also a testament to Recount that people rely on it for verifying known theories. If you think it can be a module, then that's cool. I think people were trying to let you know about it, more than "asking for a fix". I suggested something because you brought up how they were handled. Either way, I'll know to test from behind dummies in the future. :P (though that's not necessarily possible, which is why this was done from the front)
In the latest alpha, partial blocks in offensive details are annotated. This means that hits which had part of the damage blocked will appear as "Hit (Blocked)" in the details.
Also the Scarab brooch proc has been added to the absorbed effects in RecountGuessedAbsorbs.
In the latest alpha, partial blocks in offensive details are annotated. This means that hits which had part of the damage blocked will appear as "Hit (Blocked)" in the details.
Also the Scarab brooch proc has been added to the absorbed effects in RecountGuessedAbsorbs.
Is there any way to reduce the font size of the "Damage Done"/"Healing Done" text, whether it be in the options (Can't find anything here) or editing the lua file. Thanks
I was wondering if anyone else was experiencing this problem I've been having. I couldn't find much in a search so I decided to post up on this thread. I've been having this problem for quite some time. Many months, at least. The recount window will randomly clear itself empty (the data is all still there) and make me have to reselect current fight (or whatever it's on) to get the bars to show back up again.
What also will happen sometimes when I'd go to reselect current fight is when I have the fight selection list up, before I could click on any of them, the list would close. I would have to fight with recount for a little to try and select the fight quickly enough so the list wouldn't vanish on me.
This has been happening through multiple reinstalls/patches of recount. Is this a known issue or something only I am experiencing? And again, it doesn't happen all the time. It seems to have been happening less recently, but that could be due to the fact that I'm so used to it now.
Setting Recount to only store boss sections doesn't work for Valithria Dreamwalker probably because she's a friendly. Not sure if there is a way for you to fix this or not.
Might be worth adding the GUID's of some of the adds for this boss fight so that it's broken into sections?
I was wondering if anyone else was experiencing this problem I've been having. I couldn't find much in a search so I decided to post up on this thread. I've been having this problem for quite some time. Many months, at least. The recount window will randomly clear itself empty (the data is all still there) and make me have to reselect current fight (or whatever it's on) to get the bars to show back up again.
[36789] = true, -- Valithria Dreamwalker
[37950] = true, -- Valithria Dreamwalker (Phased)
are the boss, so that isnt missing.
Elsia, do we need to add the adds in there or will be we able to solve it otherwise? Maybe just an outdated libbossid in her?
Haven't reported it before now, because I haven't really noticed a specific trend to it yet to try and reproduce it intentionally. My only real suspicion at the moment is possibly something firing off right after or right as you leave combat, or a boss death is recognized that may be causing it to behave this way. Like, a brief confusion internally about when/where the segment ends, if that makes sense?
As the other poster had mentioned, the window will clear, even though it's still set to "Current Fight", yet reselecting "Current Fight" from the menu will redisplay the last fight's data again. Seems almost like something's happening right at the end of combat to make Recount think it needs to start a new segment, so it clears the window in preparation, but it all gets stored with the prior segment.
[36789] = true, -- Valithria Dreamwalker
[37950] = true, -- Valithria Dreamwalker (Phased)
are the boss, so that isnt missing.
Elsia, do we need to add the adds in there or will be we able to solve it otherwise? Maybe just an outdated libbossid in her?
The boss is listed in my libbossid it's just not separating the tries into sections probably because you never actually damage the boss since it's friendly.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
As to partial blocks, they are considered blocks as far as the Blizzard attack table is concerned, even though they do damage. At least that's my understanding of it. So I would think they should be included with full blocks. Of course, as you say, where would the damage done by these partial blocks go? Would it be possible to add another category that's just for partial blocks and includes the damage done? Sort of best of both worlds?
Those who did those tests were crit-capped and were seeing hits show up on Recount anyway. I guess now we know those were partial blocks. But it led many to believe that there was some hidden conversion of crits into hits. That's actually been going on since LK came out, but it hadn't mattered much until recently since the gear wasn't available to be crit-capped. Once that gear became available, people re-tested this and were able to more closely observe that phenomenon.
may I suggest making the death log a little more readable? I'm mainly having a hard time figuring out how much HP you have after any given action, but imo it could use a complete (not that it's a huge feature, I guess) redesign. I'm thinking, rather than "copy pasted" combat log entries, there could be straight forward columns for "who inflicted this damage", "with which spell", "how much damage", and "how much HP remains".
And also, could you make the main frame's visibility stick when you've manually opened (or closed?) it when changing zones, regardless of zone settings?
Thanks
Hmm, strange, I'm fairly sure that's the correct one (using the brooch gives you a buff which causes a spell cast on others to trigger that linked spell, like val'anyr). The spell you linked is the self buff that you get when you use the trinket, causing targets to receive the actual absorb effect I linked. The only reason I posted is because I was using it and GuessedAbsorbs wasn't showing any absorbs for it.
I'll check the combatlog in game and check it for sure and report back.
I see, well I am looking at this from a different angle. Recount reports what the combat log reports, not what can be measured knowing or having guessed certain mechanisms. The attack table is not a transparent mechanism, and may be subject to change etc.
Recount actually accurately reports things as the combat log reports it. Partial blocks are hits with a partially blocked component to it. That is a different beast completely from a miss to which a full block belongs. In the same spirit, partial absorbs and partial resists are also reported as hits. They are all partially mitigated hits. But because apparently (is this proven?) they do not enter into how the attack table is calculated they do not enter this discussion. But I think it's a good example to highlight why it isn't so simple to just say that this is actually a flaw in Recount.
Currently Recount keeps this relationship transparent from the combat log and does not assume any attack table whatsoever. I.e. it is a faithful representation of the semantics of the combat log. The advantage of this is that this will remain robust against any redesign of internal mechanisms. The disadvantage is that if people look to unearth internal mechanisms they may unearth a mismatch between how it's presented in the combat log and how it works internally.
Basically what people have discovered is that hits with partial block component are treated as blocks from an attack table perspective. That's fine. It could have also turned out the other way and there is no way to tell from the combat log!
In either case it doesn't mean that it's a miss-type (block) from a combat log perspective at all right now! I'm inclined to think that people who understand the nuance of these mechanisms understand that there are two representations here and that combat log analysis tools might want to opt to stay agnostic to internal mechanisms in favor of always portraying the combat log behavior faithfully.
I'm two minds about this. On the one hand I can see people wanting to do these kind of measurements. I could disambiguate partial mitigation effects (something like "hit (partial block)", "hit (partial absorb)" and "hit (partial resist)"). There are some complications about this that I don't have to go into right now.
On the other hand I do not like this because offensive stats are not the right place to leak in defensive mechanisms. The current separation of offense and defense is clean. People would have to check the defensive stats of their target to learn of the partial mitigation effects that contributed to what they want to measure elsewhere. I also don't like that it will increase the data accumulation size when most people simple do not need this nuance, and even people who do care about this nuance mostly want it in specific settings (when checking theories of mechanisms).
Maybe the right thing to do is offer a module for people who want to do attack table measurements and don't want to switch between defensive and offensive stats to do it. Or I'll just add it, haven't made my mind yet. I can also see just leaving things as they are. I don't really agree that there is a substantial problem here. Basically people assume that Recount should encode the attack table and I kind of disagree for very similar reasons why I don't want to encode boss-encounter specific stuff either. It is somewhat beyond the scope of a combat log analysis tool and will limit its generality when mechanisms are changed around.
@Lombra: I agree a rework of the death log would be nice. The way I look at it though is that it's nice enough and that I'd have to have substantial time on my hands to make it better and no more important thing to fix first. Given that I think it's unlikely I'll touch the death log in the near future and if I do it will mostly be to reduce data accumulation size.
@Vorvonox: Thanks, let me know which one shows in the combat log and I'll be happy to fix the ID if I got the wrong one.
The reason there's a link between Recount and the attack table is that there are only so many possible outcomes for a melee attack. And that's how they're labeled in Recount: hit, miss, crit, glancing hit, parry, dodge, block. What else could you call them? That's their name. The attack table and Recount are linked by definition.
I don't think offense and defense are cleanly separated, otherwise there wouldn't be partial xxxx mechanics in WoW. Heck, Resilience is a perfect example of a defensive mechanic affecting offense.
Anyway, not trying to argue here. It was just a suggestion to add partial stuff. It's also a testament to Recount that people rely on it for verifying known theories. If you think it can be a module, then that's cool. I think people were trying to let you know about it, more than "asking for a fix". I suggested something because you brought up how they were handled. Either way, I'll know to test from behind dummies in the future. :P (though that's not necessarily possible, which is why this was done from the front)
Persistent shield id 26470 caused absorption
Also the Scarab brooch proc has been added to the absorbed effects in RecountGuessedAbsorbs.
Can we get a heal+absorb combined tab?
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumhttp://wow.curse.com/downloads/wow-addons/details/recounthealandabsorbs.aspx
Thanks Elsia.
oh cool thanks. 3 addons to get heal+absorb Oo
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWhat also will happen sometimes when I'd go to reselect current fight is when I have the fight selection list up, before I could click on any of them, the list would close. I would have to fight with recount for a little to try and select the fight quickly enough so the list wouldn't vanish on me.
This has been happening through multiple reinstalls/patches of recount. Is this a known issue or something only I am experiencing? And again, it doesn't happen all the time. It seems to have been happening less recently, but that could be due to the fact that I'm so used to it now.
Might be worth adding the GUID's of some of the adds for this boss fight so that it's broken into sections?
I've seen this on a number of occasions as well.
@Mikari: I don't raid, so I'll need people to send in the GUIDs of bosses that are missing from LibBossIDs.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium[37950] = true, -- Valithria Dreamwalker (Phased)
are the boss, so that isnt missing.
Elsia, do we need to add the adds in there or will be we able to solve it otherwise? Maybe just an outdated libbossid in her?
As the other poster had mentioned, the window will clear, even though it's still set to "Current Fight", yet reselecting "Current Fight" from the menu will redisplay the last fight's data again. Seems almost like something's happening right at the end of combat to make Recount think it needs to start a new segment, so it clears the window in preparation, but it all gets stored with the prior segment.
The boss is listed in my libbossid it's just not separating the tries into sections probably because you never actually damage the boss since it's friendly.