Nenormalen

What do you use as raid evaluation tools guys, the dps side? I am pretty unsatisfied with SWStats or DamageMeters...

Ideally I want an addon that shows for example a raid DPS curve over the course of the fight, and not just an average number...also each players performance will be way better monitored if you can see a steady 1000 dps over 1-2 minutes and then a drop to 500 for some reason (afk for example) and then resume to 1000 shortly after...and comparing several guys' "curves" can show when in fight theres a significant dps increase/decrease and the reasons can be evaluated in terms of strategy and so on...

I am yet to try recap, but I am not sure if such features are yet present in any addon...perhaps you can give me some pointers. thanks.

 

◊ Lactose

Try the UI and Addons section?

Look, Lactose, we'd rather you didn't eradicate the whole human race.
- Sam & Max

 

The Iron Colonel

This post is in the wrong forum, but I'll bite. Using the parsing process on a combat log with time-stamps means that theoretically you could create a (total) damage curve and derive a slope at any given point on the curve; this may or may not be valuable, however. If you're doing 20k dps in the first 10 seconds of a 5 minute fight and then you die, you'll have high dps (800 dps, actually) but it's irrelevant, because you've now screwed the fight up by interrupting the tank from building threat.

What may be more useful, however, would be the ability to determine concavity of your damage curve with the second derivative. Ideally every dps class should have a concave curve with a positive slope. This may or may not be realistic, however, given that such a curve would scale off to infinite. Rather, one should determine a realistically sustainable dps window and then check to see what the curve looks like. If the curve us concave and has a positive slope, great; that player is dealing damage at an increasing rate throughout the fight. If a player's damage curve is convex with a positive slope, things look good (they are dealing damage, but the rate at which they are dealing it is not increasing).

The problem players could be easily identified; their total damage curve in the nominally sustainable dps window would be convex with a negative slope or, even worse, concave with a negative slope. These players are either dieing early in a fight or are generally not able to sustain a solid rate of dps.

Of course, this is all just theory and speculation, but hopefully someone sees where I'm going with this.

 

• Greybone

Moved.

ps. Your picture makes me wanna throwup and laugh at the same time.

 

Papajan

I don't think anything like that is out there, so I'll add to the wishlist:

It'd be awesome if you could do a class-by-class comparison within that, and do a very simple normalization for gear. Like for instance, for fire mages, divide the dps by the average fireball hit or something like that to identify what's going on independently of how geared (or undergeared) each player is. Ideally, you'd normalize by some simple function of their +damage/crit/hit/AP/etc, but that would be a huge pain to implement.

For mana users, it'd be nice to have a graph of mana too, so you could easily see that their dps dropped when they went OOM as opposed to some other reason.

 

The Iron Colonel

I'm not certain it would be such a pain to implement the math and analysis functions; rather, the problem would be keeping the data with respect to which you're normalizing up-to-date. Taking data from parsed combat logs is simple; having access to the context in which the combat takes place is not (i.e. conditions with respect to buffs, gear, etc.).

As for mana usage, the only way I see to do this would be to count spell casts and then reference talent builds / gear that changes mana cost. Clearcasting procs could be somewhat easier, as the time stamps would allow you to see which spell hit first following a clear casting proc (although this can vary - see elemental shaman spamming R1 LB to proc CC on the previous LB). I'm not a programmer per se, but I can at least help create a wishlist.

 

Papajan

I mean the coding would be tough if you wrote it to auto-inspect people or download Armory stuff for up-to-date stats rather than reverse-engineering the stats from damage of common spells.

 

◊ Shalas

Or instead of doing all that math to derive how many fireballs they cast, you could just track that directly, as SW_Stats does.

 

The Iron Colonel

Yeah, we agree there. Obtaining information from the combat log is simple; from the armory is a pain (and wouldn't be worth it, considering that the armory occasionally doesn't update for relatively long periods of time).

 

• Cryect

Basically you want graphs to aid you and I have to agree all the current damage tracking addons are pretty garbage for figuring out whats going on besides Recap (which I heavily modified to add a lot of features I wanted in). I would also say Recap has a lot of issues in that the code base I started with has several bugs in it (there is another fork I know of on CurseGaming which I think fixed a lot of them).

