Jump to content


Photo

DoT/HoT Timers and API's


  • Please log in to reply
5 replies to this topic

#1 Shkarn

Shkarn

    Von Kaiser

  • Members
  • 44 posts

Posted 08 May 2008 - 04:14 PM

I remember a while back there was a post mentioning some DoT Timer addons (like Chronometer) don't use the Blizzard API while others (ClassTimer) do. I tried searching for API information here, but I didn't have luck. Do we have a comprehensive list of all the "timer" addons that use the Blizzard API or a list of those that don't use the Blizzard API? My goal with this thread is to get a list of addons we can consider the most accurate DoT/HoT tracking addons. Here are the one's I'm aware of so far:

Uses Blizzard API
ClassTimer

Does not use Blizzard API
Chronometer

Unsure
DoTTimer
ForteWarlock
HoTCandy
Natur

What other DoT/HoT addons do people use that have information on?

#2 funkydude

funkydude

    Piston Honda

  • Members
  • 151 posts

Posted 08 May 2008 - 07:05 PM

You can't 'not use the blizzard API'.

At I guess you're referring to the difference between using the combatlog and the UnitBuff()/UnitDebuff().

Since 2.4 it really doesn't mater which you use, before 2.4 Unit* API was superior.

EDIT: Keep in mind they both have downsides and upsides, but at the end of the day they equal the same. For example using the combatlog would mean needing a library of durations which isn't needed with Unit* but using Unit* restricts your targets.
Author of BadBoy, BigWigs, and more...

#3 Shkarn

Shkarn

    Von Kaiser

  • Members
  • 44 posts

Posted 08 May 2008 - 08:16 PM

How is it, then, that some timers won't always accurately track the DoTs? Back in early T5, we were having a debuff issue where we thought we were hitting the limit, but found out that the dot timers people were using were dropping the dots before their duration was up. Chronometer was the big culprit of this, but ClassTimers has been (from what we can tell) 100% accurate. If they're using the same API, wouldn't the timers theoretically be 100% accurate all the time, or is there that big of a discrepancy between using the Unit* procedure calls and referencing the combatlog?

Ultimately, I'm aiming to provide a set list of how each of these DoT/HoT timers function for the purpose of finding the ideal timer(s) to use and not drop HoTs or DoTs from the target(s).

#4 Margot

Margot

    Von Kaiser

  • Members
  • 88 posts

Posted 08 May 2008 - 08:19 PM

WoWInterface Downloads : Plug-Ins & Patches : Sorren's Timers (2.4)

Sorren's Timers uses unit ids and tables of durations as funkydude mentions. Gets stack sizes on your buff/debuffs through Blizzard buff api, however.

#5 Silverstorm

Silverstorm

    Piston Honda

  • Members
  • 119 posts

Posted 09 May 2008 - 11:51 PM

How is it, then, that some timers won't always accurately track the DoTs? Back in early T5, we were having a debuff issue where we thought we were hitting the limit, but found out that the dot timers people were using were dropping the dots before their duration was up. Chronometer was the big culprit of this, but ClassTimers has been (from what we can tell) 100% accurate. If they're using the same API, wouldn't the timers theoretically be 100% accurate all the time, or is there that big of a discrepancy between using the Unit* procedure calls and referencing the combatlog?

Ultimately, I'm aiming to provide a set list of how each of these DoT/HoT timers function for the purpose of finding the ideal timer(s) to use and not drop HoTs or DoTs from the target(s).


As funky said, you have to use the Blizzard API for this. The difference between all these timer mods is *which* APIs you use and the logic with which you use them. I haven't investigated all of them, but I would be very curious to see how the timer detection is done for any mod that claims to have 100% correctness. The reason for this is the information exposed by the various APIs varies, and it is very difficult to get a complete picture from the combat log because several relevant events are missing information that Blizzard has, but providing it would totally unbalance things like PvP.

Funky's basic analysis of the two methods is spot on, based on my own experiences with writing a DoT Timer. UnitBuff and UnitDebuff are very complete in their information, but can only be called on targets that can be referenced through tokens like "player", "pet", "target", "raid1", "party3", "party3target", etc. Additionally, they require scanning all the (de)buffs on the target to determine which are yours. The combat log, on the other hand, will provide information about every spell or ability used, but rarely does it ever provide all the information you want in one single event. It's up to the addon author to analyze the information available which involves detecting casts/attacks, determining possible targets, and correlating the sequence of combat log events that correspond to one cast/attack to come up with the right information.

I'm still working out the last few idiosyncrasies of the logic involved, but I almost have a functional DoT Timer that I will make available once I can get through an entire raid or two without it missing things! Everything it does do is correct, but it's missing a couple events here and there, and I don't know why yet (though I have a couple ideas)!

As far as the list goes, DoTimer uses the Blizzard APIs, but I'm unsure which APIs. I do know that last I checked (recently), it did not use 2.4 combat log.

#6 Kalman

Kalman

    Super Macho Man

  • Members
  • 8,791 posts

Posted 13 May 2008 - 04:46 PM

Yeah, pretty much it's the difference between detecting cast/hit/resist and using a predetermined table to pull duration data and using the debuff/buff scanning functionality added in 2.3.

I code DotDotDot - Index of /DotDotDot/ - which uses UnitDebuff to pull duration data and the 2.4 combatlog to handle removal/cleanse/death.
Melador> Incidentally, these last few pages are why people hate lawyers.
Viator> I really don't want to go all Kalman here.
Bury> Just imagine what the world would be like if you used your powers for good.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users