That's fine, but someone is offering it (finally), and I thought posting here would help whoever IS working on it realize there's a bug. Guess I was wrong. =P
I know that others offer it. That's their responsibility/choice. I think it's a bad idea but that's me. And yes it means that people will breath down my neck now.
But Recount is about presenting things accurately and cleanly and I'll be sticking to that design goal as best I can help it. Misperceptions once established, haunt meters for many years. I am not one to contribute to that problem.
I'm not talented enough to search through 300 pages of thread to find your previous arguments, but I thought they made changes to the combat log recently to indicate how much is actually absorbed. Or is that only for hits that aren't fully absorbed? I dunno.
Anyway, I thought some of the guesswork was taken out and it could be a more precise statistic. Maybe it wasn't. As far as why you offer guessed absorbs but no way to add that to heals for an easy-to-announce list to show that yes, I was the best healer in that fight, without making people do math to make my point, I don't get. Also, the ability to watch during combat so I can compare myself with the other healers and know when I need to step it up a notch would also help. Why you'd offer absorbs but not offer the option to add them to heals is confusing to me.
Anyway, someone /is/ offering it, but there's a bug in that it's not listed on modules that can be viewed, so I'm just trying to report it so that person, or someone else who's interested in doing so, can fix the bug.
I thought they made changes to the combat log recently to indicate how much is actually absorbed. Or is that only for hits that aren't fully absorbed? I dunno.
Anyway, I thought some of the guesswork was taken out and it could be a more precise statistic. Maybe it wasn't. As far as why you offer guessed absorbs[..]
No such change happened in the game. Absorb estimation is as heuristic as it has ever been.
but no way to add that to heals for an easy-to-announce list to show that yes, I was the best healer in that fight, without making people do math to make my point, I don't get.
Two points on this:
(1) it's not Recount's function to show that anybody is the best at anything, it is Recount's function to give a solid representation what happened in a fight. You can have been the best contributor to the raid and most vital to its success and rank purely in all numerical categories of Recount. I understand that many people use damage meters to be top at some numerical score, however people have to understand that I will never modify Recount solely to feed that desire. It is not it's actual goal.
(2) Absorbs are not heals. You can and should not directly compare them. If you add your absorbs to heals and end up third on the healing meter this does not mean that you were third best healer. Absorbs are, situationally more potent than heals. An absorb can prevent a death or a wipe where a heal cannot. The mechanisms that would lead to "over-absorbs" or overheals are completely different. Right use of absorb-heavy classes and heal throughput classes in raids is very different.
To merge them only serves to give the false impression that the comparison is legit. In fact it undersells the tremendous value of smart absorbs in raid.
Recount cannot educate people how to analyse fights, but it can at least not contribute to giving false impressions.
Also, the ability to watch during combat so I can compare myself with the other healers and know when I need to step it up a notch would also help. Why you'd offer absorbs but not offer the option to add them to heals is confusing to me.
See above you cannot. 40000k heals are not comparable to 40000k absorbs. If you want to know if you succeeded, deaths is the most accurate healing stat out there. If you want to know who is slacking, watching the activity counts in more indicative of productivity than heal+aborbs!
Anyway, someone /is/ offering it, but there's a bug in that it's not listed on modules that can be viewed, so I'm just trying to report it so that person, or someone else who's interested in doing so, can fix the bug.
It's not a bug, it's very much intended. As said I disagree that merges should exist, but it's not my choice. Same goes to meters presenting absorbs in the same way as other collected values, when currently absorbs are a heuristic measure, whereas heals are directly derived from the combat log without any uncertainty at all. Clearly this has contributed to people falsely believing that absorbs can now be (more) accurately be tracked, when this is actually incurrect. All this creates superficial and wrong expectations that I wish wouldn't. But alas so we have it.
I agree with your logic, and I'll be monitoring activity instead of heals now, but nothing beats throwing numbers at your raid leader to stop him from kicking you from the raid. I agree that smart playing trumps all, but finding 24 other people who feel that way is difficult.
Your logic does have one hole, though. A heal and absorb can actually both be situational. Healing the wrong person, especially if they don't even have aggro, while you let the tank die, can cause a wipe as well. Absorbs are more situational, of course, but if the damage is absorbed, it can be considered as an instant heal for the target, and only if that damage is something that would have killed the player does it really matter that it was prevented instead of healed after it occurred. Of course, 'over-absorbs' would be equivalent of 'over-heals', if damage wasn't absorbed it's a waste.
In short, if a person is at 10k health and after 5k damage from the boss is done, and my spell is cast, they are now at 8k health, does it matter if the spell I cast was a shield that absorbed 3k of the damage or a heal that healed 3k of damage? The end result is the same. That is why people consider them equivalent. A shield is only more important if it actually prevents death, and that situation is rare enough that it doesn't really affect statistics any more or less than healing 'incorrect targets' and causing a wipe would affect statistics.
Even as a very geared disc priest, my shields only absorb for maybe 5-7k, is my estimation. Very rarely do my shields actually 'save a life' in level 80 raid content, they can certainly help, but it's no real different from an instant-cast heal that automatically happens (like prayer of mending, or a tick of a hot that happens just after damage is taken). The chance of a shield blocking the damage that kills a player is significantly small enough to, in my opinion, not alter the statistic enough from basically being another way of healing.
I agree that they're two separate things and having them in separate categories would definitely be important, but having the option to have them added together, I still don't see what the harm is, with the exception of having a 'guessed' (or hueristic) statistic added to a real one. That's always not fun of course, but I just see it as a limitation that has to be accepted in order to have any kind of stats at all for absorbs.
I thought I saw patch notes awhile back, like 3.0 or 3.1-ish, talking about absorbs and combat log and changes. I didn't read too closely because at the time I was leveling and not raiding. I think the only real change is the final hit changed from 'full absorb' and 'reduced damage' to 'absorb for X amount' and 'reduced damage', but only for the hit that breaks the absorb. That's just a guess though.
Announcing it as heals + guessed absorbs would still indicate the guessed nature.
Now if you're specifically coding the core Recount addon to prevent this plugin from working, that's just mean. =P Just because you don't include or agree, does it really matter that much if someone else does it?
Now if you're specifically coding the core Recount addon to prevent this plugin from working, that's just mean. =P Just because you don't include or agree, does it really matter that much if someone else does it?
Clearly you don't understand how addons work and a few other things. I wrote the plugin RecountGuessedAbsorbs, nothing in Recount core prevents anything, and noone is being mean here at all.
The situation is this: You have requested an addition to an addon of mine, claiming it's a bug when it isn't. I have denied the request, and in great detailed explained why. That's pretty much the end of the story as I see it.
There is a multitude of references to this discussion in this thread and to find them is absolutely trivial.
(search this thread is not exactly rocket science)
However to aid you the largest contiguous discussion occurred starting here and continuing for a couple pages to roughly the end of page 297
Among other good contributions from both "camps" this one time poster presented the situation very clearly (link)
Page 310 also adds another facet to the problem of absorbs, the difference between "offensive" and "defensive" absorbs.
For the record I absolutely agree that Recount's job is not to educate clueless raid leaders or lazy puggers by presenting arbitrary aggregates.
If one wants such any arbitrary aggregate they should make a module/view themselves and take all the "heat" for it.
It should (imo) stick to trying to provide meaningful details and drill downs and being as accurate as the game allows.
The situation is this: I saw an addon for heals + absorbs that was tagged as 'recount' so I thought this was the place to report a bug in an addon that has already been created (I thought there was some sort of Recount 'team' and this would be the most expditious way of reporting a bug for any Recount-related addon as opposed to messaging an individual person). I was not attempting to request a feature that does not yet exist in the core addon. I am apparently wrong about this being the right place to mention it.
I was going to just let it go, but then when I mentioned that the module that has been created by someone else has a bug in it that is causing it to not work, I received this response:
It's not a bug, it's very much intended.
This lead me to ask if the original core addon is somehow blocking this new addon created by someone else from working. Your beliefs and opinions on the nature of the core addon made me wonder if you believe this so strongly that you would prevent another addon that tries to do this from being operational. So I asked if that was the case.
Since I was sticking around anyway, I thought I'd toss out a couple arguments about my opinions on heals vs absorbs while I was at it. I doubt I'd say anything that hasn't already been covered, but I just wanted to understand the reasoning a little more. I'll review the links posted by the above post when I have some idle time. I like logical debate. (And didn't I already said I agree and will use activity as the best measurement of skill Recount is capable of anyway?)
I'm sorry, I didn't realize my communication skills were this bad. I seem to have been misunderstood at every turn. Hopefully this clarifies things. I didn't mean to jump in and light a fire, I just meant to report a bug and have apparently done so in the wrong place.
I see. I wasn't aware of that module. In general this is the place to report all things Recount. Specifically it's the right place for these things: Recount, RecountThreat, RecountGuessedAbsorbs and RecountDeathTrack as well as Broker_Recount. All these are written by Cryect or me. Any other plugins you'd have to find the author and find where they like their bugs reported.
I'm not sure how to best disambiguate these things. In the past there weren't any sizeable modules by third parties, so this is new to me. I don't have an issue with it and I can see that people may be led to believe that this is the place. If you find the right place to report bugs for the module let me know and I'd be happy to forward future requests that way. In fact I don't have an issue with module authors using this thread, I just need to be aware and things have to stay sensibly sane.
Tonight, full clear of ToC-25 + first 2 bosses of Ulduar-25 (because Razorscale is the weekly raid quest on our realm). Running with default settings, I believe. Meaning keep boss segments only. Only setting I change is the 5 fights kept limit. I always increase that. In any case, that's a total of 7 bosses for tonight.
I decided to try a reloadui after all that. Got another wow.exe crash sending me back to the windows desktop. Here's the message I got before hitting the Send button for Blizz:
This application has encountered a critical error:
Not enough storage is available to process this command.
Program: C:\Users\Public\Games\World of Warcraft\WoW.exe
File: d:\buildserver\wow\4\work\wow-code\branches\wow-patch-3_3_0_b-branch\engine\source\blizzardcore\blizzardcore\source\system\memory\MemoryStorm.cpp
Line: 64
Requested 35243907 bytes of memory
35243907 is the exact size of my Recount's savedvar file after the reloadui. In other words, when I did reloadui, it saved it, tried to reload it... and failed miserably.
What bothers me is the size of the file. 35 MB for 7 bosses? You said you had a full clear of BT log that was 20 MB. Something seems wrong there.
That doesn't mean WoW shouldn't be able to load that though. After the crash, I was able to log in without a hard crash, but of course, I got the memory block too big error and Recount's empty.
I can't pretend I understand your table structure in the savedvars, but there seems to be a lot of info about deaths. I could be wrong, but it appears the RecountDeathTrack plugin uses the same SV file. Could it be what's bloating it? Just an idea since I have that plugin...
That does worry me for other reasons. A saved variables file of X MB will actually be smaller when in memory. From experience the ratio is somewhere close to 50% (give or take). So if you have a 34MB SV file, that's only 17MB addon memory, which is very acceptable. Even if we are more generous in the conversion and asume 100%, 34MB is not at all large. I have routinely seen 40MB addon memory usage while raiding in the past and WoW was fine handling it.
How much main memory do you have?
On deaths, as I mentioned earlier deaths use a lot of memory, but this is largely independent of the RecountDeathTrack module. Turning off death recording will be a large decrease in memory usage, but lots of people want the death information so that's a tricky trade-off. Reason for death are really useful when raiding. I don't have time right now but in a week or two I may try to do an optimization pass on the death data. But it will be hard to do without also limiting the current functionality at the same time.
But back to your report, what I am saying is that the sizes you report are not at all worrying and should work. If WoW can no longer handle these sizes addons like Recount with sensible detail depth are screwed until Blizz fixes their bugs. I hope there are other reasons though.
Just to be clear, WoW does handle that much data without problems. I could have kept raiding all night and ended up with a bigger memory usage than that above. The problem only manifests itself when loading the savedvars. I do think Blizzard screwed up something.
I have 4 GB of RAM in my computer. That should be plenty. Also, while I agree that this isn't a huge amount of memory being used, it did seem a little excessive for only 7 bosses. I mean the SV file has way over a million lines (not home right now to check the exact number).
As said the size is normal/not in a range that worries me at all. 1 million lines isn't that special, if the file is 34mb that means on average 34 characters per line... that's just how lua represents its tables in text.
Let me be more explicit about this. What determines size is the following:
*) Any recordable action by players. That is every hit on a trash mob can (but does not have to!) add to size. If the trash mob is new it will definitely add to size.
*) Any death involving a player definitely will add to size.
*) Any recorded boss segment will increase the size substantially, it's less then an integer factor but in the worst case exactly an integer factor per segment. That means if you store 5 boss segments vs 7 boss segments you can expect a memory usage increase of up to (7+1)/(5+1) = 1.333 (+1 for the overall fight data). That means that if you had stored the standard 5 bosses your size could be as low as 34MB/1.333=25MB.
As said, I see no evidence that the size you report is excessively large given what you say you are collecting.
Yes, well all this transformations are not perfect, but as said I see nothing that I'd consider unusual... If people's raid evenings end with 34MB SV files after storing 7 bosses, I'm pretty much happy. I have tolerance for worse. This is not a bad size at all. As I posted initially upward of 50MB addon memory is where I start to worry. 100MB addon memory is serious etc. SV File sizes will be larger by some factor.
Had you said that a raid night left you at 40MB addon memory that's still within the realm of what I have experienced and consider within expectations.
We really shouldn't be micro-comparing very different cases. A farm BT run where as much trash is avoided, noone ever dies etc can be far smaller than a wipe night where no boss ever goes down. There is no real way for me to judge relative file sizes in detail. I can just to be ranges with fairly large tolerances.
Would it perhaps help to split Recounts saved variables into multiple files? Such as having deaths recorded into a separate file? If it's only the save of the file causing the issue, or is it definitely the amount of addon memory being used by Recount?
I've personally only ever had the error when I increased the number of past fights past the default.
Would it perhaps help to split Recounts saved variables into multiple files? Such as having deaths recorded into a separate file? If it's only the save of the file causing the issue, or is it definitely the amount of addon memory being used by Recount?
I've personally only ever had the error when I increased the number of past fights past the default.
+1 to this suggestion if it's technically feasible.
Since the problem seems to be only with allocation of memory when loading an SV table in
and not when saving it, or with resident memory while running the game,
this appears to be the only long term solution.
As a temporary fix until things can be modularized differently in Recount maybe people facing the problem could disable gathering of death data or any other "optional" combatlog info and rely on separate addons (where available) to do the job.
(Acheron or GrimReaper for deaths etc)
We really shouldn't be micro-comparing very different cases. A farm BT run where as much trash is avoided, noone ever dies etc can be far smaller than a wipe night where no boss ever goes down. There is no real way for me to judge relative file sizes in detail. I can just to be ranges with fairly large tolerances.
Agree with this, though I picked last night because we didn't wipe and there's no trash in ToC (the Ulduar part for the weekly raid quest involved vehicle trash and I'm not 100% sure Recount works well with that or even sees the data anyway).
Regarding what's suggested above, that's kinda why I brought up the DeathTrack plugin. Should it have its own SV? Also, since I was never clear on it, doesn't Recount track some sort of death info without the plugin anyway? I'm not even sure of the differences.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
But Recount is about presenting things accurately and cleanly and I'll be sticking to that design goal as best I can help it. Misperceptions once established, haunt meters for many years. I am not one to contribute to that problem.
Anyway, I thought some of the guesswork was taken out and it could be a more precise statistic. Maybe it wasn't. As far as why you offer guessed absorbs but no way to add that to heals for an easy-to-announce list to show that yes, I was the best healer in that fight, without making people do math to make my point, I don't get. Also, the ability to watch during combat so I can compare myself with the other healers and know when I need to step it up a notch would also help. Why you'd offer absorbs but not offer the option to add them to heals is confusing to me.
Anyway, someone /is/ offering it, but there's a bug in that it's not listed on modules that can be viewed, so I'm just trying to report it so that person, or someone else who's interested in doing so, can fix the bug.
Yes, I know about the desire for a combined measure (which some other meters do offer).
No such change happened in the game. Absorb estimation is as heuristic as it has ever been.
Two points on this:
(1) it's not Recount's function to show that anybody is the best at anything, it is Recount's function to give a solid representation what happened in a fight. You can have been the best contributor to the raid and most vital to its success and rank purely in all numerical categories of Recount. I understand that many people use damage meters to be top at some numerical score, however people have to understand that I will never modify Recount solely to feed that desire. It is not it's actual goal.
(2) Absorbs are not heals. You can and should not directly compare them. If you add your absorbs to heals and end up third on the healing meter this does not mean that you were third best healer. Absorbs are, situationally more potent than heals. An absorb can prevent a death or a wipe where a heal cannot. The mechanisms that would lead to "over-absorbs" or overheals are completely different. Right use of absorb-heavy classes and heal throughput classes in raids is very different.
To merge them only serves to give the false impression that the comparison is legit. In fact it undersells the tremendous value of smart absorbs in raid.
Recount cannot educate people how to analyse fights, but it can at least not contribute to giving false impressions.
See above you cannot. 40000k heals are not comparable to 40000k absorbs. If you want to know if you succeeded, deaths is the most accurate healing stat out there. If you want to know who is slacking, watching the activity counts in more indicative of productivity than heal+aborbs!
It's not a bug, it's very much intended. As said I disagree that merges should exist, but it's not my choice. Same goes to meters presenting absorbs in the same way as other collected values, when currently absorbs are a heuristic measure, whereas heals are directly derived from the combat log without any uncertainty at all. Clearly this has contributed to people falsely believing that absorbs can now be (more) accurately be tracked, when this is actually incurrect. All this creates superficial and wrong expectations that I wish wouldn't. But alas so we have it.
Your logic does have one hole, though. A heal and absorb can actually both be situational. Healing the wrong person, especially if they don't even have aggro, while you let the tank die, can cause a wipe as well. Absorbs are more situational, of course, but if the damage is absorbed, it can be considered as an instant heal for the target, and only if that damage is something that would have killed the player does it really matter that it was prevented instead of healed after it occurred. Of course, 'over-absorbs' would be equivalent of 'over-heals', if damage wasn't absorbed it's a waste.
In short, if a person is at 10k health and after 5k damage from the boss is done, and my spell is cast, they are now at 8k health, does it matter if the spell I cast was a shield that absorbed 3k of the damage or a heal that healed 3k of damage? The end result is the same. That is why people consider them equivalent. A shield is only more important if it actually prevents death, and that situation is rare enough that it doesn't really affect statistics any more or less than healing 'incorrect targets' and causing a wipe would affect statistics.
Even as a very geared disc priest, my shields only absorb for maybe 5-7k, is my estimation. Very rarely do my shields actually 'save a life' in level 80 raid content, they can certainly help, but it's no real different from an instant-cast heal that automatically happens (like prayer of mending, or a tick of a hot that happens just after damage is taken). The chance of a shield blocking the damage that kills a player is significantly small enough to, in my opinion, not alter the statistic enough from basically being another way of healing.
I agree that they're two separate things and having them in separate categories would definitely be important, but having the option to have them added together, I still don't see what the harm is, with the exception of having a 'guessed' (or hueristic) statistic added to a real one. That's always not fun of course, but I just see it as a limitation that has to be accepted in order to have any kind of stats at all for absorbs.
I thought I saw patch notes awhile back, like 3.0 or 3.1-ish, talking about absorbs and combat log and changes. I didn't read too closely because at the time I was leveling and not raiding. I think the only real change is the final hit changed from 'full absorb' and 'reduced damage' to 'absorb for X amount' and 'reduced damage', but only for the hit that breaks the absorb. That's just a guess though.
Announcing it as heals + guessed absorbs would still indicate the guessed nature.
Now if you're specifically coding the core Recount addon to prevent this plugin from working, that's just mean. =P Just because you don't include or agree, does it really matter that much if someone else does it?
Clearly you don't understand how addons work and a few other things. I wrote the plugin RecountGuessedAbsorbs, nothing in Recount core prevents anything, and noone is being mean here at all.
The situation is this: You have requested an addition to an addon of mine, claiming it's a bug when it isn't. I have denied the request, and in great detailed explained why. That's pretty much the end of the story as I see it.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium(search this thread is not exactly rocket science)
However to aid you the largest contiguous discussion occurred starting
here and continuing for a couple pages to roughly the end of page 297
Among other good contributions from both "camps" this one time poster presented the situation very clearly (link)
Page 310 also adds another facet to the problem of absorbs, the difference between "offensive" and "defensive" absorbs.
For the record I absolutely agree that Recount's job is not to educate clueless raid leaders or lazy puggers by presenting arbitrary aggregates.
If one wants such any arbitrary aggregate they should make a module/view themselves and take all the "heat" for it.
It should (imo) stick to trying to provide meaningful details and drill downs and being as accurate as the game allows.
Just my 2c.
I was going to just let it go, but then when I mentioned that the module that has been created by someone else has a bug in it that is causing it to not work, I received this response:
This lead me to ask if the original core addon is somehow blocking this new addon created by someone else from working. Your beliefs and opinions on the nature of the core addon made me wonder if you believe this so strongly that you would prevent another addon that tries to do this from being operational. So I asked if that was the case.
Since I was sticking around anyway, I thought I'd toss out a couple arguments about my opinions on heals vs absorbs while I was at it. I doubt I'd say anything that hasn't already been covered, but I just wanted to understand the reasoning a little more. I'll review the links posted by the above post when I have some idle time. I like logical debate. (And didn't I already said I agree and will use activity as the best measurement of skill Recount is capable of anyway?)
I'm sorry, I didn't realize my communication skills were this bad. I seem to have been misunderstood at every turn. Hopefully this clarifies things. I didn't mean to jump in and light a fire, I just meant to report a bug and have apparently done so in the wrong place.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumHe said there is a bug in RecountHealAndGuessedAbsorbs (made by Webiz), not in your RecountGuessedAbsorbs.
I'm not sure how to best disambiguate these things. In the past there weren't any sizeable modules by third parties, so this is new to me. I don't have an issue with it and I can see that people may be led to believe that this is the place. If you find the right place to report bugs for the module let me know and I'd be happy to forward future requests that way. In fact I don't have an issue with module authors using this thread, I just need to be aware and things have to stay sensibly sane.
Tonight, full clear of ToC-25 + first 2 bosses of Ulduar-25 (because Razorscale is the weekly raid quest on our realm). Running with default settings, I believe. Meaning keep boss segments only. Only setting I change is the 5 fights kept limit. I always increase that. In any case, that's a total of 7 bosses for tonight.
I decided to try a reloadui after all that. Got another wow.exe crash sending me back to the windows desktop. Here's the message I got before hitting the Send button for Blizz:
35243907 is the exact size of my Recount's savedvar file after the reloadui. In other words, when I did reloadui, it saved it, tried to reload it... and failed miserably.
What bothers me is the size of the file. 35 MB for 7 bosses? You said you had a full clear of BT log that was 20 MB. Something seems wrong there.
That doesn't mean WoW shouldn't be able to load that though. After the crash, I was able to log in without a hard crash, but of course, I got the memory block too big error and Recount's empty.
I can't pretend I understand your table structure in the savedvars, but there seems to be a lot of info about deaths. I could be wrong, but it appears the RecountDeathTrack plugin uses the same SV file. Could it be what's bloating it? Just an idea since I have that plugin...
I have the 35MB file if you really want it, btw.
How much main memory do you have?
On deaths, as I mentioned earlier deaths use a lot of memory, but this is largely independent of the RecountDeathTrack module. Turning off death recording will be a large decrease in memory usage, but lots of people want the death information so that's a tricky trade-off. Reason for death are really useful when raiding. I don't have time right now but in a week or two I may try to do an optimization pass on the death data. But it will be hard to do without also limiting the current functionality at the same time.
But back to your report, what I am saying is that the sizes you report are not at all worrying and should work. If WoW can no longer handle these sizes addons like Recount with sensible detail depth are screwed until Blizz fixes their bugs. I hope there are other reasons though.
I have 4 GB of RAM in my computer. That should be plenty. Also, while I agree that this isn't a huge amount of memory being used, it did seem a little excessive for only 7 bosses. I mean the SV file has way over a million lines (not home right now to check the exact number).
Let me be more explicit about this. What determines size is the following:
*) Any recordable action by players. That is every hit on a trash mob can (but does not have to!) add to size. If the trash mob is new it will definitely add to size.
*) Any death involving a player definitely will add to size.
*) Any recorded boss segment will increase the size substantially, it's less then an integer factor but in the worst case exactly an integer factor per segment. That means if you store 5 boss segments vs 7 boss segments you can expect a memory usage increase of up to (7+1)/(5+1) = 1.333 (+1 for the overall fight data). That means that if you had stored the standard 5 bosses your size could be as low as 34MB/1.333=25MB.
As said, I see no evidence that the size you report is excessively large given what you say you are collecting.
EDIT: Ok I see you said 20 MB addon memory, so I guess a 40 Mb resulting file? That's not that far from mine, which is for 7 bosses.
Had you said that a raid night left you at 40MB addon memory that's still within the realm of what I have experienced and consider within expectations.
We really shouldn't be micro-comparing very different cases. A farm BT run where as much trash is avoided, noone ever dies etc can be far smaller than a wipe night where no boss ever goes down. There is no real way for me to judge relative file sizes in detail. I can just to be ranges with fairly large tolerances.
I've personally only ever had the error when I increased the number of past fights past the default.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumSince the problem seems to be only with allocation of memory when loading an SV table in
and not when saving it, or with resident memory while running the game,
this appears to be the only long term solution.
As a temporary fix until things can be modularized differently in Recount maybe people facing the problem could disable gathering of death data or any other "optional" combatlog info and rely on separate addons (where available) to do the job.
(Acheron or GrimReaper for deaths etc)
Agree with this, though I picked last night because we didn't wipe and there's no trash in ToC (the Ulduar part for the weekly raid quest involved vehicle trash and I'm not 100% sure Recount works well with that or even sees the data anyway).
Regarding what's suggested above, that's kinda why I brought up the DeathTrack plugin. Should it have its own SV? Also, since I was never clear on it, doesn't Recount track some sort of death info without the plugin anyway? I'm not even sure of the differences.