This is one of the reasons I developed GraphLib, which is a library that makes graphing easy (lets you create line graphs, scatter charts, real-time graphs, and even pie charts quite easily). I was hoping someone else would take advantage of it but its looking like I will have to start work on my tracker based on what I've learned from Recap.

Really the issue comes down to the addons out there don't track enough information nor display it in a method thats useful.

 

Axelrod

A combatlog parser that outputs a graphical curve would be neat. With the x-axis representing time and y-axis representing damage, there would be an opportunity to also show bars parallel to this graph extending in the y-axis direction representing the times when certain buffs/debuffs have been placed and removed. Incoming awesome-o MSPaint skillz:



Thus, if this were an analysis of one player in a raid, the green bars would each represent debuffs placed on a boss and the blue bars would represent buffs activated or deactivated within this timeframe. If it were a graph of the entire raid's dps, the blue bars wouldn't be present and it would be easy to see how debuffs on a boss affect dps, such as "Expose Weakness" when it's on and off.

 

The Iron Colonel

I don't wanna put words in anyone's mouth, but it sounds like many people are interested in a combat log parsing program that can create dynamic graphs of various stats as well as a parallel timeline showing buffs/debuff. I have to say, I'd prefer to do this all out of game (seems like that would be easier to implement anyway). Likewise, I think I'm partial to the html output that WWS has; this makes access easier for the entire raid. Other thoughts to put on the wishlist?

 

• Cryect

Its no easier out of game than in game. The out of game advantage is you can create webpages out of game. I personally prefer in game since want to see whats going on now not later normally.

I mean the code to create graphs if you use my library is damn easy. Its basically

CreateGraph
AddDataSet

The harder part is actually gathering the data.

Some examples of it in use

 

The Iron Colonel

I see your point; I wasn't trying to diminish your previous work at all. I see your point about doing it in game and providing immediate feedback, but I find the memory usage of many damage meters to be an issue; likewise, I like to have a permanent record that I can reference when I'm looking over theory, etc.

Am I making sense or just rambling? Sorry, hard for me to tell the difference some times.

 

• Cryect

Memory is a greatly overstated performance metric that I laugh when people act like its the end all be all We aren't dealing with consoles with a really low memory amount and often the amount of memory in use doesn't even relate to the amount of processing time the addon uses.

Recap example uses less than 2MB of memory for a night of raiding and to me it would be fine if it used up 10 times that if it could give me a much more detailed view and really it needs much less than that.

For an addon you definately don't want to store the combat log messages or exact things but instead you can easily store a outgoing & incoming DPS and HPS numbers for every player once every second.

Thats 8 bytes for each with 4 variables tracked so 64 bytes per second.
25 players so 25 players* 64 bytes per player per second = 1600 bytes per second.
1600 bytes per second * 60 seconds per minute / 1024 bytes per kilobyte = 93.75 KB/Minute
Estimate 25% Overhead for Lua variables (not sure on the specifics but it has to track stuff like type and its being stored in a table) 93.75 KB/Minute* 125% = 117.1875 KB/Minute

So we are talking about ~120 KB/Minute so its going to be around 1 MB per Boss Fight. If there is the allowance easy autorecording only at boss fights (something that looks say like the RDX timer). The real importance comes down in the data management to ensure memory usage is kept to a minimum for example by allowing for autodeleting of fights lets say less than 2 minutes. Also sparse data tables because the truth is not many people have a ton of Outgoing DPS & HPS with lots of Incoming DPS & HPS.

Overall to me this seems well worth it for someone trying to analyze whats going on and how someone could potentially improve in the raid. Heh, I think I will try coding up something later tonight maybe.


BTW if you are concerned about performance issues make sure you aren't using KTM that addon sucks up CPU usage like nothing else (even while you are standing around doing absolutely nothing with no combat messages occurring near you).

 

Arko

Why not? You certainly won't store the text message, but an encoded Version can be quite small. What would, say, a fireball need?

- Time since last event
- Type of event
- Caster
- Target
- Crit/Resist status flag
- Damage done

That is all I can think of right now. A data block like that takes about 20 bytes. Now lets make some extremly exxagerating assumptions. You raid for 10 hours straight with 40 people and you go at a relentless pace causing 5 events per second per person. That is 137MB. So what? I have a Gigabyte to spare for that stuff. If you need to take 15% of it to save me the hassle of storing combat logs to disk and parsing them two hours after everything happend, go forward!

