That's what I figured... I guess there's no way to do a quick parse and 'correct' for target-specificity anywhere in there? (without making a ton of work for yourself that is)

mildly off-topic: what language is LUA most like? I've found that I need to code a LOT more than I thought I did in order to stay sharp while I'm interning at a non-coding job so I'm looking for pretty much anything that'll keep me mildly functional with C-like code (C/C++/Java/C#/etc).

Trying to correct for targets is problematic in a very large number of ways - enough that I'm not going to attempt it.

Lua's a relatively unique language, but if I had to describe it I'd say it's basically a more verbose loosely-typed C-like scripting language.

Javascript would probably be the closest language. Lua has pretty much nothing in common with C other than some superficial syntatic elements.

In fairness, you could call Javascript a loosely-typed C-like scripting language.

That's unfortunate; I'd love to do a little LUA coding here and there but I'd rather not learn two somewhat new languages at the same time :-/.

Dynamic typing scares me.

Antiarc: Any word on how you will handle newly spawned mobs that have not been damaged yet and healing aggro (such as the murlocs on Tidewalker)? Since there is no combat log entry for them spawning or anything, how will Threat-1.0 know to create a table for them to add to the global list of tables to split healing aggro across? I'm guessing it will pop up as soon as someone debuffs them/damages them directly?

Harem: For that scenario, there isn't a whole lot you can do. Healing threat is assumed to be on all mobs that Threat knows about, which means that healers are going to register a lot higher on threat than everyone else at that point, though they actually aren't. Healing threat isn't split between targets or anything, specifically because there's no good way to guess how many targets you might actually be in combat with.

However, there may be a GUI solution. In I can find specific triggers that signal murloc phase start/ends, then once the first is detected, the GUI could suppress all global threat up to that point, effectively providing a temporary "reset" of the meter for the murlocs. Once it's over, the meter would restore to normal. However, even this is iffy, since you won't be able to distinguish between individual murlocs, meaning that your DPS's threat numbers will be inaccurate to the point of being useless on individual mobs.

It isn't a very threat meter-friendly fight.

That would be my moderately uneducated guess; last night it appeared to track every mob that is actively hostile to the current player (or another player in the raid with Omen) and applied threat correctly, albeit with the wrong numeric value, to said mobs (it seemed to be underestimating things a lot but this was an early-ish build... no newer than 7p EST yesterday). I never saw it actually assign threat incorrectly or make large enough errors such that I was below/above someone else when I shouldn't have been though so I'm guessing the problem was on my end more than anything else.

Just in-case a scalar was left out, bears generate 1.3 (+addl 15% from a talent--unsure whether it's an addl *1.15 or +0.15) threat per damage and Bear mangle generates an additional ~1.15 (unsure about value) multiplier as of the most recent patch.

Correct. This is KTM's behavior without a master target as-stands right now, I believe.

No, not particularly, because of DOTs, AOEs, and target switches.

If I'm a priest and do threat to the Curator, drop a few DOTs on him, switch targets to a spark, and kill it, I have:

a) direct damage threat on Curator that gets cleared incorrectly
b) DOT damage threat on Curator that gets cleared incorrectly
c) VT/VE global threat on all targets that gets cleared incorrectly
d) Spark damage threat that gets cleared correctly

So now we've lost all our global threat and our Curator threat, and are reporting far under what our actual threat level is.

It would be easier to sorta-guess if there wasn't global threat to account for, but AOEs and DOTs would make that tricky as well.

Short answer, no, I don't think it makes sense to try to think for KTM. I think the best solution is just display it with some kind of symbol that indicates that it's coming from KTM and not Omen, so that the user is aware that it is not correct if there are multiple targets and there's been a target switch.

Yes, Tidewalker does sound unfriendly. Another issue would be differentiating the waves from each other, though you're right, a boss-specific thing could fix the issue nicely. On earthquake, create the table for the murlocs, or wipe it if it already exists. This way, a healer could target a murloc and spam cast until he beat all the other healers, and the murlocs would come to him. The relative threat would be correct. I bring this up so much because we have trouble with getting a paladin with RF up and no salv beating our shadow priests some times, and it would be pretty easy for the shadow priest to stop attacking their target if they are close to the paladin, or continue if the paladin has a significant lead.

However, doing boss specific acts like this kind of sucks, but theres no way around it really.

