Parser Public Build * Download Link

[Spider-Dan]

And total damage is a very bad measure of efficiency in fights where monsters have auto-regen and self healing. The goal as a DD fighting class for ppl who I play with is to reach the "Damage Ceiling" this is the point where you are doing maximum dmg per second till the fight is over, in ffxiv for arc specifically this means you are keeping every damage skill on cooldown and are maximizing things like quick knock with keen flurry, using blood for blood with light shots etc. Never missing a combo.

Since every DD spends the same amount of seconds in the fight, how is maximum-DPS-from-start-to-stop any different than max-total-damage?

As far as auto-regen goes, I don't see why that would affect your efficiency, other than people who are spamming AoEs on non-primary-targets (only to let them heal up) just to artificially raise their damage output. You can make the point about cooldown timer efficiency and what not, but I don't see that as an argument for DPS vs. total damage as much as it is an argument to ignore DPS and only consider cooldown timer efficiency + averaged damage per [individual action].

[tachikoma]

Since every DD spends the same amount of seconds in the fight, how is maximum-DPS-from-start-to-stop any different than max-total-damage?

Exactly right, its not but if you take 10 moogle fights the total cummulative Damage dealt is not the same some fights that are very quick could have a total dmg of say 250k from all the DD's but the next fight might have 350k total dmg. Thus the purpose of a parser is to find a way to measure your DD's effectiveness accross multiple fights and thats where DPS was born. When the king can heal for 4k a pop this GREATLY skews fights total dmg.

Example: some early moogle parser SS's

http://www.gwcdn.com/albums/images/4...7f5e004e23.jpg
http://www.gwcdn.com/albums/images/4...7f5e005067.jpg

Notice the total dmg dealt vs the DPS see how the total dmg dealt went up from 80k -> 82k but DPS went down from 73 -> 70

This is why total dmg means nothing when you are trying to measure DD output.

[tachikoma]

Looking at damage dealt is fine for a single fight, you can compare a group of DD's in a single closed instance but if you want to do any long term statistics DPS is a nice way to measure that.

[Spider-Dan]

OK, that makes sense. I've always looked at parses on a per-event basis (so, one fight, one exp session, etc.), not comparing across events.

Wouldn't % of total party damage be equivalent to DPS for comparing across fights?

[Grey Jorildyn]

Difficult to compare any cross-fight stats unless the party setup and players were the same, and the overall party performance was the same (ie. no one died, or everyone died but for the same amount of time, etc.). DPS tends to be a more accurate measure of a player's personal performance as it crunches the gear and skill (read: button-pushing ability) number into something measurable. 5 archers in your party could be pushing 60 DPS and do 20% total damage each, and kill Moogles in 10mins, or everyone could be doing 40 DPS, 20% total damage each, but the fight drags on an extra 5minutes (just throwing out numbers).

[Kaylia]

OK, that makes sense. I've always looked at parses on a per-event basis (so, one fight, one exp session, etc.), not comparing across events.

Wouldn't % of total party damage be equivalent to DPS for comparing across fights?

A parser will usually give you 3 parameters
-Total damages dealt
-DPS
-% of the party damage

It's never a good idea to look at these numbers in a vacuum because the synergy between all 3 is where you will get the meaningful information.

Total damages is obviously what what matter when you're playing (assuming there is no burst damage needed), but on its own, it doesn't tell you anything useful that can be used for theorycrafting. The longer the fight is (someone died, other dps sucks, the boss healed itself,etc) the higher your total will be. Because of that, it can't be used as a benchmark to compare different attempts .

It's the reason why "DPS" is the most used measurement. Knowing the average damage you can do every seconds, minutes, or 5 minutes allow you to make better prediction. Obviously, that number is going to be skewed by the encounter mechanics to a certain extent, but at least, it removes the effect other players have on your number (excluding buff/debuff).

% of the party damages is useful to find the weakest link in your group. However, since the performance are individual and are subject to change, being the top (or last) players in a specific group doesn't mean you're doing well (or awful), it could means that everyone is fucking terrible (or great).

[tachikoma]

Nice summary Kaylia, another very VERY usefull part of my parser and most others is damage taken and the breakdown of what caused the dmg. Being able to show a weaker player "Look you were hit for 6 eruptions for a total of 4k dmg" is a lot more concrete than "you suck stop getting hit".

