TPS is very useful when comparing gear setups in terms of threat and is frustratingly absent from the current lineup of TBC threat addons.

Just throwing in my 2 cents, as I came here and submitted the same request for TPS. I currently use a Weak Aura for TPS and the way it is calculating works great on bosses if you are the MT, but on bosses like 4 horsemen, where you are not tanking for extended periods of time, it starts showing very low TPS when you start tanking again. I think it would be great to have a TPS calculator that you could adjust, as was mentioned in this thread. Even just a rolling 5 second average of TPS would be useful to see for some encounters.

Came here to request this feature too. Was trying to calculate the threat difference between Thunderfury and Honor's Call and couldn't find a threat meter that displayed tps...

@dfherr

I think you misunderstood me. For me TPS would be time a mob entered the fight and eventually died and the combat time is for all players the same for that enemy. Tracking individual time for every player gets even more complicated. I'm thinking of TPS similary as DPS is displayed in a damage meter. I.e. if you have higher TPS you are also always higher on threat as everyone started the fight at the same time. (Edit: there are many situations that are hard/impossible to judge correctly always. Healing is one example. A Paladin blessing is another example. A hunter's mark would be a debuff that doesn't start combat, etc. It's really hard to indentify start of combat and the only easy option is to track first damage, which will show completly wrong TPS values in certain situations)

Yes the combat information is from the combat log. There is no identifier in the combatlog on entering combat (except for raid bosses that trigger a special event for that). So I would have to make an educated guess when that happens. The threat API works only on specific targets (e.g. target, targettarget, focus, focustarget, raid1target, and so on) so you could scan for enemies being there and that's something the threat library was doing as well for certain situations. However, please understand that I don't want to add major computational bloat to this addon to cover some edge cases for a feature that' irrelevant for the main use case of this addon (that is keeping track of when you will get attacked).

In comparison, simply using start of combat/end of combat information that's very easy to do. There is an ingame event that tells me if a player entered or left combat and I can just track that with a single variable and use that information to calculate TPS. for your testing purposes and raid bosses that would be more than sufficient and for adds it will be wonky, but at least pretty obvious.

I see what you mean now, yeah. It's certainly a niche feature given that the Blizzard APIs don't really provide enough info to make it completely accurate, but for the simple purposes of testing items or solo fights, enter/leave combat is probably good enough.

I saw this and i'm thinking about it.

however, TPS information is not directly available and while identifying start of combat and end of combat is easy, identifying start of combat/end of combat with one particular unit is difficult and will no be implemented. That means I can not add accurate TPS numbers in all situations.

So that leaves adding TPS values from start to end of combat, which is at least accurate for boss enemies. I don't think that value will be useful for comparing gear as on a low sample size RNG influence will always outweigh a few gear pieces (that's why we have simulators for gear comparison on DPS classes too), but as it's rather straight forward to implement, I'll see what I can do.

Sample size needn't be low. Whacking those invincible mobs in blasted lands for as long as you wish would smooth out most fluctuations in rng the longer you allow your tests to go on.

Does Blizzard include unique identifiers for units? If I recall, prior to Blizzard enabling the threat API, libthreat was able to discern between individual mobs to keep track of threat on each unit. Is that no longer possible with the threat API, or would it just require reimplementing some of libthreat's functionality?

There are unique identifiers and identifying when one mob dies is actually easy. However, identifying when one mob entered combat is pretty hard. He could add and the first threat on him is a heal for example. I have no way to know that. So the numbers would also be somewhat wrong and I really don't like adding something that only sometimes works.

That makes sense. Do you get that data from the combat log (or some combat API)? If so, would it be possible to keep track of the time that someone was added to a mob's threat table? As you said, it doesn't really help if a healer causes a mob to enter combat and you don't whack it for several seconds afterwards, but your tps counts the time you weren't actually interacting with the mob.

I think you can largely get around the "when did combat start" tracking problem by choosing to show TPS not as the total per fight, but instead as a moving average of TPS within a sliding window of the last x seconds, which the user can configure. In this case it doesn't matter so much if you make an incorrect assumption about when that individual mob entered combat, as incorrect assumptions fall off the window.

@chrismackey i actually like this idea, but if I completly disregard when combat started and lets say have a 10 second time window, I would see incorrect TPS (or slowly ramping up TPS) until the window is filled, which isn't really TPS then but more like TPS_(in time window). might still be a cool feature.

However, that will be hard to get right. I only get threat as a current sum in total and in non-fixed intervals and I only get those for the current target (if I don't want to start nameplate and raidmember target scanning). So actually knowing how much threat was added in the last x seconds is non-trivial.

Right, that "ramping up" behavior would be present if you always assumed there was a 10 second period before the current point in time. This wouldn't be terrible, but I don't think it's hard to get around either. The point of there being a sliding window is not that you can completely ignore the time in which you initiated combat against a specific mob, rather it lets you make an assumption and not care if it is wrong.

I completely agree about avoiding scanning for mobs. That's a huge amount of extra complexity with limited value in most cases. I wonder if this could be made really simple even without introducing the sliding window period. You've already mentioned that it's easy for you to detect the start of combat, so the only problem with a TPS output that used that would be wonky TPS values on adds that spawned midway through the fight. What if the displayed TPS is only relevant until you switch target? I assume you can detect when the player changes target? TPS resets like this are something that are valuable as well even when the player does not switch target - any fight with a threat reset for example, should be to a large extent discoverable by you, with a simple comparison of previously known threat value vs what it is now.

So the behaviour could be:

• Introduce two new variables: threatTrackingStartTime, threatTrackingStartValue
• On start of combat, threatTrackingStartTime is set, assuming the player has a target
• On start of combat, threatTrackingStartValue is 0
• TPS is calculated as (currentThreatValue - threatTrackingStartValue) / (currentTime - threatTrackingStartTime)
• When changing target, threatTrackingStartTime is reset to the current time
• On first poll of the new target, threatTrackingStartValue is set to the current threat
• The previously mentioned TPS calculation now shows your TPS after you switched target. If you do not switch target, it shows the TPS for the entire encounter.

Furthermore, this adjustment in how TPS is calculated can be used by the addon itself, in some smart detection of threat resets. If you can observe threat values dropping to near 0 across the board, you can assume that is a threat reset, and trigger the same logic as above without requiring a target switch.