You could have completely new viewing options once this data is available in the game. Be a little creative, like this: "Warning: Tank X was 1.3 seconds from dying to the next attack when he was healed." I sure would like to know this as a raid leader immidiately, it could be just in time to reassign a healer in mid-fight.

You want to know why priest X has so much overhealing? Collect the set of heals, that hit his targets right *before* he healed them. You see a lot of flash heals from priest Y? Maybe there is your real problem. SWStats goes into that direction, but it is far far from what would be possible.

 

◊ Shalas

If you're saving the data as complex lua data structures, size can start to be a problem as the lua serializer is somewhat slow, but even that doesn't matter if you just serialize the data yourself sometime when the delay isn't incredibly noticable. Other than that, memory used is almost meaningless as a performance statistic -- you're either using enough that you run out, or you aren't, and an addon would have to be storing a disgusting amount of data to make a significant difference. Because of how lua stores strings (strings are immutable, unique and gc'd as if they were objects), storing a complete copy of the combat log could theoretically even improve performance by reducing the time spent in gc.

 

• Cryect

Thats something I personally have been wanting to implement in some shape or form for a while (and by a while I mean since my guild was in BWL trying to kill firemaw since I thought healing meters mean jack shit compared to the actual saving heals) of the what if case if we took out just a single heal would the tank have died. But, you don't need that much data to figure out those type of stats.

The way I'm planning to handle cases like that is just track the last 15 actions done to all players this gives you enough leeway to calculate this stuff on the fly. Then whenever a player is stored this gets attached to the player death information (so when you are looking at the Death List you can click on a player this will pop up a window showing the various deaths at different time points with any of them selectable to show the last 15 actions involving that player). This data as well can be used for other actions like figuring out saving heals on the fly.

Anyways back to coding.

 

panny

I vaguely remember one of Beckon's numerous PvP videos had a mod that would graph his DPS in realtime. When I get home, I'll have a look for the video, but does anyone know it offhand?

 

◊ blindworld

I'm not entirely sure if this is possible, but is it possible to also track who had a heal mid-cast on a target when they died? The client has to have the information somehow since you can display others cast bars, but I'm not sure if that is something that comes up in the combat log, or if it would have to be tracked through a much more complicated means.

"Regime change under a Bush doctrine. Democratic installations. Constant war for constant soldiers. What are we gonna do now? De-escalation through military force. Increase the pressure. Oh Condoleezza what should we do about the situation in Iran and North Korea? Condoleezza?" Against Me! - From Her Lips To God's Ears (2005)

If a punk band from Florida knows what the Bush Doctrine is, clearly a politician should too, especially one who could be the next Vice President.

 

◊ Cadfael

I don't think this is possible (at least if you want something near 100% accuracy). The game reports "<Healer> begins to cast <healing spell>" events, but won't give you the target. If you check at this point manually what target that player has, you will get the wrong one if he's using macros like [target=focus] which enables him to have another target than the one getting the cast. Same for clickhealers who do not heal necessarily the person they have targeted.

If the cast gets through, you will get spell target on successfully cast spell event and you will of course get a "<player> gains X health by <healers>'s <spellname>" but if the target dies and the spell fails, these events won't come.

You might be able to track spell abort events though and try to correlate them to player deaths post mortem but that's not going to be accurate either if there are several people dieing almost concurrently.

It may have changed though and the API now does infact give spelltargets with spellcast started events. Wowwiki at least doesn't list that if it does it now, though or I missed it when I skimmed through it.

 

Arko

As a last resort, you can sync it. But that could create a lot of network traffic and it causes an additional delay. Not what I had in mind.

 

Arko

Saving unparsed string data is pretty much always a bad idea. If you get to much objects, you can invent your own data format and store larger chunks of binary data directly in an object as byte array.

The gc will have a very bad time with a full combat log of strings if it is not generational. If it is, it won't matter.

 

◊ Shalas

If you store everything, the garbage collector's performance doesn't matter, as it wouldn't be collecting anything at a time when performance matters as long as you cleaned up sometime before logout.

 

Crepe

DPS graphs certainly would be interesting. They would allow you to correlate when Noobmage0 was spamming fireball and when they were running around like a chicken with a missing head from Notgolemagg's Aoeofdoom or whatever.

The healing bit is more interesting, though. H