◊ Kalman

/derail

It's really time for KTM to get oRA'ed.

 

Cel

That's a good way to describe it... when I made the jump from CT to Ace, I was shocked in the amount of resources I freed up. KTM has hundreds of little parses and calculations, though, given the nature of the addon. Is it possible to cut that back? I'm not so sure it is, though that's blind estimation from one who doesn't write mods and just has a general programming background.

"There is much pleasure to be gained from useless knowledge." - Bertrand Russell

Alpha is recruiting... go go.

 

• Chicken

I've seen it suggested a bunch of times, developers on the Ace forum say it's too complicated to do so easily (Since it has to deal with threat calculations et all internally), unlike, say, CTRA which basically communicates information which is relatively easily available.

I'd personally give a lot for a send-only version of KTM, but I'm not sure if that'd even help much.

buff /bʌf/ Pronunciation[buhf]
–verb (used with object)
- to reduce or deaden the force of

 

◊ Kalman

If it's taking up resources in the fashion Cryect describes even while there are no combat events going on, then yes, it is. Addition and multiplication are relatively cheap operations these days; the calculations aren't the part that's chewing up time. It's the parsing/event processing, most likely, eating the CPU.

 

Cryect

CombatGraph or Gram. CombatGraph was my baby http://acm.jhu.edu/~cryect/CombatGraph/ I don't even know if it works now :-p

Takes about 10 minutes to implement a rough new version with GraphLib and ParserLib (I did when I was fooling around with working on the Realtime graph though my favorite test for that was a FPS graph).





On KTM, there is interest in the Ace community for someone to do it but no one personally who wants to do it :p The issue is the project isn't a very interesting one

The problems with KTM after doing some profiling is that every frame its running a ton of code for unknown reasons. I've got a hack that helps reduce the performance KTM is using by only letting it do updates at most every 0.1 seconds instead of every frame though don't know if it has any issues. It still uses a fair bit of CPU time when it shouldn't be (example fly up high into the sky not in a group and you will be receiving zero combat log messages for it to process but its likely using ~50% or more of your CPU time).

Its the implementation thats flawed not the basic concept of Threat Tracking and its at the point where it works well enough that no one is really wanting to tackle the project.


Edit: I will make note first time implementations of most things is normally bad without a lot of fore planning. Heh, a streak I know thats in a lot of my addons. Though its a lot better in addons I care about to take the time to write all up before I ever start coding them (feature bloat is what causes issues normally).

 

Cryect

BTW figure I give some real numbers.

This data is from me going afk for 15 minutes or so.

I've got 165 different addons running during this time (been experimenting with a lot of various addons on PTR, example I've got 4 different damage trackers running :-p)



And memory from about the same time point.



GPSLib usage is so high btw due to some memory issue with me creating a new table over a table every frame (when GC clicks it drops down in memory usage a ton :-p). Wasn't thinking when I wrote that code and need to go back to it (actually I was thinking oh I don't really feel like checking if the table is already created or not even though it would be 3 more lines of code only).

 

Vektor

I'd be interested in that KTM hack
(I assume it's just a matter of testing elapsed time since last update in the OnUpdate callback or something, but I haven't opened the .lua file at all, so if you already have a solution, I'd be receptive.)

I'm no raid lead, but I'm our guild's statistics junkie. I'm the guy running 200yd WWS parses and posting them.

SWS is nice for seeing a quick-and-dirty overview of who did how much damage, but it doesn't tell you jack about context (also, I'd love for it to have a "last fight" feature though, to alleviate the constant /sws rv spam on each boss attempt)

WWS is a bear in that you have to take all these logs and wait until post-raid to generate parses, and good luck wading through the combat log if, for some reason, the log splitter doesn't play nice.

I also like the idea of real-time graphs.

I can see something like

being infinitely more useful than your standard 'damage meters' type addon.