It may seem odd, but .. why bother trying to accomodate KTM's global threat? Does KTM continually aggregate the threat internally, or is it the report that gets updated? If it's just the report that gets updated, then your threat would be most accurately depicted vs your current target, and that's what gets reported to KTM, not global threat (which really sucks, mentally having to remember what number you were at, what number that particular MT was at, etc).

Why not just do all the math you would have to do per single target, and have only the current target being the amount of threat that is sent via the KTM channel? Your threat numbers would seem lower to those who watch KTM, but I don't see why you have to maintain the same 'conglomerated threat' model.

For multiple targets: We just run an internal mod that switches your master target for a subset of people in KTM, as opposed to everyone at the same time - like for 4H, it was relatively accurate.

Forgive me, but all this seems a lot of work to incorporate KTM? I'd worry about Omen users only and devil take the hindmost, or is there a good reason you want interoperability?

The problem here is that it's so precarious. A single missed death event will ruin the threat readings for all healers.

We've done just fine with KTM, without heal-threat splitting. I convinced myself the first time I realized that healing threat was inaccurate, that there was no good solution. So long as you're aware of it, it doesn't cause a problem (if people aren't aware of it, though, it can cause confusion, like the Priest kiter thinking he was going to pull aggro at Gluth).

A combination of the network effect and human nature, basically; oRA took off because it was CTRA compatible, so you could use it without having to convert your entire guild, and it would just work with what was (is) the established standard.

Yes, if you're the guild *leader* it's easy to mandate a change, but if you're just a raider, being able to switch over and have a superior, *compatible* solution while you work on convincing your guild leader to mandate the change is quite valuable.

This is going to sound like an oddball request, but here goes. I spend most of my time tanking, and as such I'm usually building the maximum threat I can at any given moment so I'm not too fussed about who is where in threat provided I am building the maximum I can - which is a player issue.

Is there any chance of a send-only version of the Threat library (or Omen if applicable), or is this not something that will reduce my CPU usage in raids?

This looks awesome. Now, how do I convince my guild leader to switch over to Omen?

As always, hit me up if you want anything tested.

What will the chance be of multiple front-ends being able to be easily written on top of the base engine? I love KTM dearly, but the display has never been that useful to me (having to compare two bars; at least I can filter by class now.)

Perhaps some concept of being able to set "the names I care about", not just classes? (so I don't have to view all the druids just to know where our druid OT's threat is.)

And..... a pie chart, or a bar filling up, or something that represents "my threat until 100%" and "my threat until (110%/130%)". Maybe something like a casting bar, with a red bit at the end like Quartz does for lag. Some sort of "up close and personal" threat view, just me and the guy who matters . I don't care the tank's total threat or TPS so much as I care my percentage of his, and my velocity relative to him.


Also I echo perhaps considering some of the logic that DoTimer uses to distinguish between targets by raid symbol (although it's imperfect, it's pretty darn useful if you just march through symbols rather than re-symbol'ing each time to mark the new kill target.)


I'm hoping some of my guild, including our main tank, will install this to run along side KTM for tomorrow's SSC raid .

Seems easy, actually. A bossmod (Bigwigs) would "know" when those mobs are being added to the encounter, as it's precisely indicated by the earthquake - and the number/type of mobs is also exact. So it could simply add them to the list of mobs Omen is tracking via a function. So no clunky boss-specific functionality is necessary; simply allow Bigwigs to add new mobs to the threat list when they are spawned, so Omen starts tracking their threat at the appropriate time.

A single missed death event will potentially ruin any threat reading for any character? I fail to see how this is a problem, or how a death event would be missed in the first place. An entire raid running 30 yard combat logs and a mob that gets feared out of range and dies to dots? Heh.

Haha, good luck there. I heard that guy's a real dick.

Excellent. ThreatLib is a library explicitly so that you can write any frontend you want for it. Violation already includes a thread module based on it, and Omen, of course, displays it, so that's two right there.

Installed it and did some primal farming with our elemental shaman. His complaint is that he cannot see a total threat count, and he'd be quite annoyed if he had to use it on raids.

Apparently the way he deals with not having dots but trivially out-threating tanks is that he switches to an offtanked mob, watches to see when the first tank gets a 6-8k threat lead, and then switches back.


I'm not saying his use case is necessarily important, just passing on the interface feedback. He's one of our officers, alas .

That's an interface issue - you could easily have two threat windows for two targets.