Also evaluating weather you think a THM is useful in moogle you could look at enfeeble bind rate, and bind counter. If a single THM is able to add in 20 binds in a fight that stick it can totally change the fight dynamic. Of course if your THM sucks and they dont' bind then this could help them improve that area.

[Deus Diabolus]

Hi, I have a note to the author of the parser applet. I have a few comments and a request. I want to start of by saying THANK YOU for making basic parse tests accessible and simple for general purpose use. A lot of very useful data has come from the presentation of your parser. It's so important that we all collaborate in this way so no one person has to do all the work. Thanks for making this available to everyone, with a very crisp presentation and thorough calculation of most of the game parameters.

I have a very basic request that will enable myself and other advanced testers like Kaeko to be able to do extremely detailed and rigorous testing. To do this we need RAW data. A year ago I did 3 months of testing using a simple program that is no longer around, Crabby, which read the chat state (including chat codes) and I was able to copy that out into notepad and write my own parser using Perl. What I'm asking you to do as a feature is a simple ECHO as you read each line of chatlog in and be able to output that. Alternatively it will take one of those log files and convert it into a legible format. The problem is I have not figured out what that log file format is, and if chat codes can be reestablished from that file. Since you have already figured this out I was hoping you could save me the time. If you can do that for us we are one step closer to performing rigorous tests that may ultimately derive complete battle algorithm formulae.

An example of output I get from crabby (that I see in the log files, but with unintelligible characters that 'corrupt' the data im looking for):
0020:[17:00:44] The black eft is engaged.
0052:[17:00:47] Dot Net's Light Shot hits the black eft from the left for 109 points of damage.
0052:[17:00:49] Dot Net's Light Shot hits the black eft for 110 points of damage.
0053:[17:00:51] The black eft's Circlespark hits Dot Net from the rear for 183 points of damage.
0052:[17:00:51] Dot Net's Light Shot hits the black eft for 102 points of damage.
0052:[17:00:53] Dot Net's Light Shot hits the black eft for 102 points of damage.
0058:[17:00:55] The black eft evades Dot Net's Light Shot.
0059:[17:00:57] The black eft's attack misses Dot Net.
0052:[17:00:57] Dot Net's Light Shot hits the black eft for 105 points of damage.
0058:[17:01:02] The black eft evades Dot Net's Light Shot.
0053:[17:01:06] The black eft's attack hits Dot Net for 268 points of damage.
0058:[17:01:08] Khymerra Rhae's Light Thrust misses the black eft.
0058:[17:01:09] Era Dilectio's Phantom Dart misses the black eft.
0052:[17:01:10] Era Dilectio's Phantom Dart hits the black eft for 83 points of damage.
0052:[17:01:11] Khymerra Rhae's Light Thrust hits the black eft for 87 points of damage.
0058:[17:01:12] Era Dilectio's Phantom Dart misses the black eft.
0052:[17:01:13] Khymerra Rhae's Heavy Thrust hits the black eft from the left for 85 points of damage.
006A:[17:01:13] Khymerra Rhae's Heavy Thrust inflicts the black eft with the effect of Bind.
0052:[17:01:14] Era Dilectio's Phantom Dart hits the black eft for 71 points of damage.
0064:[17:01:14] The black eft is no longer bound.
0058:[17:01:15] The black eft evades Khymerra Rhae's Heavy Thrust.
0053:[17:01:16] The black eft's attack hits Khymerra Rhae for 308 points of damage.
0052:[17:01:16] Critical! Era Dilectio's Phantom Dart hits the black eft for 91 points of damage.
0064:[17:01:18] Dot Net's Hawk's Eye grants Dot Net the effect of Hawk's Eye.
0062:[17:01:18] Your Provoke II inflicts the black eft with the effect of Provoked.
0052:[17:01:19] Critical! Khymerra Rhae's Light Thrust hits the black eft from the left for 94 points of damage.
0052:[17:01:19] Era Dilectio's Phantom Dart hits the black eft for 66 points of damage.
0064:[17:01:19] Dot Net's Raging Strike grants Dot Net the effect of Raging Strike.
0066:[17:01:19] The black eft is no longer provoked.

The numeric chat codes (first 4 digits) correspond to the chat filters in the Configuration settings. Those are crucial (but not absolutely necessary) for establishing the validity of each line in the context of whatever test I am doing. Being able to recover those is a priority if its possible.

