Omen - Ace Threat Meter - Page 5

Elhana · 05/30/07, 12:20 PM

Originally Posted by Harem

Correct me if I'm wrong, but wouldn't a simply Ace'd KTM be better than a non-Ace'd version, assuming you are already using a certain number of Ace mods? For example, just using ParserLib to get the events to act upon rather than redundantly parsing itself?

The only thing that would help is Parser being shared with the other addons you use (if any!?), however it might also happen that it would actually come out worse if let's say you are using only 1 addon utilizing parserlib (being aced KTM) and it won't use all the functions provided by the library - then it will be a waste of memory. CPU utilisation would probably stay the same if not come up abit due to the fact that functions in Parser lib might do the job unnecesary for that aced addon.

Problem is that people clueless about how programs work read too much wowace wiki and now assume every ACEd addon is damn cool, which is in fact wrong.

and offtopic about optimisation:
1)"There is no such program which you can't shorten by atleast 1 line of code"
2)"Every program has atleast 1 bug"
which leads us to the fact that every program can be cut down to 1 line of code which contains a bug :p

Antiarc · 05/30/07, 12:29 PM

Originally Posted by Malan

I did notice something a little odd for shaman. I went out and earthshocked a mob and the threat did not equal the damage done. (thread modifier for shaman on earth shock was removed and added to frost shock) It wasn't like it was having a large threat modifier added to it, but the threat and the dmg done by the shock did not equate, they were something like 50-100 off.

If you can provide specific numbers, that would be wonderful. In looking at the code, the only modifier to Earth Shock should be Elemental Precision. If you can provide an example to the contrary, I'd appreciate it.

(Grace of Air, Blessing of Salvation could also change the number, so...)

Edit: Regarding mobs of the same name, we've intentionally not been given unique mob IDs. I don't expect that to change any time soon.

Antiarc · 05/30/07, 12:30 PM

Originally Posted by Athinira

He got the druid threat modifier for Cat Form inccorect. In the Lua file its 0.79 (-21%) while its in fact 0.71 (-29%) like rogues. I messaged him about this just now to get it corrected. Until then, Druids in Cat Form using this mod will generate more threat than the mod suggests.

Thanks! I've corrected this.

Shadowed · 05/30/07, 12:33 PM

You have no idea what you're talking about.

KTM runs dozens of handlers multiple times -every second-. Not every 5 seconds. Not a few times a minute. Every frame, it invokes multiple handlers. Every single frame.

Bucket events mitigate the burstiness of event-driven systems, and they don't consume any active resources when there are no events being fired.

I've profiled both KTM and Omen heavily using my own homegrown methods, as well as the build-in, Blizzard-provided, written-in-C profiler. ThreatLib and Omen are worlds more efficient. Anyone who has the slightest experience writing software knows that poll-driven systems are highly inefficient in the vast, vast majority of scenarios. WoW is one of them. About the only places that you want a polling system are a) an eventless system, which WoW is not, or b) a multi-threaded system that can run a background threadperiodically polling for state changes that effectively fire events for the primary thread. KTM fits neither of those descriptions.

