Working Parser?

[nekura]

How difficult would it be to implement something that allows the user to select which POL process they want the parser to watch?

[Amele]

How difficult would it be to implement something that allows the user to select which POL process they want the parser to watch?

I'll have more time in a couple weeks and can look into it if someone else doesn't get to it first. in the meantime this work around should work for you:

step 1, start client you want to parse
step 2, start parser.
wait for parser to confirm active link.
step 3, start other client(s).

I realize this won't let you parse multiple clients at the same time but it should at least let you control which client it finds when you start the parser.

[LinktheDeme]

some reason its not working for me anymore D:

memloc is what its supposed to be.

Tried taking timestamp off too didnt resolve issue.

Also tried changing to the new version and nothing ;/

[Cream Soda]

Could anyone add a feature to the parser to also detect number of Feather tickles or TP reset to 0?

[Motenten]

Could anyone add a feature to the parser to also detect number of Feather tickles or TP reset to 0?

KParser does that; check the Debuffs page. Also, 1.0.8 has been released.

Edit: Suppose I should put the link in here: http://code.google.com/p/kparser/

[Amele]

Could anyone add a feature to the parser to also detect number of Feather tickles or TP reset to 0?

we could, although I would rather just implement a generic TP-moves taken, rather than checking specific things like feather tickles.

[Deathgazer]

Do it

[Cream Soda]

we could, although I would rather just implement a generic TP-moves taken, rather than checking specific things like feather tickles.

That would be awesome, but i'd still like a specific thing for feather tickle.

[Wenslydale]

KParser does that; check the Debuffs page. Also, 1.0.8 has been released.

Edit: Suppose I should put the link in here: http://code.google.com/p/kparser/

VERY Nice! It's actually working for me now! Good Job and keep up the good work.

[Motenten]

Another update to KParser (v1.0.9 at http://code.google.com/p/kparser/), though only a couple of additions.

First is the addition of access (via dialog; check the Tools menu) to a small field in the database to store player information. When I originally designed the database I considered putting automated job info there by pulling seacom data or the like, but it never really worked out. Unfortunately I left it fairly small -- just 100 characters. While recording job info for each player in the parse is probably useful, I also recently realized people will probably want to store things like full gear set info as well, and that's just not feasible with its current size. This will be changed in the next database revision.

To go along with that, I added a small little plugin page to show the player info that's been stored for the current parse file.


Second is the addition of detailed data for offense and defense damage per fight. Most people probably won't use it, but it can be handy if you're trying to do a more detailed statistical analysis of the numbers. The Defense Details tab could be useful for those studying shield block or guard rates/amounts, while the Offense Details would be handy for those studying random pDiff variance behaviors.

Processing for unrestricted mining of large data sets can get expensive, so it's set on a minimized value while parsing is active.


Also has a fix for totaling -ga spell damage.

[ringthree]

Is there a way that anyone could add to either parser a way to output the info to an XL spreadsheet? I figure this has to be incredibly easy, but is far beyond my field of knowledge. There is so much I could do with the information if it was easily manipulatable in an XL spreadsheet and it would allow much easier testing of things like pDIF, crits, etc.

[Amele]

Is there a way that anyone could add to either parser a way to output the info to an XL spreadsheet? I figure this has to be incredibly easy, but is far beyond my field of knowledge. There is so much I could do with the information if it was easily manipulatable in an XL spreadsheet and it would allow much easier testing of things like pDIF, crits, etc.

would you be ok with it exporting into csv or a similar format?

[Motenten]

If you're wanting only the data currently being displayed, it should be possible (though it may be a bit tricky to do without duplicating a lot of work). If you want to customize it much beyond that, well.. at that point you might as well just start pulling exactly what you want from the database directly (or build a plugin that grabs the data you want, and export -that- to excel).

I'll see what I can do, though.

[Amele]

If you're wanting only the data currently being displayed, it should be possible (though it may be a bit tricky to do without duplicating a lot of work). If you want to customize it much beyond that, well.. at that point you might as well just start pulling exactly what you want from the database directly (or build a plugin that grabs the data you want, and export -that- to excel).

I'll see what I can do, though.

based on what his ideas for use are, I think he wants the full combat log pre-chopped (basically before it goes through the accumulators but after we filter for relevant lines).

[Zhais]

would you be ok with it exporting into csv or a similar format?

no need with C#, as we can load data directly into excel.

Long as I know exactly what to export to excel, would be fairly easy. Have all the code examples due to work for excel exporting.

[Amele]

no need with C#, as we can load data directly into excel.

Long as I know exactly what to export to excel, would be fairly easy. Have all the code examples due to work for excel exporting.

right, except csv is more flexible and less bloated...

I wasn't suggesting it because I didn't think we could do excel (about 80% of the code work I do at my job is either automating excel or exporting data to it) but because I didn't want to lock people into basically two ways of looking at the data (excel and oocalc)

[ringthree]

would you be ok with it exporting into csv or a similar format?

I would be ok with it exporting into something I have a freaking clue how to use. LOL So you might need to add a little explanation for that because I don't even know what CSV is. If it is basically just another spreadsheet I should be able to figure it out.

For DirectParse, since you can get the chat log dump, and I think that is basically where the numbers are pulled from, I thought it would be pretty simple to just add a function that just populates an XL spreadsheet (which I believe is a similar function to what it already does).

based on what his ideas for use are, I think he wants the full combat log pre-chopped (basically before it goes through the accumulators but after we filter for relevant lines).

I had a dog and it's name was BINGO!

If we know constants about gear then we can use the raw numbers, ranges, etc. to figure out potential pDIF ranges for normal hits and crits, and then we should be able to work backwards and figure out general ideas about all mobs stats.

I did a little work by hand and found out that at least for two-handed weapons the old pDIF function is wrong and needs to be fixed. It would also be much easier to test crit theories this way, etc.

right, except csv is more flexible and less bloated...

I wasn't suggesting it because I didn't think we could do excel (about 80% of the code work I do at my job is either automating excel or exporting data to it) but because I didn't want to lock people into basically two ways of looking at the data (excel and oocalc)

While you guys may all work in the computer industry, I am a librarian that just likes numbers. All we use at work are inflexible and bloated MS products. I do have a slight better understanding of excel than the average retard and can use the functions in it for calculations and graphing which is my main goal.

BTW, Amele, can I have your babies? LOL

[ringthree]

Delete, see post above.

[Amele]

csv is 'comma separated values' - it's basically a text file version of a spreadsheet, where the values for each cell are separated by commas.

because it's ASCII and an open file format it's importable into a variety of math/array based applications, including excel (but not limited to)

whereas an .xls format file is really only readable by two applications (MS Excel and open office calc) and .xlsx is only readable by one (Excel 2007).

and unless you're a girl I don't think you are capable of having my babies lol.

[Zhais]

right, except csv is more flexible and less bloated...

I wasn't suggesting it because I didn't think we could do excel (about 80% of the code work I do at my job is either automating excel or exporting data to it) but because I didn't want to lock people into basically two ways of looking at the data (excel and oocalc)

fair enough!

and damn, I thought you were female as well damn you people and your mix & match gender character combinations