Sadly Recount is no longer actively supported according to it's forum thread and is glitching. I think it also sync's with omen through the Threat-1.0 library which is the basis of Omen without the gui front. Now if only I had some sort of coding skills.

Recount uses Threat-1.0, which communicates threat as it is accumulated.

And, uh, in looking for the code that you'd need to do this, I discovered that I did indeed put something like this in a long time ago.

That'll do it, though you'll have to run it on each login to make it take effect (or write an addon that runs that code on PLAYER_ENTERING_WORLD or something).

I apologize if this has been reported but we encountered non intended threat resets at Leotheras demon phase. He switches to demon phase and omen clears the threat list properly but after 5-10 seconds it occasionally clears the list again.

That sounds like a problem with a delayed clear message. Check to see if anyone in your raid is running a high-traffic addon (like DoTimer - FuBar_AddonSpamFu will help you see this), and you have your culprit. If they can disable it, that should fix the problem.

I'm working on a more complete fix for it, but that's your band-aid for the problem.

I've experienced the same issue, but only on Leotheras which is a shame since Leo is the only boss I still have to bring KTM up for. Not sure if it's an addon traffic issue though since casters were asked to update Dottimer a while ago since I believe the addon message spam was fixed in a later version.

Though if it was addon message spam, wouldn't it also affect other fights and not just Leo?

I'd expect it to, but it may just be a corner case wherein Leo is causing more traffic than normal or something, causing people to bump up against the limit. At any rate, I'm working on a more permanent fix that should address such problems in the future.

At this risk of asking you to spill trade secrets, what did you do to handle the zero threat on Lightning Overload procs? I am asking, not because I doubt that you did it successfully, but because I would like to try and translate the code to be more effective in recognizing LO / TLC procs with Shaman's Friend. At the moment, it shows a lot of false positives, which makes accurately tracking the total damage from the trinket and/or the LO almost impossible.

Basically, I'm watching UNIT_SPELLCAST_SUCCEEDED for a Lightning Bolt cast, and set a flag, which is then consumed when Lightning Bolt damage (or a miss event, like resist/immune) is registered. Any Lightning Bolt damage events that occur when the flag isn't set are considered LO procs - only LBs that the player specifically cast produce threat.

Chain Lightning is a bit more difficult because each cast can produce multiple threat-causing damage events. Basically, I set a flag when CL is cast, and record the time when the first damage event after that is recorded. Any subsequent damage events within 0.045 seconds are considered to be a part of the original cast. I did a lot of testing with a friend's shaman under multiple latency conditions (BitTorrent is a wonderful tool for producing such conditions! ), and arrived at that number as a relatively safe event delta, even under laggy conditions. I suppose it may break under extremely latent conditions, but that should very much be a corner case, and there isn't much better that I can do, I think.

The code is in the Shaman module in Threat, and it's licensed under the LGPL, so you have moderately free license to borrow and use the code as you like.

Edit: TLC procs are still a pickle and a half for me, though. I don't believe they're handled correctly for Shaman, though they are for all other classes. Right now, the TLC will result in the shaman's threat registering slightly higher than it actually is, which, while frustrating, is better than the converse.

Edit again: Though, thinking about it, my LO code may have inadvertently fixed it. I should test!

Have a look in you addons folder and check if Threat-1.0 is actually there. I know it sounds silly, but I had to whitelist some libs in JWoWUpdater because it kept removing libs it thought were not used anymore even if they were.

Can it be made so that individuals can be 'banned' from your Omen window. Like, I just want to see bears, and not trees.

I believe Kalroth took over for Recount and is actively maintaining it now.

Not currently, but it's on the potential feature list.

Yeah, it's there. It's in its own folder (Interface/Addons/Threat-1.0), if it's supposed to be somewhere else. I don't have separate folders for any of the other Ace Libraries, they're all in Addons/Ace2.

What's under the Threat-1.0 folder?

Threat shows up in the addon screen as "Lib: Threat-1.0", I believe.

I've had this problem for a while (might be through the whole life of omen, only recently started leveling alts). With most ace addons, when I copy the user folder inside (ie: <wow>\WTF\Account\<account>\<server>\<player>) and rename it to my alt's name, when I load up wow with the alt all of the ace addons will inherit the settings of the folder I copied. With omen, nothing gets inherited, and when I try to copy the profile from my main, none of the settings get applied.

It's a small problem but I'm sure there's an easy fix to it.

This may be my lack of LUA coding ability but today our shamans in particular were complaining that Omen didn't seem to be registering their new fancy threat reduction talents.

Please correct me if I'm wrong...

I took a look at the code and it does a check to determine if we're in 2.3 and then applies the new threat modifiers as follows:

ect and as you described for lightning overloads above.

My concern is this new 2.3 based code doesn't seem to be executing. To confirm this if you change line 542 in Threat-1.0.lua

to read 2.3.0 instead of 2.2.0 then you get an error in the Paladin.lua that refers to rank being a string but being used like a number.

To fix this error I changed "rank" to "currentRank" and it all seems to work fine and our shamans no longer complained that their threat seemed higher than it should have been.

Once again I'm sorry if I'm mistaken I'm extremely new with LUA and thanks in advance

Doh, I completely missed that. I should have included GetBuildInfo() there, rather than the string "2.2.0".

The paladin thing is also my fault; that should be:

select(5, GetTalentInfo(3,21)) - otherwise you get a string back.

Fixes for both are committed.

Thanks a ton for the heads up. I feel kinda foolish now :P

I'd like to request a feature if it's posible. An option for checking newer versions with 3 possible stage:
-red text under the omen window (current state of omen)
-popup window (the red text disappears and whenever you join a raid that has a member with newer version of omen, you get a popup message that tells you your omen is not up to date)
-turned off (no red text, no popup message)

Don't know if it's because of the patch, but I now get Lib:Threat-1.0 to show up on the addon screen. Still get the same error in-game, though.

Just a sidenote to the more official response.. you *can* do this in a more brute-force way. If you ignore the other player, you won't receive their sync messages. It may require both people to ignore each other. While this is obviously impractical for most people, it is an option.

Found this out in a weird way.. 2 of the people I raid with had each other on ignore and couldn't see each other on Omen. It was rather interesting considering one was a tank and the other a fairly threat-capped dps'er. I remember being asked to warn the dps'er if he got too high (since I could see both players)...

It's sufficient if the person that wants to "clean" his/her list ignores the persons he/she doesn't want to show up. Thinking two seconds about it makes clear why this is so. You are discarding someone's sync messages by ignoring him. He/She ignoring you wouldn't stop him/her from broadcasting his/her threat on the sync channel. I myself stumbled over a similar behavior in Cartographer_Guildmates (or whatever the module is named that shows guildmates on the world map)