Authors CurseForge

Ok so I am not reading 99 pages. Any reason why my recount isn't syncing with others? its the latest version from the updater and the global data collection is on.

When soloing I show DPS for "current fight", just for learning purposes. However to do this I must reset Recount after each login to make Recount start working. Is this a bug or a feature?

That's a bug, I'll look into it.

Thanks Elsia. Another thing: When I use the DPS mode when soloing the numbers seem too low. I tried running DamageMeters in parallell which shows considerably higher values. Just doing the simple calculation mob hp divided by time to kill indicates that Recount is 20-30% too low on DPS measurements whereas DamageMeters is more exact. Perhaps there is a setting I missed or something?

Read up this thread for extensive discussion about DPS. Short summary: Compare Damage done not DPS. DPS depends on arbitrary defintion of time to use to calculate the "per second" part hence will differ between different addons/WWS.

How can there be more than one interpretation of time? Combat starts and combat ends. No?

As said, read back. It's all been detailed.

Will do.

[2008/06/01 19:52:09-1561-x1]: Recount-75628\Recount.lua:1308: Usage: UnitClass("unit")
Recount-75628\Recount.lua:1308: in function `AddCombatant'
Recount-75628\LazySync.lua:413: in function `?'
CallbackHandler-1.0\CallbackHandler-1.0.lua:146: in function <...ist\libs\CallbackHandler-1.0\CallbackHandler-1.0.lua:146>
<string>:"safecall Dispatcher[4]":4: in function <[string "safecall Dispatcher[4]"]:4>
<in C code>: ?
<string>:"safecall Dispatcher[4]":13: in function `?'
CallbackHandler-1.0\CallbackHandler-1.0.lua:91: in function `Fire'
AceComm-3.0\AceComm-3.0.lua:246: in function <...terface\AddOns\Omen\Libs\AceComm-3.0\AceComm-3.0.lua:235>

 ---

Feature request: Pull out bars from recount to be placed dynamically on screen, so i can track one person sometimes

Feature Request

When reporting, would it be possible to report to a dialog that text can be copied from? The functionality I'm thinking of is very similar to that used by addons like CT_RaidTracker for exporting to web-based DKP systems.

While I can get around it by reporting to the chat window and copying that using another addon, I have to crop the text and having it in a discrete window would allow me to have just the data I needed.

Thanks!

Marcus

@Hjalte:

That addon is poorly programmed. It will mess up not only damage meters but also SCT-like addons like for example blizz's own one etc. It really should delay it's cached UnitHealth() enough for all sources that rely on UnitHeath() at combat log event time to safely access it.

There are multiple ways of doing this, the current version of the addon just doesn't, hence breaks expected behavior i.e. that UnitHealth() at combat log event time shows the pre-event value, not the post-event value. A very clean and fast hypothetical solution would be if the addon could be last to handle combat log events in the queued addons for the event. Not sure if that's possible. A related idea is to make the change effective with the next OnUpdate. Else it really needs to delay UnitHealth() return values enough to give other addons a chance to process their respective events first.

One can specifically look for the presence of this addon and bypass this but really it should be up to this addon to do this cleanly and not mess it up for a large class of other addons. Also any number of other poorly written addons can have the same undesirable effects.

Basically as written now this addon is designed to break overhealing estimations and it shouldn't.

Also it actually doesn't properly cache health changes either, only healing or damage suffix entries are accounted for.e.g. DAMAGE_ events from damage shields are not correctly handled in the current version of that addon.

The addon will also effectively double the UNIT_HEALTH events the way it's written (if I understood correctly what he's doing). There really should be a cleaner solution to do what this addon does and one that does keep SCT/damage meters and any other addon that requires for UnitHealth to be it's standard value at combat log event time because this is current expected behavior. Then he can shorten the delay all he wants.

As a side note, the addon doesn't currently hook per best practices either, it should hook UnitHealth(unit,...) not UnitHealth(unit).

@Cus: It's on my list, but given that there are good chat window based once it doesn't really have high priority.

@skater: Have you tried realtime windows for this purpose?

Fantastic addon, just a question...

Is it possible to hide specific classes from view, for example, if I only want to see rogues damage, can I hide all other classes so just rogues show in the window (but still ofc, record data for all other classes)

Many thanks in advance

@Elsia

Zenima pointed out your post for me and when reading it I can see there are a few things in my addon I will have to look over. The intention is for it to behave exactly like expected, but one thing I overlooked was that some addons expects UnitHealth() to show the post-event value. As you posted, waiting until last handling the combat log events would be a very clean way of fixing this. I will see if I can come up with a reliable way of doing this.

Pretty bad my addon is ignoring some damage. One more thing on the list to fix.

As for the generating additional UNIT_HEALTH events it's intended and necessary for the addon to do what it's supposed to do. UNIT_HEALTH events are only generated whenever the health of a unit changes which really is the expected behavior. There really isn't any way of generating fewer UNIT_HEALTH events without slowing down the update rate of health bars and such.

Going to change how it hooks as well.

Although I have a good bit of experience with programming in general the lua language was new to me when I started out on this addon, I learned lua to make this addon after coming up with the idea. Your comments have been helpful and very much appreciated!

Thanks!

Glad to help. I think the addon is a very cool idea, and I'm sure it'll be possible to have it still maintain expected behavior at the same time.

Hello there, I am a mage and I have a bit of a problem with the way the critical % is being calculated for fireball: it also takes into consideration the fireball ticks.

52 crits out of 118 fireballs, not out of 246 :P

I'm sure there's a way to ignore the ticks when calculating the crit% :)
Thanks!

Added a suffixed (DoT) for damage over time events in the combat log. This means that e.g. Moonfire damage will show as "Moonfire" for the direct damage part and "Moonfire (DoT)" for the dot part. Unfortunately this also means that any pure dot will have a (DoT) suffix, such as "Corruption (DoT)" as there is no easy way to differentiate mixed damage from pure damage dots.

Side effect is that crit rate for direct damage will be displayed in a more meaningful way for mixed damage spells.