------------------------------------------
(original post follows this line)
------------------------------------------
I just started writing Omen3 today. Lol.
At the moment, all it has is a non-configurable "SingleTarget" mode, nothing else, no fancy stuff, no combat log parsing., doesn't sync, has no config, and uses pure Blizzard threat events and values. (No its not uploaded anywhere yet.)
One problem is that Blizzard's threat events doesn't fire on units you aren't actually in combat with, so if one party member engages a mob, you didn't enter combat yet, Omen3 wouldn't actually display anything because wow would refuse to tell you any threat information on that mob until you start doing damage to it (it doesn't work if you send your pet to attack it, you have to attack it).
So maybe some form of syncing is still required. Ugly. Another problem with Blizzard's new threat API is that you can't obtain threat on a unit that you or one of your party members isn't targetting. This might mean raid scanning, which is highly costly with CPU time.
Xinhuan, perhaps it's possible to - I hate myself for suggesting this, but maybe it will be less costly than the cpu time on raid scanning - have those in raid with Omen3 send treat to the others (with a - oh god here it goes) comm channel. Or was that what you meant?
It's faster, but the problem is with its inconsistency. If nobody in the raid is targeting mobX, then you can't query anybody's threat on mobX because you don't have a valid unitID on it.
The main problem here I'm getting is this (as of the current beta build 8982):
If you aren't in combat with a mob, Blizzard's threat API returns all nils. Even if you send in your pet to attack a mob, and that automatically puts you in combat as well, Blizzard's threat API still returns all nils with that mob, until you do at least 1 damage to it yourself, or buff yourself to generate some amount of threat.
The good and ugly stuff:
If you body pull a mob, you are considered on its threat list and will get every threat update on it even if you remain at 0 threat.
If an NPC is tanking it, you can get the NPC's threat values (since targettarget) is a valid unitID. If the NPC stops tanking it (such as at Kalecgos in the demon realm), then you can't query the NPC's threat on the mob until you have a valid unitID on it, such as a raid member targeting him (which would then require raid scanning).
What this means is, if your main tank starts pulling a mob/boss, you can't see how much threat anybody has on that mob until you do an action that causes more than 0 threat on it (such as buffing) - sending your pet in doesn't count, you can't see your pet's threat either until you get on the mob's threat list.
If the whole idea of Blizzard's threat API is to avoid parsing the combat log and avoid syncing, its failing at the moment.
I don't actually see a problem with that.
From the way you describe it, only people who are AFK (by nature trivial as a "problem") or who would send their pet in without attacking themselves would notice this.
And I can't see the latter happening often. Maybe for Hunters or Warlocks for the first 1-2 seconds of combat, but does that matter to them. Or do you drop off the Blizzard threat-updates again when you don't change your threat for X seconds?
It just seems odd behavior. Suppose a boss encounter has 4 mobs. You spend 3 minutes killing the first one, then switch to the second one. You wouldn't know how much threat anybody has on the 2nd mob until you start attacking it (although it isn't really an issue, it just seems odd behavior).
I don't see the "big" problem with not getting any data before you enter the combat actively. I wouldn't put syncing in just for that.
the reason is probably that on the server the threat data is send from the mob-object to all objects in his hate list... so if you're not on his list you get no data.
It just seems odd behavior. Suppose a boss encounter has 4 mobs. You spend 3 minutes killing the first one, then switch to the second one.
i doubt that because on most of those encounters you will get on the hate list of the other boss mobs much earlier, probably when you are in range. Maybe it's not the case with kalecgos but that's a special case.
I know ktm/omen tend to produce knee-jerk reactions but it wasn't my intent :)
It was mentioned as a reinforcement of what you already mentioned above.
(that other threatmeters are doing the same)
"opted for" was a bad choice of words admittedly; sorry for confusion.
Just a suggestion, as I don't really know much about mod writing, but is it not possible to send untiID's to each other via a comm channel or something? Raid scanning is CPU intensive, but if omen3 can send unitID's to each other would it be any better proformance wise? Assuming it does work, the only disadvantage i see is it requires everyone to run omen3 to be able to send unitID's to each other. Players have for years have gotted used to all using the same threat meter, so it's not exactly a major problem to for a raid to all use the same threat meter.
On a side note, using ZTM in native mode, I have always found that it never returns any threat info about mobs that are not tagged by you (grey name), even if you attack and damage it.
Omen3 will have threat data on grey tagged mobs - as long as you're in combat with it, you have threat info, otherwise you don't.
As for sending unitIDs to each other, that wouldn't work, because the numbering of the raid members is client side. The 7th person in the raid on your screen might not be the 7th person on another person's screen, depending on how it is sorted for display. Also, you are always the last person in your party when in a raid group.
It just seems odd behavior. Suppose a boss encounter has 4 mobs. You spend 3 minutes killing the first one, then switch to the second one. You wouldn't know how much threat anybody has on the 2nd mob until you start attacking it (although it isn't really an issue, it just seems odd behavior).
mhh ... is heal-threat beeing shown ?
I mean, ok, it is a problem for DD not to know before they start, how many threat the tank has ... but i guess healers have to worry more about that.
mhh ... is heal-threat beeing shown ?
I mean, ok, it is a problem for DD not to know before they start, how many threat the tank has ... but i guess healers have to worry more about that.
Sorry .. I have to admit that threatmeters are very handy on long fights .. but if you can't judge your threat in the first 20 seconds of a fight I can only say: Learn to play.
A warlock should know that he better not open a fight with a shadow bolt when the tank is still running to the mob, and the same goes for healers.
mhh ... is heal-threat beeing shown ?
I mean, ok, it is a problem for DD not to know before they start, how many threat the tank has ... but i guess healers have to worry more about that.
Heal threat will be shown correctly because casting a heal generates threat on all mobs and places the healer on all the mob's threat lists.
Yes Astaldo, because raid scanning is the *only* way to find valid unitID tokens for various mobs and things that people target.
That, and the author of KLHTM has historically been less concerned about CPU usage than I'd like. Having a lightweight alternative in the form of Omen3 is worth living with some limitations for a while, especially if it helps focus community attention on pressuring Blizz to improve the API :p
So basically your saying is that we will not be able to see what the main tank's threat is unless we throw something at the boss. So for example I'm looking at Gurtogg, MT pulls and I'm still seeing nothing on Omen3. However if I throw up an Ice Lance at Gurtogg, I'll see what the MT's Threat is?
Also I understand the UserID's are client side, but is there a way to get the name of each of the users/pets in the raid? If that is the case, wouldn't that help to match who is NOT on the Threat meter and who is, and send the Threat information to the people who are not on the Threat meter?
if you look at the one side what you have to do to make it work and on the other side what you gain from it, i'd say no syncing just for that.
You don't need a threat meter to see if the tank hit the mob.. you can see if sunder armor is on the mob or could have a small addon parsing the combat log just for the tank or stuff like that.
don't add bunch of code only to be able to show threat the first 5 seconds of the fight...
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
http://www.wowace.com/projects/omen-threat-meter/
http://wow.curse.com/downloads/wow-addons/details/omen-threat-meter.aspx
http://www.wowinterface.com/downloads/info8459-OmenThreatMeter.html
Localization is still needed for most languages.
------------------------------------------
(original post follows this line)
------------------------------------------
I just started writing Omen3 today. Lol.
At the moment, all it has is a non-configurable "SingleTarget" mode, nothing else, no fancy stuff, no combat log parsing., doesn't sync, has no config, and uses pure Blizzard threat events and values. (No its not uploaded anywhere yet.)
One problem is that Blizzard's threat events doesn't fire on units you aren't actually in combat with, so if one party member engages a mob, you didn't enter combat yet, Omen3 wouldn't actually display anything because wow would refuse to tell you any threat information on that mob until you start doing damage to it (it doesn't work if you send your pet to attack it, you have to attack it).
So maybe some form of syncing is still required. Ugly. Another problem with Blizzard's new threat API is that you can't obtain threat on a unit that you or one of your party members isn't targetting. This might mean raid scanning, which is highly costly with CPU time.
The main problem here I'm getting is this (as of the current beta build 8982):
If you aren't in combat with a mob, Blizzard's threat API returns all nils.
Even if you send in your pet to attack a mob, and that automatically puts you in combat as well, Blizzard's threat API still returns all nils with that mob, until you do at least 1 damage to it yourself, or buff yourself to generate some amount of threat.
The good and ugly stuff:
If you body pull a mob, you are considered on its threat list and will get every threat update on it even if you remain at 0 threat.
If an NPC is tanking it, you can get the NPC's threat values (since targettarget) is a valid unitID. If the NPC stops tanking it (such as at Kalecgos in the demon realm), then you can't query the NPC's threat on the mob until you have a valid unitID on it, such as a raid member targeting him (which would then require raid scanning).
What this means is, if your main tank starts pulling a mob/boss, you can't see how much threat anybody has on that mob until you do an action that causes more than 0 threat on it (such as buffing) - sending your pet in doesn't count, you can't see your pet's threat either until you get on the mob's threat list.
If the whole idea of Blizzard's threat API is to avoid parsing the combat log and avoid syncing, its failing at the moment.
From the way you describe it, only people who are AFK (by nature trivial as a "problem") or who would send their pet in without attacking themselves would notice this.
And I can't see the latter happening often. Maybe for Hunters or Warlocks for the first 1-2 seconds of combat, but does that matter to them. Or do you drop off the Blizzard threat-updates again when you don't change your threat for X seconds?
the reason is probably that on the server the threat data is send from the mob-object to all objects in his hate list... so if you're not on his list you get no data.
i doubt that because on most of those encounters you will get on the hate list of the other boss mobs much earlier, probably when you are in range. Maybe it's not the case with kalecgos but that's a special case.
I know ktm/omen tend to produce knee-jerk reactions but it wasn't my intent :)
It was mentioned as a reinforcement of what you already mentioned above.
(that other threatmeters are doing the same)
"opted for" was a bad choice of words admittedly; sorry for confusion.
On a side note, using ZTM in native mode, I have always found that it never returns any threat info about mobs that are not tagged by you (grey name), even if you attack and damage it.
As for sending unitIDs to each other, that wouldn't work, because the numbering of the raid members is client side. The 7th person in the raid on your screen might not be the 7th person on another person's screen, depending on how it is sorted for display. Also, you are always the last person in your party when in a raid group.
mhh ... is heal-threat beeing shown ?
I mean, ok, it is a problem for DD not to know before they start, how many threat the tank has ... but i guess healers have to worry more about that.
Sorry .. I have to admit that threatmeters are very handy on long fights .. but if you can't judge your threat in the first 20 seconds of a fight I can only say: Learn to play.
A warlock should know that he better not open a fight with a shadow bolt when the tank is still running to the mob, and the same goes for healers.
Heal threat will be shown correctly because casting a heal generates threat on all mobs and places the healer on all the mob's threat lists.
That, and the author of KLHTM has historically been less concerned about CPU usage than I'd like. Having a lightweight alternative in the form of Omen3 is worth living with some limitations for a while, especially if it helps focus community attention on pressuring Blizz to improve the API :p
Also I understand the UserID's are client side, but is there a way to get the name of each of the users/pets in the raid? If that is the case, wouldn't that help to match who is NOT on the Threat meter and who is, and send the Threat information to the people who are not on the Threat meter?
You don't need a threat meter to see if the tank hit the mob.. you can see if sunder armor is on the mob or could have a small addon parsing the combat log just for the tank or stuff like that.
don't add bunch of code only to be able to show threat the first 5 seconds of the fight...