Lastly here are some examples of things I have done in the past in the previous battle algorithm context. I would like to have the opportunity to provide similar results again in the coming months:

I cant post URLs so Google these:
"Test Central: Log Parse Results = MAX Attribute+Gear Effects"
"Deus Diabolus Lodestone blog"

Thanks, I look forward to whenever you can get around to this.

[tachikoma]

Hi, I have a note to the author of the parser applet. I have a few comments and a request. I want to start of by saying THANK YOU for making basic parse tests accessible and simple for general purpose use. A lot of very useful data has come from the presentation of your parser. It's so important that we all collaborate in this way so no one person has to do all the work. Thanks for making this available to everyone, with a very crisp presentation and thorough calculation of most of the game parameters.

I have a very basic request that will enable myself and other advanced testers like Kaeko to be able to do extremely detailed and rigorous testing. To do this we need RAW data. A year ago I did 3 months of testing using a simple program that is no longer around, Crabby, which read the chat state (including chat codes) and I was able to copy that out into notepad and write my own parser using Perl. What I'm asking you to do as a feature is a simple ECHO as you read each line of chatlog in and be able to output that. Alternatively it will take one of those log files and convert it into a legible format. The problem is I have not figured out what that log file format is, and if chat codes can be reestablished from that file. Since you have already figured this out I was hoping you could save me the time. If you can do that for us we are one step closer to performing rigorous tests that may ultimately derive complete battle algorithm formulae.

An example of output I get from crabby (that I see in the log files, but with unintelligible characters that 'corrupt' the data im looking for):
0020:[17:00:44] The black eft is engaged.
0052:[17:00:47] Dot Net's Light Shot hits the black eft from the left for 109 points of damage.
0052:[17:00:49] Dot Net's Light Shot hits the black eft for 110 points of damage.
0053:[17:00:51] The black eft's Circlespark hits Dot Net from the rear for 183 points of damage.
0052:[17:00:51] Dot Net's Light Shot hits the black eft for 102 points of damage.
0052:[17:00:53] Dot Net's Light Shot hits the black eft for 102 points of damage.
0058:[17:00:55] The black eft evades Dot Net's Light Shot.
0059:[17:00:57] The black eft's attack misses Dot Net.
0052:[17:00:57] Dot Net's Light Shot hits the black eft for 105 points of damage.
0058:[17:01:02] The black eft evades Dot Net's Light Shot.
0053:[17:01:06] The black eft's attack hits Dot Net for 268 points of damage.
0058:[17:01:08] Khymerra Rhae's Light Thrust misses the black eft.
0058:[17:01:09] Era Dilectio's Phantom Dart misses the black eft.
0052:[17:01:10] Era Dilectio's Phantom Dart hits the black eft for 83 points of damage.
0052:[17:01:11] Khymerra Rhae's Light Thrust hits the black eft for 87 points of damage.
0058:[17:01:12] Era Dilectio's Phantom Dart misses the black eft.
0052:[17:01:13] Khymerra Rhae's Heavy Thrust hits the black eft from the left for 85 points of damage.
006A:[17:01:13] Khymerra Rhae's Heavy Thrust inflicts the black eft with the effect of Bind.
0052:[17:01:14] Era Dilectio's Phantom Dart hits the black eft for 71 points of damage.
0064:[17:01:14] The black eft is no longer bound.
0058:[17:01:15] The black eft evades Khymerra Rhae's Heavy Thrust.
0053:[17:01:16] The black eft's attack hits Khymerra Rhae for 308 points of damage.
0052:[17:01:16] Critical! Era Dilectio's Phantom Dart hits the black eft for 91 points of damage.
0064:[17:01:18] Dot Net's Hawk's Eye grants Dot Net the effect of Hawk's Eye.
0062:[17:01:18] Your Provoke II inflicts the black eft with the effect of Provoked.
0052:[17:01:19] Critical! Khymerra Rhae's Light Thrust hits the black eft from the left for 94 points of damage.
0052:[17:01:19] Era Dilectio's Phantom Dart hits the black eft for 66 points of damage.
0064:[17:01:19] Dot Net's Raging Strike grants Dot Net the effect of Raging Strike.
0066:[17:01:19] The black eft is no longer provoked.

