Gretten

Lately I've been experiencing some irritating issue with Chronometer in raids. I use this as my DoT-tracker, and in solo/pvp it functions very well. However, for instance on Nightbane yesterday I noticed that somehow DoT's kept "falling off" chronometer, even though we in no way reached the debuff-limit. It can really screw up my DoT-cycle sometimes, and that equals lost dps. I have no idea why this happens, if it is a bug, or simply something intended which I don't really see the point in. Therefore I'm asking anyone here if they have experienced the same issue, as it would help my dps be promoted even further.

http://www.discogs.com/artist/drexciya

 

Troggy

I've noticed that too. It seems to be related to Chronometer tracking just any DoT of your type so if you, for example have Corruption up and another warlock had casted it earlier, as soon as his Corr. fell off, Chronometer would take that as your DoT and therefore fade out the bar. I had once changed that behavior in the .lua files But I got tired of it since it got overwritten every time I loaded a new version via WoWAceUpdater.
I think the author had a special case defined somewhere so Banish wouldn't fall off prematurely and I tagged on my SWP/VT/VE accordingly.

 

Gretten

I have no knowledge of lua-scripting whatsoever, so I don't really know how to do that. Could anyone help? Much appreciated

http://www.discogs.com/artist/drexciya

 

elanovic

To fix it in an ever so 'hacky' way, find 'function Chronometer:SPELL_FADE' and replace this block:
Code:


if info.type == "fade" then
if info.victim == ParserLib_SELF then
return self:KillBar(info.skill)
else
return self:KillBar(info.skill, info.victim)
end



With this ...
Code:
if info.type == "fade" then
if info.victim == ParserLib_SELF then
return self:KillBar(info.skill)
elseif info.source == ParserLib_SELF then
return self:KillBar(info.skill, info.victim)
end



You'll notice the only thing that has changed is the else, which attempts to determine the source/owner of the debuff that is fading. As I described earlier, this is impossible, so the bars are never killed. The only problem with changing it in this way is that if your DOT is *genuinely* knocked off, the bar will not disappear. This is problematic with stuff like warlocks improved shadowbolt, Shadow Vunlnerability, that sometimes will have it's charges used before the duration is up. One way to address this is to add a new option definition when you create a spell/dot/etc, that when enabled, will have it's functionality returned to how Chronometer worked originally.

From wow-ace.com.

Happy dotting.

 

Gretten

That would also be something I wouldn't want, as I tend to just fire shadowbolts if DoT's are fading and ISB is up :p

However, I found this line while nosing around looking at things which make absolutely no sense to me:

if info.skill == BS["Banish"] then return end
if info.type == "fade" then
if info.victim == ParserLib_SELF then

As Troggy said there was a special case for Banish, and I seemed to find that line. Would it be possible to add Corruption, Unstable Affliction, Siphon Life and Immolate to this? If so, do I add the skills to ["Banish..."] as extras where the three dots are or in some other way?

http://www.discogs.com/artist/drexciya

 

Troggy

Yes, that's the function I changed. I just inserted similar lines for my DoTs like:

if info.skill == BS["Banish"] then return end
if info.skill == BS["Shadow Word: Pain"] then return end
if info.skill == BS["Vampiric Touch"] then return end

etc.

kinda hacky especially since I have no real grasp of LUA or WoW scripting in general but worked for me. It's been a while since I've been Shadow though and I haven't really needed it since.

 

Melador

Does the "chron /fade" toggle fix this without requiring code changes?