Authors CurseForge

I'll look into it.

Elsia, first, I have to say, thank you for Recount. It helps a great deal when trying to figure out what's going wrong - or right. :)

My only request is one of graphical configuration. Would it be possible to get the option to set the bars to use a single color, and have the player names be colored by class? Recount is the only addon in my UI where I can't turn off class-colored bars, and so it's the only one still using them. :)

Recount is now using 1.24MB on login (no fights are stored, everything wiped), previously it was in the low 900's. This happened after today's update, using Broker_Sysmon to monitor addon usage (which also got updated today). Can anyone confirm this, and if it is correct, why the increase?

Just checked. Recount on my machine has 990 MiB on start including RecountThreat and RecountDeathTrack, 980 MiB without. This is with Option(less)House.

In terms of what happened, I added two config options. This should add minimal memory.

Delete your per character SV, I suspect you just have some legacy data floating around.

Don't you mean 990 KiB, Elsia? :p

It's terabytes really ;)

Deleted all Recount savedvars now (main one included), and it's still using 1.23mb. Not idea why, could be Broker_Sysmon that's a bit fishy.

It could be a lib that gets attributed to Recount. No clue. But code-wise Recount has only seen very minimal additions in recent history. Certainly nothing remotely near the scale of a 300KiB jump.

Something's going on for sure, but i can't seem to find the culprit. Damage even gets recorded when i have ''solo'' set to off, it stops recording when i tick ''keep only boss segments''.

Edit: Went back to r988 and mem usage is back to normal. Definately weird.

That makes no sense to me. The code change from 988->989 is minimal, touches nothing that in any way relates to data collection.

Simply said, the changes from 988->989 cannot cause the effects you describe.

If anything I'd expect the effect to be visible in 988 as well. Unless this is a very odd bug related to aceconfig which I doubt.

Quote from Elsia

That makes no sense to me. The code change from 988->989 is minimal, touches nothing that in any way relates to data collection.

Simply said, the changes from 988->989 cannot cause the effects you describe.

If anything I'd expect the effect to be visible in 988 as well. Unless this is a very odd bug related to aceconfig which I doubt.

927kib with 988, and that's how it's allways been. I also noticed a slight memory increase with 989 without doing anything special when soloing, going to do some more tests.

I just installed broker_sysmon. Shows the same numbers as OH. I get no accumulation while solo/idling in Dalaran and both show the values I reported earlier. While going for the fishing dailies I killed mobs solo under the conditions you report. I see neither memory accumulation nor evidence that data is recorded.

I still vote for those extra 250-odd KiB being from some lib that for some reason get attributed to Recount.

Quote from Elsia

I just installed broker_sysmon. Shows the same numbers as OH. I get no accumulation while solo/idling in Dalaran and both show the values I reported earlier. While going for the fishing dailies I killed mobs solo under the conditions you report. I see neither memory accumulation nor evidence that data is recorded.

I still vote for those extra 250-odd KiB being from some lib that for some reason get attributed to Recount.

Yeah, but r988 uses the same libs as 989? So it seems very strange to me.

I cannot reproduce the problem. If you can find any way that I can reproduce it on my end then I can do something about it. I do not see the effect you report and it makes no sense given the changes that happened from 988->989.

I decided to use Recount Threat instead of installing Omen since I thought it silly to install another addon if Recount could double up as a threat meter, the problem is it seems to display the threat with an odd scaling, this is pretty much just after pulling a trash pack in Naxx, the threat shown is way too high.

Thanks, I'll look into it. I have gotten very little testing on the thread module yet, so it's good to see feedback coming!

Quote from Skylinee

Yeah, but r988 uses the same libs as 989? So it seems very strange to me.

There was an Ace3 release between those two revisions, couldn't that cause the libs to be loaded from Recount, causing the different results!?

Hej!

I don't know if it was already posted here, but one of the guys from wowhead.com maybe found a solution for the disc-priest recount. I'll just link you to the thread.

http://www.wowhead.com/?forums&topic=68238.3

And here's the modified Tracker.lua he came up with:

http://my.curse.com/members/bifffur/files/Tracker.lua.txt.aspx

There are two proposed methods out, one is based on talents and indirect effects (Glyphed PW:S and DA), the second is based on tracking spell casts, and attributing absorbs to the casts.

The first is heuristic because there is no way to track healing modifiers.

I did some fairly extensive testing on the second with help of some nice people on the #wowace irc channel. Result is that this method makes flawed assumptions on how absorbs relate to prior casts. Tests indicate that this relationship is not straight forward and in fact does depend on the remaining power of the shield in some fashion. Precise working of the mechanism is still unknown, except that the way the second method implements it is definitely false in various situations.

Even if the mechanism is reveiled, it is very likely hard to impossible to track the data to come up with good decision making what aborption spell will take priority.

In short the second method fails as implemented and is very likely very hard to fix.

Both these methods are fine for people who want to get ballpark feels of absorb contributions, I prefer the second because it's class and talent independent. But both methods are heuristic and fail in unpredictable ways hence are not really suited to be added to recount as if they were faithful representations of contributions.

I do think having a separate RecountGuessedAbsorb module likely based on the second method is a viable solution until either blizz offers this info directly or a better method is being discovered. I do not have time to hack something of this sort right now but it's on my list of stuff to do.

I do think some disc priests will still be unhappy, but the problem here is currently not really easy to fix addon-side.

Quote from Skylinee

Recount is now using 1.24MB on login (no fights are stored, everything wiped), previously it was in the low 900's. This happened after today's update, using Broker_Sysmon to monitor addon usage (which also got updated today). Can anyone confirm this, and if it is correct, why the increase?

Updated again to the latest version today and memory usage is back to normal.. God knows what caused the issues yesterday.