@Avitus: Read back. I'm out of the country until Monday, so no fixes that need wet-testing until then. I did check that bug report and it is non-obvious hence needs wet-testing, so no fix for it until Monday earliest.
@memory usage: Memory usage climbing is normal for a storing damage meter, just the amount is what concerns me. A BT clear should not net 100MB let alone 200MB on sensible filter settings (and yes this is crucial!). I cannot test if 2.4.2 changed anything until Monday but death tracking for NPCs always worked anyway so that doesn't explain it if players don't die.
my filetr settings were pretty much like Skylinee's, no timed stuff or anything, just absolute basics.
Does Recount have a feature to tie in with BigWigs and automatically save off boss fights (if configured to do so), by chance? Its probably one of the biggest things I miss having lost Assessment to patch 2.4, when looking at other meters.
did you guys fix the death counter yet? It's been broken for a crow's age and was wondering if that was expected to be fixed in this latest patch or not?
did you guys fix the death counter yet? It's been broken for a crow's age and was wondering if that was expected to be fixed in this latest patch or not?
It should be fixed as of the current patch, 2.4.2.
Have there been any reports of getting immediately disconnected after login or serious lag issues (not affected by internet connection) when using Recount? I'm really starting to think its a Recount issue since when I have it disabled, I don't have any problems. I really hope there is some fix for this as I hate switching to Violation.
I'm not aware of any reports about this. It's also highly unlikely that recount disconnects you on login because it doesn't do the thinks that can typically disconnect you on login.
Can you do two things? Delete all wtf/*/Recount.lua files (there are a few) and load recount as the only addon. Then disable recount and try again. If you see the same pattern let me know.
Just got the following error in a WSG battleground:
2008/05/17 15:06:07-4155-x1]: Recount-73484\Tracker.lua:1262: attempt to index local 'victimData' (a nil value)
Recount-73484\Tracker.lua:348: in function `parsefunc'
Recount-73484\Tracker.lua:600: in function `?'
CallbackHandler-1.0\CallbackHandler-1.0.lua:146: in function <...Ons\Ace3\CallbackHandler-1.0\CallbackHandler-1.0.lua:146>
<string>:"safecall Dispatcher[13]":4: in function <[string "safecall Dispatcher[13]"]:4>
<in C code>: ?
<string>:"safecall Dispatcher[13]":13: in function `?'
CallbackHandler-1.0\CallbackHandler-1.0.lua:91: in function `Fire'
AceEvent-3.0\AceEvent-3.0.lua:70: in function <Interface\AddOns\Ace3\AceEvent-3.0\AceEvent-3.0.lua:69>
---
I recently updated from 70712 to the latest version. I know that some changes to fonts and bar sizes have been made, but is it intended that my font size increased without changing the bar size? I liked it better before!
I'm not aware of any reports about this. It's also highly unlikely that recount disconnects you on login because it doesn't do the thinks that can typically disconnect you on login.
Can you do two things? Delete all wtf/*/Recount.lua files (there are a few) and load recount as the only addon. Then disable recount and try again. If you see the same pattern let me know.
This is very odd, I tried everything you said but I was never able to reproduce the problem. I have a few addons that are out of date but its mostly Fubar plugins. Maybe all that was needed was fresh Recount settings? :)
Anyways, I will report again if I get the same problems again. Thanks again for a quick response.
There is currently a mistake in the way Recount counts damage of extra attacks. The way the combat log reports an extra attack is like so:
Line 1) Vulajin's melee swing hits Some Mob for XXX. (unrelated melee swing)
Line 2) Vulajin gains 1 extra attacks through Sword Specialization.
Line 3) Vulajin's melee swing hits Some Mob for XXX. (swing that caused the proc)
Line 4) Vulajin's melee swing hits Somb Mob for XXX. (sword spec swing)
Currently, Recount assumes that the swing on line 3, the one immediately following the proc announcement, is the sword spec extra attack. Instead, the swing that causes the proc always immediately follows the proc announcement, and then the extra attack comes next.
This isn't a particularly high priority thing to fix, as Recount still counts the total damage correctly (as far as I can tell), but it would be helpful for accuracy in analyzing my damage after a fight.
How do you know that's true? Why can't line 1 be the proccing attack, and line 3 be the proc? Even if line one is not the proc attack how do you know that 3 and 4 related to procer and procee in the way you describe it and not the other way around?
I coded this based on windfury procs and my combat logs show heroic strike windfury procs to have the following order:
1) Heroic strike (causes the proc)
2) Gain windfury attack
3) Heroic strike
All white damage attacks have the same pattern, i.e. that you see a white attack, the proc, and a next attack at the same time stamp.
I didn't study sword spec procs in detail (but did take a look if it matched the pattern and it did). I am so far assuming that all proc mechanisms are the same internally as the combat log doesn't distinguish between abilities themselves. If you have a proof that this assumption isn't valid I'd love to see it.
A final word about this is that I'm unaware that blizz has ever stated that combat log order/sequences are stable/guaranteed. I personally treat everything that Recount does that requires watching multiple combat log events as inherently heuristic (though a lot of it turns out to work well in practice), not only because we don't know if sequences are stable, but also because we don't know if you will always see the full sequence.
immer nich das selbe Problem, nach einem Wipe verschwinden die Hexenmeister aus der Liste (Reset ihrer Daten), hast du eine Idee an was es liegen k?nnte?
Had an issue in Kara tonight with my meter reading me at about 3x the damage everyone else saw me at. I'll post a SS if it happens again (dps was right though :/).
And if I have it set to "keep boss segments only" does it still track damage done/dps accurately for all the other fights?
@sleazy: Verschindet er wenn alle noch tot sind oder nach dem ressen, wenn er sein Pet wieder herzaubert?
@ant: SS much appreciated. Boss segments only affects if a segment is copied into storage after a fight ends and does in no way interfere with data collection. Overall data still will contain all data collected, irrespective of a boss having been present or not.
How do you know that's true? Why can't line 1 be the proccing attack, and line 3 be the proc? Even if line one is not the proc attack how do you know that 3 and 4 related to procer and procee in the way you describe it and not the other way around?
I coded this based on windfury procs and my combat logs show heroic strike windfury procs to have the following order:
1) Heroic strike (causes the proc)
2) Gain windfury attack
3) Heroic strike
All white damage attacks have the same pattern, i.e. that you see a white attack, the proc, and a next attack at the same time stamp.
I didn't study sword spec procs in detail (but did take a look if it matched the pattern and it did). I am so far assuming that all proc mechanisms are the same internally as the combat log doesn't distinguish between abilities themselves. If you have a proof that this assumption isn't valid I'd love to see it.
A final word about this is that I'm unaware that blizz has ever stated that combat log order/sequences are stable/guaranteed. I personally treat everything that Recount does that requires watching multiple combat log events as inherently heuristic (though a lot of it turns out to work well in practice), not only because we don't know if sequences are stable, but also because we don't know if you will always see the full sequence.
I know it's true because I have studied sword spec procs pretty extensively for rogue mechanics and the result is always as I described it. It's feasible that the Heroic Strike version is different, but the particular reason I can tell that it functions this way for sword spec is that I have a main hand fist (can't proc sword spec) and an off hand sword (can proc sword spec). I verified it yesterday in testing that the "You gain 1 extra attack" message was preceded by a main hand hit (damage range was too high to be an off hand hit) and followed by an off hand hit, which was then followed by a main hand hit.
This behavior has been pretty consistent across all of my testing, so I'm not sure why yours would be different other than the idea that perhaps Heroic Strike itself is unique.
(edit) Here are some links that support the interpretation I've given:
One prob though, deathlog "REPORTS" are not working:
[2008/05/15 00:26:15-2773-x1]: SendChatMessage(): Invalid escape code in chat message:
<in C code>: ?
<in C code>: in function `SendChatMessage'
Prat_Modules\modules\ChatLink.lua:223: in function <Interface\AddOns\Prat_Modules\modules\ChatLink.lua:214>
(tail call): ?:
Recount-73484\GUI_Detail.lua:2040: in function `ReportFunc'
Recount-73484\GUI_Report.lua:197: in function `SendReport'
Recount-73484\GUI_Report.lua:138: in function <Interface\AddOns\Recount\GUI_Report.lua:138>
Also getting this error, slightly different, though.
[2008/05/18 23:25:37-3581-x1]: SendChatMessage(): Invalid escape code in chat message:
<in C code>: ?
<in C code>: in function `SendChatMessage'
Recount-73484\GUI_Detail.lua:2040: in function `ReportFunc'
Recount-73484\GUI_Report.lua:197: in function `SendReport'
Recount-73484\GUI_Report.lua:138: in function <Interface\AddOns\Recount\GUI_Report.lua:138>
@sleazy: Verschindet er wenn alle noch tot sind oder nach dem ressen, wenn er sein Pet wieder herzaubert?
wir haben 2 Hexer in der Gruppe und ich habe bis jetzt nicht rausgefunden in welchen Zusammenhang die beiden verschwinden bzw. ihre Daten auf 0 gesetzt werden.
- es passiert nicht immer, wenn dann waren in den letzten Wochen die Hexer betroffen
- sie verschwinden zu unterschiedlichen zeitpunkten, mal wenn alle noch tot sind, mal wenn man grad am buffen ist
Je mehr details wann das passiert desto besser. Tot sein sollte das nicht ausl?sen. Meine Vermutung ist das es mit den Pets zu tun hat, aber sicher kann ich da noch nicht sein.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
my filetr settings were pretty much like Skylinee's, no timed stuff or anything, just absolute basics.
Gonna run a few tests again today.
If anyone with expo could profile Recount in the meantime that'd help.
It should be fixed as of the current patch, 2.4.2.
Have there been any reports of getting immediately disconnected after login or serious lag issues (not affected by internet connection) when using Recount? I'm really starting to think its a Recount issue since when I have it disabled, I don't have any problems. I really hope there is some fix for this as I hate switching to Violation.
Thanks in advance.
Can you do two things? Delete all wtf/*/Recount.lua files (there are a few) and load recount as the only addon. Then disable recount and try again. If you see the same pattern let me know.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThis is very odd, I tried everything you said but I was never able to reproduce the problem. I have a few addons that are out of date but its mostly Fubar plugins. Maybe all that was needed was fresh Recount settings? :)
Anyways, I will report again if I get the same problems again. Thanks again for a quick response.
Line 1) Vulajin's melee swing hits Some Mob for XXX. (unrelated melee swing)
Line 2) Vulajin gains 1 extra attacks through Sword Specialization.
Line 3) Vulajin's melee swing hits Some Mob for XXX. (swing that caused the proc)
Line 4) Vulajin's melee swing hits Somb Mob for XXX. (sword spec swing)
Currently, Recount assumes that the swing on line 3, the one immediately following the proc announcement, is the sword spec extra attack. Instead, the swing that causes the proc always immediately follows the proc announcement, and then the extra attack comes next.
This isn't a particularly high priority thing to fix, as Recount still counts the total damage correctly (as far as I can tell), but it would be helpful for accuracy in analyzing my damage after a fight.
I coded this based on windfury procs and my combat logs show heroic strike windfury procs to have the following order:
1) Heroic strike (causes the proc)
2) Gain windfury attack
3) Heroic strike
All white damage attacks have the same pattern, i.e. that you see a white attack, the proc, and a next attack at the same time stamp.
I didn't study sword spec procs in detail (but did take a look if it matched the pattern and it did). I am so far assuming that all proc mechanisms are the same internally as the combat log doesn't distinguish between abilities themselves. If you have a proof that this assumption isn't valid I'd love to see it.
A final word about this is that I'm unaware that blizz has ever stated that combat log order/sequences are stable/guaranteed. I personally treat everything that Recount does that requires watching multiple combat log events as inherently heuristic (though a lot of it turns out to work well in practice), not only because we don't know if sequences are stable, but also because we don't know if you will always see the full sequence.
immer nich das selbe Problem, nach einem Wipe verschwinden die Hexenmeister aus der Liste (Reset ihrer Daten), hast du eine Idee an was es liegen k?nnte?
And if I have it set to "keep boss segments only" does it still track damage done/dps accurately for all the other fights?
@ant: SS much appreciated. Boss segments only affects if a segment is copied into storage after a fight ends and does in no way interfere with data collection. Overall data still will contain all data collected, irrespective of a boss having been present or not.
I know it's true because I have studied sword spec procs pretty extensively for rogue mechanics and the result is always as I described it. It's feasible that the Heroic Strike version is different, but the particular reason I can tell that it functions this way for sword spec is that I have a main hand fist (can't proc sword spec) and an off hand sword (can proc sword spec). I verified it yesterday in testing that the "You gain 1 extra attack" message was preceded by a main hand hit (damage range was too high to be an off hand hit) and followed by an off hand hit, which was then followed by a main hand hit.
This behavior has been pretty consistent across all of my testing, so I'm not sure why yours would be different other than the idea that perhaps Heroic Strike itself is unique.
(edit) Here are some links that support the interpretation I've given:
http://elitistjerks.com/205769-post19.html
http://elitistjerks.com/427817-post38.html
Also getting this error, slightly different, though.
When trying to report a death to raid chat.
wir haben 2 Hexer in der Gruppe und ich habe bis jetzt nicht rausgefunden in welchen Zusammenhang die beiden verschwinden bzw. ihre Daten auf 0 gesetzt werden.
- es passiert nicht immer, wenn dann waren in den letzten Wochen die Hexer betroffen
- sie verschwinden zu unterschiedlichen zeitpunkten, mal wenn alle noch tot sind, mal wenn man grad am buffen ist