The numeric chat codes (first 4 digits) correspond to the chat filters in the Configuration settings. Those are crucial (but not absolutely necessary) for establishing the validity of each line in the context of whatever test I am doing. Being able to recover those is a priority if its possible.

Lastly here are some examples of things I have done in the past in the previous battle algorithm context. I would like to have the opportunity to provide similar results again in the coming months:

I cant post URLs so Google these:
"Test Central: Log Parse Results = MAX Attribute+Gear Effects"
"Deus Diabolus Lodestone blog"

Thanks, I look forward to whenever you can get around to this.

So what exactly is not being parsed or stored? I'm not sure what your asking for besides me cleaning up the text logs for u to pearlscript up.

I've read both the posts you linked before when you first did the testing. I re-read them since its been a good 12months since you posted them. Glad to get more testers but I rather fix the parser to accomodate what you need rather then what your asking.

[tachikoma]

You should read the last 3 pages of this thread http://www.bluegartr.com/threads/107...ey-work./page8

Kaeko shows in this thread (or his blog I can't remember exactly) that you don't need hundreds of tests to validate a test case but rather get the min/max and with the current avg distribution (not bell curve) it is easy to get meaningful results with limited trials. ~someone will probably be able to word this more appropriately

Use the export feature it gives you ALL of the statistics of a logging session in a text format, like max/min/counter/crit-max/crit-min/crit-counter/accuracy/etc same for healing.

If you have a statistic that is not tracked thoroughly enough I would rather address the issue in the parser itself.

[Kaeko]

To clarify what Tachi is talking about, the game has an equal chance of producing any value within a set range for both normal and critical hits, so the only real meaningful pieces of data are the MIN and MAX. You can get everything else from there so long as you can back up that your min/max are the actual min/max. The average is useful if you are not sure if what I just said is true and/or you believe that certain numbers in the given range can appear more often than others (e.g. critical hits in XI). So it still has a use, but at least for the testing I do, it is not immediately useful.

There are still many parts of testing where the parser is not sufficient though. For instance, it is not useful in "distribution" testing where you would require the exact number of times each particular value occurred. This was needed for say MEVA testing where there are set tiers and I needed to count the number of times each "tier" of damage occurred. So the parser is not an all powerful tool, but simply 1 of many possible tools.

[tachikoma]

How could I add distribution testing functionality?

[Kaeko]

It would require you to be able to list out every amount of damage you've taken (not just the min/max) as well as how often each amount appears. This is pretty "useless" data for the average parser user though. Testing to look for a specific "distribution" is really only useful if you're looking for tiers and there aren't many cases of this. I would say a more useful addition to the BG parser would be shoring up the block / parry / evade / miss rates. The parser also excludes partial resists right now, which may be useful knowledge.

[DeusBahamut]

Thanks for the reply. What I am really needing at present is a full breakdown of non/single/double/triple resist rates. I didn't even realize we didn't have block/evade/parry/miss breakdowns yet, and that's important too. But I figured doing a different type of export dump with all of the chat codes and chat raw data would be easier for you to implement. You're already storing all the raw damage values, probably just not the full chat lines. You could add a ticker in the options that would skip over that feature so it doesn't bog down the performance for the average user. It's not just the raw damage values that we are losing. There's a lot of other testing that is unique to seeing every type of log entry. I will give some examples below.

I'm still wondering if you capture and use the chat codes to add additional verification. I noticed that players whose name start with "The" are not parsed correctly. This leads me to think that those are not recoverable from the log files or are not being used.

As for the fact that it is a uniform random distribution across the min and max, that helps and will be useful for damage averaging. Those already require an insignificant number of trials compared to 'binary' feedback like critical, miss rates, and resist rates. For those rates we still need a huge number of trials. In the past I draw the line at 1000. To go beyond 1000 in my opinion is too much to be expected unless you're trying to derive the complete algorithm. If ACC+40 doesn't show a miss rate decrease after 1000 trials then obviously SE is not meeting our expectations.

Another feature I don't see is separating out the different mob ranks represented in the results, allowing me to test in many more areas without worrying about delta rank discrepancies. This introduces another factor of randomness to the results. More on that in later post.

Having the full chat dumps allows me to do many useful things you can't get with a 'stop' 'go' parser. Manually verifying and trimming the test range is important. Primarily it's manual editing of the test feed, to include taking out specific lines if I screw up and use a buff or debuff, or the mob uses a buff or debuff, or I want to specifically see the effect of when that buff or debuff is up, I create a flag and a new 'bucket' to throw the test data.

What I did in the past was separate out damage taken by the coblyn after it broke itself using Crystal Geyser. Things like that you'll never be able to implement in a general purpose parser.

I admire that you would prefer to strengthen your parser and I would love to give feedback for that on its strength and weaknesses. Know that I want to use my own as well because some people just prefer to have more power over their own testing when it sometimes takes weeks to hash out the test and reports and I often find other ways like above to save myself time and ensure the accuracy of my data. A lot of that time is saved by doing my own coding. That said, I appreciate your hard work and the milestones you've made with your parser.

[DeusBahamut]

Additionally if you provided a full dump of the chat lines, it would allow me to do some reverse engineering and catch any logic or parsing errors that may exist in your code, since you're keeping it closed source. Chat code verification has really saved me a lot of errors in the past while string matching. Personally I could care less about sharing my code if it means we have better tools out there. So I will be giving you information about my code.

[DeusBahamut]

To explain a bit more about the mob rank feature, where you create a separate bucket for each mob rank, this was done by collecting data per 'battle' where at the end the experience points value I used to derive the mob rank. I used a hash table of pointers pointing to each bucket (collection of damage values/miss rates/etc for the associated mob rank) where the key of the hash was that experience point value. At the end I ran reports on each bucket and I selected those that I had manually verified were the correct full experience point values (previously when you killed a mob sometimes it would award a fraction of the total SP) and copied them into the Excel table and published the results.

The caveat is you have to make sure you are only killing ONE mob at a time, which now really sucks for farming because you normally AOE, but it's the price you pay for accurate and delta rank dependent data. It would be pointless to build this feature into your parser since few people would be so masochistic as to kill one mob at a time. But that's how you get mathematically true results.

[DeusBahamut]

Additionally saving the raw data in a controlled test is very useful because I might not think to run a specific test until after I'm already done. Like in one case my weapon broke and I didnt notice and I was able to take that section out, and also see the difference between normal and yellow performance.

When you have enough controlled tests put together, you can start testing other variables. Say I want to compare fighting a group of Rank 25-29 mobs to a group of 45-49 mobs. I won't feel the pressure to ensure every parameter is evaluated at the time of the test, but can adapt the parser later and rerun the raw data through the parser. I might not have even intended to test damage taken for example, but since I wrote down all the stats, and have the raw data, I can later make those conclusions without any further in game testing. I never got to this point last year because I knew everything was going to change and just wanted to prove how broken everything was so they'd fix it. Now I want to see if everything is in fact fixed post 1.21. It's not the first time we've seen them repeat the same mistakes.

[DeusBahamut]

In my parser I treated single double and triple resist rates as an average because in my tests I 'usually' never saw but one type of resist. I only did one controlled test series with spell casts, and that was Scourge and Scourge II. I wonder if they even had so many resist types back then. Anywho, they were bucketed in my parser by the fact that it says "spell was partially resisted". At least that separates it from the 100% and 0% case. Implementing the logic below did not make sense at the time due to announced changes to battle algorithms.

**Here's pseudocode for creating the non/single/double/triple resist rates distribution.

int min = minimum spell damage observed

int max = maximum spell damage observed

int threshold = Mapped out the damages creates grouped clusters. The threshold attempts to estimate the random distribution range of each tier of resist ( 100% 75% 50% 25% ), such that it equals the (max-min/2) of the largest range of all of the observed grouped resist tier ranges. The job of the threshold is to group the damages and then we can easily find the max and min for each group. The challenge is it must do this universally without first knowing the data. Fortunately a large value will not cause problems due to the relative huge gap in between resist groups. Id recommend a constant but we could use a percentage depending on how damage scales in the damage formula to cover the most types of test cases where numbers are very large or small.

Threshold Example: In Kaeko's Magic Evasion test, first chart, on his blog the largest max-min of each resist's damage range was on the triple resist = 5 (48-44+1). So a threshold of as little as 3 (round up(5/2)) for the first chart would do the trick to chart out the plateau for all the resist tiers.

Side note: We ignore 0% fully resisted damage because that is reported in game as a miss. It even has a different chat code and message. At least pre-1.19 that was the case. Some things changed from what little I have seen of chat codes since.

Side note 2: We should also separate out the unresisted spell damage values as we already know what tier those belong to. This will increase performance when evaluating the 3 resist tiers.

array S = array of spell damages observed

new array M[ size = max-min+1] = Mode of damage occurrences of value "minimum+index" plus or minus threshold
//initialize array M to all zeros

for ( int i=min; i<max; i++)
{
//Record incidences (mode) of damage i plus or minus a threshold occurring
for ( j=0; j<S.size(); j++)
if ( S[j]>=i-threshold && S[j]<=i+threshold )
X[i-min]++;
}

//Charting out X would result in a set of 'hills' or 'plateaus' with a peak in the area of an unknown resist tier. If it's not a hill or plateau then you didn't get enough data and your average damage prediction will not be as accurate. If your threshold is too small it may result in an equivalent mode value creating a 'plateau'. If your threshold is too large it may overlap into another resist tier, but it would have to be pretty large.

Since you mapped out the plateau in the matrix you can count how many plateaus you have to check against what is expected, that it does not exceed 3 (75% 50% 25%). Remember 100% should not even be in this evaluation phase because it's a different chat code. With this check any stray values that are not part of one of the 3 plateaus should be thrown out as a safety.

Choose the 3 largest values in X that are not within threshold*2 distance of each other. These are the rough center of your resist ranges. One efficient way to do this (in C++) is throw them on a multimap (max-heap) and pick them off. The key is the mode, 'X[i]' and the value is 'i'.

You should then average the max and min values which are close to (roughly threshold distance from the center of the plateau) the foots of the hill/plateau to represent your 'true average' according to the philosophy of uniform random distribution we are subscribing to. This is your "average expected damage from that tier resist", call it 'average'.

To assign that tier as single/double/triple resist you would then compare these 'average' resist tier values to the 'average' 100% unresisted value (this may not exist in the larger data set at all).

For example:
y= mode peak value for that tier resist
x= unresisted spell damage, 100%. Note this MIGHT not be the maximum above if all spells casted were resisted. In this case you would need to compare to other partial resists instead. You will know if the 100% unresisted damage exists by the chat message itself. You will also be able to count the number of peaks to assess if all resist types were represented or not. In most cases some resist tiers will not be represented in the data. For example in Kaeko's test, there were no cases where he was damaged in full by the Scream.

comparethreshold = As far as the parser knows, the 75% resist is actually the 100% unresisted, UNLESS you implement a tight 'compare threshhold' (below), as 75%*(.66)=50%, it may mistakingly assign the 75% as 100% unresisted and the 50% as a 75% resist (this would occur if the compare threshold was 0.16 or greater). But if you make it too tight the fluctuation due to the data may be too skewed to accurately assign it a resist tier. I'd say 0.05 is generous enough to start.

if (x*0.5+x*comparethreshold>=y && x*0.5-x*comparethreshold<=y)
//Then y is the 'average' of the double resist 50% tier

It's much easier to sort and eyeball data like Kaeko did to chart out a resist profile manually, but this is one equivalent way to do it in code. I'm sure some optimizations can be made. btw Kaeko I thought your resist profile theory (where the resist rate changes due to MACC/MEVA are universal, and your image is a rough representation of it) was pretty cool. If we can just prove that receiving elemental damage and dealing it operates on the same formula. It would be pretty disturbing if it didn't, because that would mean mobs do not have their own full stat profiles respective to ours and PvP would be a mess to balance.

[tachikoma]

your crabby example sure looks like its reading from RAM which my program does not do. If you want timestamped output like you have in the example a few posts back that is something you should ask the other parser guy about. I"m not going to read from RAM with this until 2.0 and they release an API so I can talk with ffxiv directly.

The program does store the log files already in a backup file named by timestamp when you stop and start the parser, its not pretty but it does work. I'll work on getting the code at the start of each line, for simplicity I ignored this and used string matching to identify dmg dealt/ dmg taken/ healing/ blocks etc.

Right now evade is not shown in the log, I'll combine all "misses" into the players evasion counter. I dont' have any logged examples of a parry so if you have the text for parry right now i'll add that in too.

[tachikoma]

New version out: http://www.bluegarterls.com/forums/topic?id=8&p=6#p1876

addresses all the current issues including evasion/parry/block rates, and player names starting with "The". More accurate parsing results and less prone to break from bad log input.

Also has the raw line dump as requested.