(especially if you could hover over, or click a person's graph for more detailed informations)
(maybe a graph of tank HP would be more useful than damage taken? I don't know!)

 

◊ Kyth

I'd be very interested both in what mod (even if it's not "of public release" quality) you're using to easily view the data (so I can play on the PTR or when 2.1 is out!) and in any generically useful conclusions you can post, since many I think use a core of the same mods.

 

Cryect

Its Protractor and you can find it over at WoWAce. Besides KTM is a performance hog and there is no good way to figure out what addons are causing Ace 2 performance and memory use to be up not much to say. In general, I was pleased with memory usage but we've had means of measuring that information fairly well for a while and most developers try to be conscious of their memory usage.

 

Papajan

I remember watching a Sapphiron video on Google video from a horde priest POV, I think it had the song "Blow Me Away" by Breaking Benjamin at the start, and that video had a side-scrolling graph of damage on the MT where there would be a little bar which was correlated to the damage. I imagine it'd be handy for predictive healing. Maybe it was the evolution of CombatGraph that Cryect mentioned on his page.

 

Cryect

The 1.4 Beta of CombatGraph supported seeing incoming HPS or DPS of any target and I know a few people made their own updated versions though never checked what any of them did (I decided I didn't find it personally that useful and just an amusing thing to watch).

Edit: Here's some supposedly version working in 2.0.10 not exactly sure if I'm fond of how he doesn't give me any credit (he took my readme file replaced my name with his name hell he even has the date from dec 2005 in >_>)

http://wow-en.curse-gaming.com/downl...graph-updated/

 

Cryect

I've got a basic parser and data displaying addon together though haven't add features in yet for time data etc. But have to start somewhere.

Basically like a Recap at the moment hence the name Recount

 

Vektor

Interesting idea

I don't know if your graphs are this dynamic, though.

I like visual representations.
Over in the detail window, maybe tab the sucker or something.

What I was thinking was a line-graph with checkboxes across the bottom.
Obviously, you have damage dealt, heal output, etc.

Toggling the checkboxes on overlays the selected value on the graph.

So you could toggle damage dealt on, as well as remaining mana and watch how the damage dealt slope varies as remaining mana changes. Values could include mana remaining, raid members still standing, damage done, damage received, healing, overhealing... you could probably even filter for the presence of certain buffs (combobox maybe?)

I don't even know if your addon collects per-second (or even dumbed down, accumulated per-5-second) data or not. If it did, this sort of thing is one kind of interesting metric you could use which gives time-sensitive data with the ability to take multiple values into context.

Disclaimer: it's 4:15am and I should be sleeping so if this is incoherent, sorry :P

 

Vektor

Okay.
I'm somewhat awake now.

Realize I'm likely being overenthusiastic (but as you say, storing the data won't produce THAT much overhead), but here's a crappy image of the sort of thing I was thinking



Showing the correlation of damage done to mana remaining

 

Papajan

Looks useful so far, I'd definitely replace SWS or DM with this. Just a quick couple of quick questions though:
1) What is the ability 113 (#5)?
2) Is there a way to show auto-attack as different from special abilities in the bottom graph? I think the hit-cap is different for melee, for example, when using normal vs. special abilities.

Also, as an idea, if you've got hit in there, it would be possible to normalize by that in addition to +damage. (Although crit couldn't really be normalized)

I didn't realize at first that this is what I wanted, cause I didn't realize that most of what I'm after is the number of casts. To some extent, I was thinking of normalizing across spells, not for individual ones, so that you'd have number of casts and ability usage rolled into one statistic. Something for a global view of things that might be nice is the total dps time (sum of casting times) over the total time spent alive and in combat. If I had that sort of info, then I'd have a good picture of whether someone's dps is dependent on their ability usage or lag/clicking.

That gives me another fun idea: what if you used an ngram model of ability usage in conjunction with collocation-detection methods (like mutual information) to automatically determine which ability rotations they used? It would be really nifty to see that 90% of someone's dps was in an AB/scorch rotation or whatever rather than guessing at their rotation from ability percentages. Or actually, using MI would be extra work I think, maybe just detect cycles in a markov model that account for >20% of total damage. The model would probably have to be somewhat high-order, but the set of abilities is very small, so it shouldn't be bad computationally.

Another thing that would be useful to see is the breakdown of cast times for arcane blast (if there's a generic way to implement this, maybe break abilities down by cast time if they have multiple cast times, but that would be affected by Quag's Eye and Heroism, etc). It would be very useful information to see that someone isn't overlapping the AB debuff expiration with the beginning of their next cycle.

Anyway, if you're working in Subversion/CVS or something and need a hand, I can help out a bit. I'm not really good with lua gui stuff (especially if I have to start from scratch), but I could probably help out with fixing up little things or implementing analysis-type code.

 

The Iron Colonel

This might already be in, but one feature that I love about WWS is the ability to break things down fight by fight (Minnastats does this as well, but its overly simplistic interface is quickly wearing my patience thin) and to calculate dps during time spent dpsing (rather than length of time in combat, as SWStats does). I realize item #2 might seem like a "lets make our dps look higher" kind of thing, but honestly it's not representative of damage output to count someone's damage while they're graved or stoned or on cube duty. Measure dps by actual time spent dealing damage, not potential time spent dealing damage.

 

Cryect

