Is any analysis done on boss averages data.

Post Reply
calar
Posts: 1
Joined: Fri Jan 06, 2012 3:19 pm

Is any analysis done on boss averages data.

Post by calar » Fri Jan 06, 2012 3:25 pm

Example page:

http://www.worldoflogs.com/zones/Dragon_Soul/Morchok/

Is anything done at the time of generating these reports to remove outliers from the data? If so what? If not, how accurate are these reports when used for things such as measuring the average time of boss kills. From these reports it is made apparent that 25man kills on average take a shorted period of time than 10man kills and I was wondering about the accuracy of this claim.

Taken as of last night:

Morchok 10man = 258 seconds
Morchok 25man = 221 seconds

Zonozz 10man = 791 seconds
Zonozz 25man = 781 seconds

Yor'saj 10man = 396 seconds
Yor'saj 25man = 383 seconds

Hagara 10man = 338 seconds
Hagara 25man = 326 seconds

Ultraxion 10man = 306 seconds
Ultraxion 25man = 284 seconds

Blackhorn 10man = 371 seconds
Blackhorn 25man = 324 seconds

Spine 10man = 467 seconds
Spine 25man = 449 seconds

How reliable is that information?

nipil
Posts: 230
Joined: Fri Oct 22, 2010 2:49 pm

Re: Is any analysis done on boss averages data.

Post by nipil » Fri Jan 06, 2012 5:14 pm

The fact you are bringing up is based on a simple explanation : until a reliable LFR mode detection is devised, the 25 LFR reports are considered 25 N reports. You may ask "Why ?" : because Blizzard didn't give any outsider's way of detecting the fight mode, because all spell ids are the same (spell id is the most reliable way of detecting fight modes). As such, one of the only way to detect 25LFR from 25N is the boss and mobs health. There's no other easy way to know the fight mode in the combatlog, as everything is exactly the same. All modes' boss hp values are currently gathered in the following thread : viewtopic.php?f=12&t=2928

So, back to your question now. Once you understand that there are two actual game modes merged in the 25N rankings, you understand that there are two different kind of fight length in these rankings. You can expect "longer" fight times to be 25N, and "shorter" fight times to be 25LFR. But the easiest way to distinguish them, is to open the actual report and look at the total damage done : if it's large, then it's a 25N kill, and if it's smaller, then it's 25 LFR.

What this means is that the 25N numbers in your post are (often) actually 25LFR, and as such, you're actually comparing 25LFR fight length versus 10N fight length.

By the way, i seize the opportunity to remind that once all the HP values are gathered, then the site admins will finish implementing the sanity checks, which will have 2 side effects : firstly, 25 LFR will not be merged anymore with 25N. Then all the "false" reports, the 10 seconds log crap, the "globally incomplete" fights, will all be excluded automatically, bringing back some sanity in the rankings. In the meantime, if you wish to help you can contribute and help the devs get actual exact values for each boss in each mode values : viewtopic.php?f=12&t=2928

ArcaneMagus
Posts: 1518
Joined: Wed Aug 26, 2009 7:56 pm
Contact:

Re: Is any analysis done on boss averages data.

Post by ArcaneMagus » Sat Jan 07, 2012 9:46 am

Just as a note: The implemented LFR mode detection is solely based on detecting "Player-server" type names, and then flagging the 25N (from the spell ID perspective) report as really LFR.

The HP values being gathered in that thread will be used as a better validation then any previous method. Previously fights were validated by checking that x damage was done during a boss encounter... regardless of where that damage was being done. The new form of validation checks that "x damage has been done to npc ids (npc1, npc2, ...)". After putting in a safety margin to account for the inaccuracy inherent in the logs that WoW produces we can now pretty reliably say that a fight was valid, where before a fight could have only been part of the fight, with extra damage done to the trash.

Also, the point of gathering the exact HP values is so we have numbers that actually work with the new validator. The old one was based on a statistical value from a script run on the reports.

Post Reply