Go read through the KTM code some time (I've done it) and come back and tell me it's efficient. It simply isn't.

If you really have profiled it, then give your numbers.

The ones you gave are meaningless, soloing is a poor indication of performance being able to 2 shot level 40 mobs doesn't prove anything, you're going to have to give the numbers of an actual raid along with specifics on events profiled before you can try to pass it off as fact.

All you're doing is trying to play an extreme to discredit an idea, if you read what I said I specifically mention in a raid scenario where you typically are going to be in combat most of the time, and you'll have data coming in and out from everyone else.

Calling a function 5 times a second is basically no processing too bad KTM calls like 20-30 internal functions every frame >_>

BTW KTM interestingly enough masks a lot of the processing time from itself by having the part that uses the most CPU time actually be its own internal profiler which of course doesn't measure the time it takes for it doing its own stuff (this is based on using the blizzard profiler checking function time).

Here's an example of how bad KTM is while idling in the middle of nowhere (this picture is with ~200 addons for testing purposes on PTR).

It would be nice if people actually read what I said, I specifically mention never disabling profiling is an issue giving the numbers while both of the mods are idle are useless and you're just going to be biasing the info towards Omen since everyone already knows it's an issue that polling isn't disabled.

Ace2 mods do the same thing actually, it's an easy way to hide memory by putting stuff into libraries.

So I say it again.

Post numbers, I want to see the following, what fight you were testing it on, events and functions you profiled, when you ran the profiling and how many other people were using Omen/KTM.

Soloing is not a valid test case, memory is not a valid test case, and overall CPU taken unless you've done a real test in a raid, also you'll need to give something more specific...oh also you should make sure you disable all of your addons so you actually include the time it takes for it to work including the libraries "It's more efficent if you're using 500 Ace2 addons" is also not a valid excuse.

And no, they aren't giving us any way to uniquely identify a mob from the combat log, it's something they don't want us to have specifically.

Necrotoid · 05/30/07, 1:01 PM

Originally Posted by Athinira

Antiarc.

I was thinking about the problem with mobs of same
name. I was thinking, is it possible to implement threat for more mobs of the same name by using and checking the raid mark icons? This of course implies that icons aren't changed during combat, however it can still be considered a possibility.

DoTimer seems to separate mobs 100% when they are marked with raid icons (and shows the raid mark icon on the timer), and I have trouble with it collapsing mobs with the same name when they are not marked. I'd always assumed it had access to the mob's icon and could use this to differentiate them.

Is the reason a target-based mod (like DoTimer) can do this but not a threat meter because a threat meter must work even when you are not targetting the mob to be tracked?

Fendryl · 05/30/07, 1:02 PM

Originally Posted by Praetorian

No, because all that any threatmeter has to work with is the combat log.

Your Fireball hits Lair Brute for 2500.

There are two Lair Brutes in the pull. Which did you just nuke? You can certainly distinguish between two different mobs for other purposes, but not when parsing a combat log.

For single target spells you could probably get by with checking GetRaidTargetIndex() at the cast time & then using that when you parse the result. Where it'd get confusing though is when an untargeted, i.e. AE, spell is used.

Honestly I'm not too worried about the multiple target issue, I can't think of many fights where you'd be AE'ing & worried about your threat on same-name'd units. The two big things I'm looking forward to from Omen are performance & encounter integration to clear threat on specific phases.

Exigent · 05/30/07, 1:10 PM

What is it about this that's getting some folks so angsty? I believe everyone can agree that the KTM mod has been incredibly useful thus far and I don't see why a little bit of competition from a group that thinks they can do things better is compelling enough of a disturbance to warrant demanding performance evaluation of an add-on that's not even out of the gate. If the group wasn't hell-pent on making a mod that out-performed and out-classed the existing one, then I doubt they'd be inspired to go through the effort in the first place. That said, this is a personal thanks from someone far too lazy to do what you guys dedicate so much time to.

At best, this new mod will provide the raiding community with an improved tool for managing threat; that might come in the form of a new mod or even possibly in an old one, retuned to take advantage of some of the ideas presented. Either way, as a community, we benefit.

I'd humbly suggest that those demanding proof of this or that wait until the addon authors submit something closer to being ready for full-time raiding. Until that time, everything that's being said doesn't contribute much more than this post.

Shadowed · 05/30/07, 1:16 PM

Because it's an issue related to how people view Ace2 mods in general.

If you read the last few pages, people generally are going by the assumintion of libraries and modularity makes it better all the time which is simply untrue unexcept for small cases and even then you have to code it properly. If people are going to use it they should use it because features, bugs or performance but real numbers need to be used and real tests before you base it off that assumination, not just simply saying "Modularity so it's better" or "It feels faster."

Antiarc · 05/30/07, 1:18 PM

So I say it again.

Post numbers, I want to see the following, what fight you were testing it on, events and functions you profiled, when you ran the profiling and how many other people were using Omen/KTM.

Well, all I have for raids at this point is anecdotal - I ran Kara last night and had my group members install it, and eyeballed the performance vs KTM at several points during the night. Turned on CPU profiling for some of the trash pulls where I could afford the slowdown. Threat was, as expected, consuming significantly fewer resources. Once I've got a beta release ready, I'll certainly be doing more benchmarking, but every test I've run so far shows Threat as orders of magnitude more efficient than KTM.

oh also you should make sure you disable all of your addons so you actually include the time it takes for it to work including the libraries "It's more efficent if you're using 500 Ace2 addons" is also not a valid excuse.

Uh, dude, shared Ace libraries just mean you don't duplicate RAM usage. It has nothing to do with CPU performance. Lua is single-threaded, and invoking a library function from Threat is going to take the same CPU time whether there's 1 Ace mod installed or 10. Using Ace libraries a) saves RAM as you increase the number of mods using those libraries, and b) saves developer work (which is my primary reason for building on the Ace framework). Why should I implement a parser, internal event system, pseudo-OO framework, communications handler, and spell localizations when they're already done?

