Possible new Parser (Suggestions required)

[Daladran]

Recently, I decided that I'd like to make a new log parser (Long story) to be used for the Mac. Now, I have some good ideas as to what I'd like it to do (listed below) but I'd like to know what else should be put into it. Also, what would you consider the best way to calculate DPS (Based on the timecode provided by the log or otherwise)? I'll be basing my layout on the last version of YALP and I'd like to include the majority of the features provided by it (export into HTML, graphical layout of damage, etc...). This probably won't be a real time log parser.

Currently I'm considering:
Having a separate tab that parses statistics for unique text skills (Like Slay Undead)
Associating mobs and timecode, thus the ability to break down stats by individual mobs and by types of mobs

All comments, suggestions, criticisms welcome. It'll be awhile before I put up my first build (As I'm still acclimating to Xcode), but the more features I know I'd like to include before hand will make the process go much more smoothly for me.

[Brohg]

Have you investigated getting on board with the Gambosoft team and porting their existing software to the mac, rather than reinventing the wheel?

[Daladran]

I want to make a parser from the ground up, mainly because I want to learn as much as possible about Xcode during the process. This as much a project that I hope to use and hand out as it is a learning exercise. Also, I want to do some stuff specific to the Mac (In terms of presentation and coding) that might be difficult to implement by using someone else's code.

It might be reinventing the wheel, but I know it'll be my wheel and that I'll get the most out of it (In more ways then one).

[Gamanern]

How serious do you want to get with your parser. Are you looking at making a viable competitor to the existing Windows based programs, or just wanting to build something as learning exercise?

If you want, you can use my features page as a good start for what features to add:

Similarly, you cna use my instructions page to see how I separated the information and what output options I offered:

For slays, I simply interpretted when an attack was actually a slay, then changed it to type 'Slay' so I could then see how much damage was against slay, as the example below shows (with name changed to protect the innocent):

/tell Pally Pally -vs- Longhorn Krond the Unliving: -- DMG: 142535 -- DPS: 1096 -- Scaled: 1033 -- Slay: 81516 -- Slash: 58840 -- DirDmg: 1197 -- Bash: 982 -- Non-crit rate: 79.4% -- crit rate: 20.6% -- Attempts: 88 -- Hits: 63 -- Missed: 22 -- Defended: 3 -- Accuracy: 74.1% -- Avg Hit: 2262 -- Max hit: 25625 -- DMG to PC: 0

Obviously that is only the quick output to send in a tell, but in the interface and full HTML output, you will see further.

Now, I am not trying to discourage you, or say you should do things my way, just that you can approach each task from MANY different ways, and that some of them may integrate with your other ideas better.

Beyond what you will get from the links above, some of the really advanced ideas that I never implemented, if you ever wish to get really extravagant with your project are:

* Intergrate with Excel, so at the click of a button it transfers the fight information into Excel (using a template file with advanced VBScript macros already in place) so you analyse the data further, allowing people to build third party Excel templates to do further features, allowing the community to contribute to your project. This also has the advantage of free publicity of your core product as others need to reference it when they release their own template addins ... maybe I should dust off the old project and put that in too ...

* Integrate with databases, so you can transfer parse information straight to a MySQL (or whatever DB you choose) so you can easily post your parse information to a DB on the internet, and with a matching PHP script people could then easily access the information within the guild, allowing them to easily collate large amounts of information, like tracking a single person's DPS across multiple fights etc.

* Incorporate a FTP client into the program so it can upload a HTML output to the net without needing to use a second program, and if you want, providing the user with a link to the location of the file that can be easily paste into a guild's forum, perhaps have options on how to format the link to fit with the different forum software out there like phpBB and vBuliten.

* On the items looted page, make double clicking open the item in Lucy etc. Make the action configurable so people could link to their internal DKP website if interested.

* Track conversations, so all teh usual channels plus tells and user channels.

* Track a person's class for easy grouping of players for comparison.

If you are going to have a serious crack at this, I am more than happy to assist with any questions you have, though obviously in a different environment (Visual C#). I am also very well versed in interpretting the log file itself, so can assist there if you would like.

[Daladran]

Thanks for all the info, man!

In all honesty, this is more of a learning exercise. But, I would like to provide an alternative for Al'Kabor players. I recently gave the Mac server a shot and I noticed most people are depending on Parallels/Bootcamp/VirtualPC+Their favorite parser or they are running a basic home made operation. Competing with Windows based Parsers will never be my intention, I don't think I could ever develop something on my own to do such. The original idea was one based more out of convenience than competition. That being said, my intention has always been to provide a parser that displays as wide a variety of statistical data as possible. I don't want to overload users with info, but I want users to know they have just about any number they could possibly want.

I haven't fully considered how I would approach identifying the unique texts yet as I'm still testing the waters in Xcode. But, I'm certainly keeping all avenues wide open. Although, I am somewhat tempted to keep my project as a pure Damage/Efficiency parser without items/chat/trading/etc...

Again, thanks for the info and the help. I'll always take advice from someone who's used the log as much as you guys.

[Gamanern]

Well, starting with the real basics, you will have a few things that you want to work out, and some of those will affect how easy or hard it is to progress with the project. I remember after 3 months I had to rebuild the entire project so it had the flexibility to add in all the other features I wanted.

For an initial version, I would suggest at least the following:

* Define how you will store the data, in a super table with links, in a single table per opponent, or as a list of player tables within an opponent. This will affect how easily and fast you pull the information out later, more controls allows you to grab information faster, less controls makes the data structure easier to get a start on. Decide what numbers you want to generate, and from there what structures you need to achieve that. Can you build the stats as you load the data, or do you load the full data for a fight and then go back to analyse it.

* Work out which types of lines you will read in, and how to split the information out of those lines, so your melee, other's melee, non-melee (yours and others I think are the same), and damage over time (the mac version may not show other's DoTs) as well as whatever else you want about spells, crits, kill messages.

* Work out how to read in the file, and weather you do it as a single read, or if you create a process that allows you to pick up extra information as it becomes available. Making a parser is the hard part, making it live isn't too much extra work, and becomes easier when you plan your work with the assumption you will try to read in live mode later, or do as I did, rewrite your project 3 months later.

* Work out how to determine when a fight starts and ends, including when fights overlap (both 'a snake' and 'a bear' in camp at the same time, keeping their damage separate). Be careful how you handle fights that you don't see a 'slain' message, like when the opponent is out of range when it dies, you don't see the message.

* Work out how you are going to display your information. Will it contain many tabs for each type of information, or will it be a series of cells and any kind of information could be output to it.

That should give you a good place to start, and depending on how familiar you are with your development environment, and your previous programming knowledge, you could get something up and running in a week or two.