DPS is a broken measure for very short time spans. It really isn't even intended to work for 1.5 seconds and it's a weak and undesirable measure for long time spans.
If I rewrote a damage meter and the culture of wow wasn't yet obsessed about DPS I would simply write one without any DPS at all, and purely promote total damage per boss fight. But sadly that train has left the station many years ago.
In short I won't be touching the DPS formula unless some drastic change in the game mechanics require it.
Great that's indeed fixable. I committed an alpha that treats all absorbs that are not overheals as effective healing. Let me know if it works as intended. Thanks.
In the changelog for r1192, though, is the following: "Absorbed heals not reported as overheals will not count towards effective healing...". Is it actually that or was the log worded improperly?
I had to remove recount since I noticed via Broker CPU addon it reached up to 10% CPU Usage during LFR fights (test runs). This was on a 8 x virtual,4 x core relatively new processor. Is it possible to reduce its CPU usage?
I still suspect the API of Blizzard bugs occasionally (e.g. it was giving CPU usage on RaidBufStatus addon occasionally which is supposed to be turned off in fights) so it might not be the responsibility of some addons.
You shouldn't leave CPU measurement addons running during fights. If one is measuring, everything results in by far more CPU usage. Do you have performance problems without running a measurement addon?
Also, you shouldn't trust these addons 100%. Recount needs to call an huge amout of functions during a fight (x functions for each combat log line) and these addons tend to show more CPU usage than there really is for many function calls.
This was on a 8 x virtual,4 x core relatively new processor. Is it possible to reduce its CPU usage?
On a sidenote... WoW isn't optimized to use more than two cores. While it does use more if told to, it does not benefit enough from those to make a notable difference (besides that it doesn't run on the same core as the OS).
So, I have a question about recount and its ability to track the drains from Soul Drinker. I can see the healing done by it via the Drain Life. Im sure that it is a 1 to 1 dmg to healing so I know it is doing dmg. However, I dont see that on my Damage Done section at all.
The same thing was happening with Gurthalak, Voice of the Deeps. The Tentacle would show it's own DPS meter, however, I never seen it as part of my DPS.
Maw of the Dragonlord shows it's healing done on the meters btw.
You shouldn't leave CPU measurement addons running during fights. If one is measuring, everything results in by far more CPU usage. Do you have performance problems without running a measurement addon?
Also, you shouldn't trust these addons 100%. Recount needs to call an huge amout of functions during a fight (x functions for each combat log line) and these addons tend to show more CPU usage than there really is for many function calls.
I do not trust the API of Blizzard to be honest either, besides, it's not accomodating to regular addons either. However, since that oddon does not show much load from other addons I'm willing to trust there is at least *some* related load from recount.
I did see a noticeable increase in FPS with it off.
This is in Ultraxion which is notorious to give FPS drops on 25man, at least in LFR (10man guild).
At first I thought it was the projected textures overlapping at the spot peoplle stack but after this I suspected to be a very spammy log.
The problem at Ultraxion is not intrinsically with Recount but the way the encounter loads some systems. If you have a choked system any addon that has to do substantial computation will degrade your performance. Blizzard has already hot-patched Ultraxion to address some of this. And that is the place where this needs to be fixed. An addon can do nothing when it faces an already choked setup.
Incidentally Recount has gone through extensive optimization work over the years. It's unlikely that much time can be optimized at this point in the most critical code paths.
Incidentally Recount has gone through extensive optimization work over the years. It's unlikely that much time can be optimized at this point in the most critical code paths.
Would it help if there're options to isolate parts of its code from operating? e.g. the simple option of restricting it to only counting Damage Done, or even only Damage Done without tracking any individual spells (like those lightweight addons claim to do).
I don't see the point in making Recount act like a lightweight DPS meter when those exist. Recount is meant to be a comprehensive combat analysis solution in which you can see individual spell data if you need to dig in. To me that's precisely why multiple addons exist. People can pick the ones closest to their needs.
I would suggest you use "/recount pause" (macro it!) to pause data collection for that one encounter, and friends in raid whose system is not choked can give you numbers when you don't have your own.
And I'm sure there are a range of other creative solutions too that don't require you to wait for a reload and don't require me to spend days of my life hacking code just because Blizz borked one encounter for some systems.
No, in that case a more elegant solution is to not use the addon at all and have others use recount, with the player on a simplistic addon that only tracks total damage done of each player.
Hence my assertion that a player may not use Recount at all due to CPU usage.
Sure, whatever solution people find most fitting for their situation. I don't require that anyone use Recount. It's a free offering for those who want it.
Would we be able to somehow put the correct bossname to fights like madness of deathwing , like checking which bossunits are up and if it matches one of the ids in libbossid, use that unitname as name for the encounter?
I'm not sure I understand this correctly, but it should already use the boss name for segmentation. It may not pick the ideal boss-level entity, but it certainly should pick a present and relevant one (relevant in the sense that it indeed is a boss-level mob in the encounter).
So, I recently was trying to figure out why my hunter pet's damage stopped showing up in recount (when you hover over your char's name, it shows the details of your dmg vs. pet dmg, etc.). Well, it turns out this is only when "Current Fight" is selected. On "Overall Data" or a previous fight, it splits the dmg correctly and shows how much you and your pets each dealt. But on Current Fight, it just shows the hunter's damage.
Is this intended? If so, can you make an option to toggle this?
I'm not sure I understand this correctly, but it should already use the boss name for segmentation. It may not pick the ideal boss-level entity, but it certainly should pick a present and relevant one (relevant in the sense that it indeed is a boss-level mob in the encounter).
He probably meant Spine not Madness.
There's not fight segmentation for Spine in Recount afaik.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
If I rewrote a damage meter and the culture of wow wasn't yet obsessed about DPS I would simply write one without any DPS at all, and purely promote total damage per boss fight. But sadly that train has left the station many years ago.
In short I won't be touching the DPS formula unless some drastic change in the game mechanics require it.
In the changelog for r1192, though, is the following: "Absorbed heals not reported as overheals will not count towards effective healing...". Is it actually that or was the log worded improperly?
Sadly I don't know how to edit commit message post-hoc so I'll just have to leave it at that.
http://www.wowace.com/addons/recount/files/1524-v4-3-0c-release/ you might be able to edit the file description there as an author though.
I still suspect the API of Blizzard bugs occasionally (e.g. it was giving CPU usage on RaidBufStatus addon occasionally which is supposed to be turned off in fights) so it might not be the responsibility of some addons.
Also, you shouldn't trust these addons 100%. Recount needs to call an huge amout of functions during a fight (x functions for each combat log line) and these addons tend to show more CPU usage than there really is for many function calls.
On a sidenote... WoW isn't optimized to use more than two cores. While it does use more if told to, it does not benefit enough from those to make a notable difference (besides that it doesn't run on the same core as the OS).
The same thing was happening with Gurthalak, Voice of the Deeps. The Tentacle would show it's own DPS meter, however, I never seen it as part of my DPS.
Maw of the Dragonlord shows it's healing done on the meters btw.
I do not trust the API of Blizzard to be honest either, besides, it's not accomodating to regular addons either. However, since that oddon does not show much load from other addons I'm willing to trust there is at least *some* related load from recount.
I did see a noticeable increase in FPS with it off.
This is in Ultraxion which is notorious to give FPS drops on 25man, at least in LFR (10man guild).
At first I thought it was the projected textures overlapping at the spot peoplle stack but after this I suspected to be a very spammy log.
Incidentally Recount has gone through extensive optimization work over the years. It's unlikely that much time can be optimized at this point in the most critical code paths.
Would it help if there're options to isolate parts of its code from operating? e.g. the simple option of restricting it to only counting Damage Done, or even only Damage Done without tracking any individual spells (like those lightweight addons claim to do).
And I'm sure there are a range of other creative solutions too that don't require you to wait for a reload and don't require me to spend days of my life hacking code just because Blizz borked one encounter for some systems.
Hence my assertion that a player may not use Recount at all due to CPU usage.
Is this intended? If so, can you make an option to toggle this?
There's not fight segmentation for Spine in Recount afaik.