◊ Shalas · 05/30/07, 1:18 PM

Originally Posted by Gurruk

Maybe so.

However, someone with mod credibility could ask and see what he says. It would make targeting mods, threat mods, and other mods much easier to make and take a ton of guess work out of what's happening in a fight.

It's been requested many times, and every time he's said "never going to happen". They've explicitly stated that they don't want mods to be able to give a perfect view of the game world. Of course, based on the the precendent of non-self castbars and debuff timers, if someone managed to perfectly identify mobs in some way with the current information available they might relent.

Originally Posted by Harem

Correct me if I'm wrong, but wouldn't a simply Ace'd KTM be better than a non-Ace'd version, assuming you are already using a certain number of Ace mods? For example, just using ParserLib to get the events to act upon rather than redundantly parsing itself?

ParserLib is a case where this is true -- if you're using Omen, SCT and the ParserLib version of Recap the performance gains could be significant. Most of the time, the benefits of library sharing are going to be minimal, though. Few addons fully utilize all of the libraries they use, so you could easily have 2-3 addons using a library and still having the library do more stuff than each addon implementing the features seperatly would. In addition, even in the best case most libraries just don't do anything that's very computationally expensive. Something like RollCall will never be better performance-wise than each addon doing it seperatly, as it just wraps the guild list API to make it easier to use.

Libraries are great for developers, as they can potentially save large amounts of time. Ideally, this results in higher quality addons, as the addon developers have more time to spend on improving the actual addon instead of reinventing the wheel again. The reason many people love Java isn't the language, it's the incredible standard runtime library. For the end user though, in most cases a program that uses no libraries but is otherwise the same is preferable.

◊ Praetorian · 05/30/07, 1:20 PM

PLEASE stop discussing/debating Ace2 vs. non-Ace, modular vs. non-modular, library memory usage, etc. It's a discussion that's been beaten to death so many times in the modmaking community and we don't need to rehash it yet again in this thread about a promising threat-meter mod.

Shadowed · 05/30/07, 1:22 PM

Uh, dude, shared Ace libraries just mean you don't duplicate RAM usage. It has nothing to do with CPU performance. Lua is single-threaded, and invoking a library function from Threat is going to take the same CPU time whether there's 1 Ace mod installed or 10.

Actually worded it wrong, but meant so you have memory and such as the actual values used, and to reduce any inaccuracies or potenals for data to be simply wrong.

Antiarc · 05/30/07, 1:25 PM

You've got it, Praetorian. Performance flamewars shelved.

Antiarc · 05/30/07, 1:54 PM

Originally Posted by Chicken

In case it's any help for the future, KTM sends it's messages in this format:

prefix: KLHTM
text: t Threat
type: RAID or PARTY depending on whether you're in a raid or not.

You can spoof a KTM threat communication by doing: SendAddonMessage("KLHTM","t 50000","RAID")

There's some checks in there for versions as well, and the version query being sent by someone seems to include the version number as well, which will make spoofing an up-to-date KTM version response very easy. But I'm not exactly sure if it works that way.

Edit:

There's already some framework in place taking into mind the above. So, instead so this post actually has a use, suggestion for handling:

