Feorthas

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).

 

Antiarc

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.

 

◊ Shalas

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

 

Antiarc

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

 

Feorthas

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 :-/.

 

Harem

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?

 

AC

So you might have someone who appears to have a huge amount of threat on a new target because of the accumlated global threat from a KTM source?

Would it make sense to parse for death messages of the target that KTM user is attacking currently and use that as some sort of rough threat clear for that person?

 

Antiarc

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.

 

Feorthas

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.

 

Antiarc

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.

 

Harem

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.

 

◊ castille

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.

 

◊ Praetorian

Well, it's clunky, but if you really wanted, you could make boss-specific functionality. Even if the combat log has no way of revealing that there are 12 mobs named Tidewalker Lurker, you and I know that there are 12. We know that the moment Morogrim emotes/quakes, there are 13 mobs on my aggro list, and if I heal someone for 2600 with no threat modifiers, that I am generating 100 aggro on each murloc and on Morogrim. As we see "Tidewalker Lurker dies" we know that this value is reduced by 1, until eventually there's just Morogrim left and all my heal aggro is going right to him.

Same with Solarian's 12 Agents, or Ragnaros's 8 Sons of Flame, or the 5 Hellfire Channelers on Magtheridon. On Magtheridon we know that Abyssals spawn based on the direct-damage spell effect associated with their arrival. And so forth. If you build in specific enough logic, customized per boss fight, you can accurately track threat among multiple mobs of the same name.

 

◊ Quigon

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.

 

• Daboran

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?

 

• Arawethion

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).

Carrot Cake Soup is like the taste of watching girls make out.

 

◊ Kalman

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.

http://mmorchive.net

The WoW forums, explained:

 

• Umph

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?

 

Antiarc

Umph: It would be pretty easy to turn off receiving/storing, definitely. However, there really shouldn't be much of a CPU hit from receiving events - it basically just stores the value in a hash, and what happens from there is up to whatever GUI you have hooked up to the lib. There's really no computation going on with the data. I'll test it out with reception disabled, but since you can run Threat "behind the scenes" without a GUI, I'm not entirely sure that you'd see too much of a boost from disabling data reception and storing.

 

Kamileon

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.

 

◊ Kyth

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 .

 

mek

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.

 

Antiarc