1) Thats the constant for damage shields in ParserLib that I forgot to check for at that time.
2) It actually shows a single ability at the bottom (was my maul data at that time) here's a new screenshot from last night before I went to sleep. Basically the idea is you select an ability at the top by scrolling over it in the pie chart or table then that ability is shown below.



And 200 in that figure is for "No One" (things like the ceiling falling on top of people or the shadow word: death tick on to priests aren't attributed to anyone).

I need to work on fleshing it out a little for the other it should be able to display in this mode.

1. Hostile Abilities
2. Healing
3. Incoming Damage
4. Incoming Heals
5. Damage on Whom (Bottom Chart will show the specific attacks on the targets)
6. Healing on Whom
7. Incoming Damage by Whom
8. Incoming Heals by Whom


The todo list after that then is

1. Add Time Data Tracking and Display
2. Summarized Incoming Damage Report
3. Summarized Outgoing Action Reports
4. Add death tracking (handling & display of last X incoming actions on the player dieing)

Then will see where to go at that point.

 

Cryect

Heh and patience on the time graphs etc.

I've got ideas which you will see shortly (the fun of flipping through old various design docs I've written up in the past which are in spiral notebooks).

 

Cryect

Lots of work to go only polishing that up.

 

Northerner

I await The Holy Grail here with some interest. I'm far too lazy (and busy) to go down this road myself but if we can get past the data collection stage I'd be happy to contribute with output logic/formatting.

I consider THG to be output that answers these questions:

Who died, when and why?
Who did (or didn't do) what and when, with what impact?
Overall raid dps and affected by what debuffs?
Overall incoming raid damage and specific tank damage and affected by what?
and so on...

Oh damn, it's too easy to think of options at this point.

 

BeerBelly

I'm looking forward to seeing this in action. It's exactly the type of thing that would help me breakdown the performance of certain people in boss fights.

The graphs would help best if you could overlay one over the other I think (I'm talking about overlaying a leading mage DPS graph to an underachieving one). Since that would paint a nice picture of where the underachiever goes wrong.

Anyway, I hope this addon sees the light of day since I would surely be using it.

 

Abbi

Very keen stuff. The time graphs are really exciting; I've been thinking about generating that sort of thing out of game, but haven't made a lot of progress so far.

 

The Iron Colonel

I think this exemplifies what people want: context. Damage meters traditionally provide only damage totals out of context. Having a timeline or readily manipulable data to actually figure out what happened would be great. Looks like you're well on your way to putting out a solid utility for raiding; I appreciate the time and effort.

 

Papajan

Looking great so far, man; if you want any sort of testing, just holler.

I hadn't thought about it before, but one problem with the dps-over-time graph is the granularity of measuring dps. If you measure the 1s period in which a fireball lands, then you're looking at say 3000 dps. But if you measure over the 3s cast, you're looking at 1000 dps. Here are a few ideas for you (you probably already thought of them, but it can't hurt to give some alternative implementations):
1) Block dps in 10s regions. This would be pretty resource-efficient during live usage since you'd only update the graph every 10s. The only thing I'd say is a problem with regions like 5s is that it's below the cast time for some rare long spells.
2) Choose block sizes such that the derivative of dps stays below some threshold (when possible). That would force the graph to be smooth, which is exactly what you're interested in for long-term trends.
3) Just graph total damage done and then the whole problem is avoided (by shifting the problem onto the user)
4) If you could somehow measure cast time and tick time, attribute all damage to the time period that went into generating that damage. That'd give a really accurate graph, which might then need to be smoothed out.

I'm not sure about the advantages vs. disadvantages of having overlapping time blocks vs. non-overlapping ones. I suppose the former would be smoother, but the latter would give a better idea of what's happening in a region. Though you'd probably get the overlapping smoothing effect by just fitting a curve to non-overlapping data. The method of graphing it will probably lend itself more to some ways of interpreting dps more than others

 

Cryect

Yeah, I've played around with various methods in the past currently I'm just using a 15 second window for filtering. After looking not fully sure if its quite as smooth as I desired (was looking kinda spiky on boss fights for most players). I've got more ideas of what to do.

At the moment I need to consider how to filter the data slightly better in GraphLib so it doesn't go over board with number of lines its drawing (heh 10 minute fight was taking ~10 seconds to setup).

Was distracted today working on something else today completely unrelated >_>



http://acm.jhu.edu/~cryect/mode7test.zip


For those who are wanting to test out Recount its on the WoWAce SVN but not on files.wowace.com at this time (some issues with it). Kinda quirky at the moment but its quite in the early stages.