- Add a (KTM) suffix to any data incoming from KTM
- Add the threat reported by KTM to all targets (Much like healing threat; this is also just an assumption since more details are not available and it's better to guess higher than to guess lower)
- For sending threat to KTM, make the threat reported equal to all threat generated on all available targets in the current fight; this should be functionally equivalent to the data KTM sends. Make sure some communication has taken place beforehand that checks which users are using Threat-1.0 and/or Omen instead, so KTM data from these users is ignored, since we have per-target information.

Thanks for the analysis; this looks like it should do the trick.

Snow · 05/30/07, 2:43 PM

I posted this in my guild forums and we tried it. It was very well recieved, so praise be to Antiarc (again). Though it's obviously early on for feature request: our MT commented to me, though, that he misses the threat per second (insert office space TPS joke here) and as soon as Omen displays it, he'd switch immediately. It seemed like a small thing so I thought I would pass on his request.

Jeht · 05/30/07, 2:59 PM

Get the deaggro components working, and I'll force GCR to use it. I can do things like that. I'm sort of a big deal over there.

Antiarc · 05/30/07, 3:22 PM

TPS display is coming. It's a GUI issue, rather than a library issue, which is why I haven't worked on it yet.

Deaggro components should be coming soon.

Roana · 05/30/07, 3:31 PM

Originally Posted by Antiarc

TPS display is coming. It's a GUI issue, rather than a library issue, which is why I haven't worked on it yet.

If it isn't too much of an issue, I'd like it if TPS display could be switched off by the user (if so desired).

Feorthas · 05/30/07, 3:33 PM

Originally Posted by Antiarc

TPS display is coming. It's a GUI issue, rather than a library issue, which is why I haven't worked on it yet.

Deaggro components should be coming soon.

Compared to deaggro components, how hard would it be to rig in an Omen <-> KTM synch? *hopeful*

Athinira · 05/30/07, 3:45 PM

Originally Posted by Antiarc

TPS display is coming. It's a GUI issue, rather than a library issue, which is why I haven't worked on it yet.

Deaggro components should be coming soon.

Just a short reminder, remember that deagro abilities that work with static threat values (Cower and Feint is the only ones springing to mind right now) is affected by threat reduction buffs, including passive threat reduction. This makes these abilities less effective the more threat reduction you get. Aka. feint gets 30% less effective with Salvation etc. though you of course still generate 30% less threat overall.

Athinira · 05/30/07, 3:50 PM

Originally Posted by Praetorian

That seems clunky. It really just boils down to a question of how much Blizzard wants to help the playerbase make mods like these.

I have no doubt that each mob has a unique identifier that isn't displayed but which is known serverside. If they wanted, they could make these unique IDs known to the client via an invisible combat log channel for use by addons, kind of like how they added invisible chat channels for addon communication. But I think that Blizzard may want to continue to obfuscate some elements like this.

Just for info, a unique identifier for mobs have been denied in the past by Slouken, i can't remember the exact reasons. Thanks for the explanation about the combat log though, didn't think of that. I guess its somehow possible to circumvent it, though it would require some pro coding and probably take too many resources.

Antiarc · 05/30/07, 3:50 PM

Originally Posted by Athinira

Just a short reminder, remember that deagro abilities that work with static threat values (Cower and Feint is the only ones springing to mind right now) is affected by threat reduction buffs, including passive threat reduction. This makes these abilities less effective the more threat reduction you get. Aka. feint gets 30% less effective with Salvation etc. though you of course still generate 30% less threat overall.

Yup, that's all accounted for. I have the framework set up in such a way that there are a number of multipliers calculated and maintained, which are applied to abilities as they're passed back from class module handlers. This means that the class modules really only have to worry about their raw values, and the framework takes care of the necessary scaling after the fact.

Antiarc · 05/30/07, 3:53 PM

Originally Posted by Feorthas

Compared to deaggro components, how hard would it be to rig in an Omen <-> KTM synch? *hopeful*

It depends on how much data is desired. KTM only maintains a single threat list that is effectively the sum of all your threat on all targets in a fight, barring Master Target settings. This doesn't "play well" with ThreatLib, as ThreatLib maintains separate threat lists per target name. I'm considering making threat synchs from KTM effectively be "global threat", so they show up on all targets. This works, but sorta pollutes ThreatLib's multi-list targeting. I'll likely band-aid that by denoting which users have data coming from KTM in the display.

Feorthas · 05/30/07, 4:00 PM

Originally Posted by Antiarc

It depends on how much data is desired. KTM only maintains a single threat list that is effectively the sum of all your threat on all targets in a fight, barring Master Target settings. This doesn't "play well" with ThreatLib, as ThreatLib maintains separate threat lists per target name. I'm considering making threat synchs from KTM effectively be "global threat", so they show up on all targets. This works, but sorta pollutes ThreatLib's multi-list targeting. I'll likely band-aid that by denoting which users have data coming from KTM in the display.

How about band-aiding it by something like this:

Omen

Mob A                Mob B
-----                -----
Fred                 Bob
Jim                  Dave
Dave


KTM
-----
Fred
Jim
Bob
Dave

When you synch with KTM, Dave gets +THREAT on both mobs, since he's on both lists, and the others only get +THREAT on the one list that they're active on.

Antiarc · 05/30/07, 4:12 PM

Originally Posted by Feorthas

When you synch with KTM, Dave gets +THREAT on both mobs, since he's on both lists, and the others only get +THREAT on the one list that they're active on.

This is sorta what I'm going to be doing. Threat maintains a global threat list in addition to target-specific lists, and your threat on a target is that target's threat + global threat. KTM users will effectively have their threat values added to the global threat list, making them appear to have that threat on all targets. Ugly and somewhat misinformative, but it'll work.