Working Parser?

[Bestovian]

I just want to take the time to thank everyone involved with this project. Parsing, to me, is something that makes this game SOOOOOOO much more interesting and drives me to make my characters better. I do, understand the circumstances involving Kalia's exile from our little world - but I think that the work he did on the parser is and has been a bit undervalued - regardless of where his starter code did or didnt come from he spent alot of time working on the parser which is something many of us didnt do. That being said, again thanks to everyone who has and will work on this project in the future because lord knows I dont have the time to help out.

Yeah I 2nd this as well.
Thanks guys and gals for all your time and effort into the project from DVS all the way down the pole.

[Amele]

so, yeah; a dps feature could be added (relatively easily) but that doesn't mean a useful dps feature could be added relatively easily.

if there's a way to detect engaged status that might be best. if there's a way to detect *everyone's* engaged status that'd be even better. etc.
[/size]

Frankly it doesn't need to be complex, DPS over the course of the battle should be sufficient. I know that EQ2s most popular parser tracks your average DPS over the course of the fight and everyone uses that and not your "engaged DPS" since your true performance (ie usefulness) is not in spike damage but over the course of the entire fight.

question: when you say course of the fight, do you mean over the entire parser log or per fight?

entire parser log is trivially easy and frankly I doubt it'd be useful; it's dirtied by all sorts of outside considerations (how long has your parser been running, how much of that was standing around while you waited for fafhogg to pop. etc.) and it's just a matter of taking total damage column divided by time parser is running.

engaged dps would give an accurate indication (of melee dps) but would potentially be inaccurate for non-melee damage (too low for dinosaur chi-blast monk rotations and blackmages and too high for med->ws) this might be implemented depending on what sort of indication there is in the memory map that a character is engaged (I don't know if there is)

actual per fight dps would be ideal but it's very difficult to determine when a fight actually starts with non-nm mobs.

another option would be to use the first hit or miss recorded by the parser for each player (timing out after some heartbeat.. 10 seconds of no combat related parse lines?) as the 'start' indicator and just drop the first value from the dps calculation.

since in theory it takes just as long to make that first swing as it takes from swing to swing - this would work fine for melee based dps.

for magic dps cast time is the primary concern and it is common for the 'first' nuke to be the largest if the magic dps starts the fight; so it may skew results there slightly. (using 'small' damage like bio or fire to prime the dps values might be an option) although I suspect that magic dps is slightly less interesting to blackmages than melee dps is to melee.

[Croaker]

for magic dps cast time is the primary concern and it is common for the 'first' nuke to be the largest if the magic dps starts the fight; so it may skew results there slightly. (using 'small' damage like bio or fire to prime the dps values might be an option) although I suspect that magic dps is slightly less interesting to blackmages than melee dps is to melee.

It sounds like you have a good solution for melee dps, but the hangup is it wont apply to magic dps. Are mages even interested in dps? They arern't continually casting small spells like melee are continually swinging. % of total damage and high damage might be all the information they desire.

As a melee, the reason dps would be so usefull is that parsing vs. person X in a first party isn't going to be the same standard as person Y in a second party. Sometimes I will try to evaluate a piece of gear or food by making the change and restarting the parser during the same party, but I have no guarantee that the performance of the people I parsed against was a constant.

[Sykes]

another option would be to use the first hit or miss recorded by the parser for each player (timing out after some heartbeat.. 10 seconds of no combat related parse lines?) as the 'start' indicator and just drop the first value from the dps calculation.
...
I suspect that magic dps is slightly less interesting to blackmages than melee dps is to melee.

This makes the most sense to me. I think that the key reason one would want a DPS calculation is to be able to test optimal DD strategies independent of the other people in the party. While magic DPS is important, it is much more easily measured independent of other variables because it comes in infrequent large bursts. As a Black Mage, I know that my setup that created a 1600 damage Burst II is more effective than the one that generated 1550 damage. As a melee, measuring the impact of attack vs. haste isn't quite as easy (it can be modeled pretty easily, but measuring is more difficult). I would definitely separate out melee and magic DPS (eg. Melee DPS, Magic DPS, and Combined DPS columns).

Keep in mind that while it is important to be as accurate as possible, accuracy is not nearly as important as consistency. The number itself is minimally important, but how that number changes or differs between players can provide a lot of useful information.

[Amele]

right; which is why I think the ideal would be 'engaged' time only for melee. (you'd have an outlier at med->ws times since you'd be engaged for a few seconds each minute - but it would be highly obvious) it isn't really fair to compare the dps of someone engaged the whole time versus someone engaged half the time if the 'half time' is being divided by the full time.


the issue of course is that this proposed solution adds alot of additional timers and overhead to directparse as written... it might be easier to make a smaller lighterweight subform that just does dps (using the chat monitor library from directparse as the jumping off point.) which could be launched only when someone actively wanted to track dps.

I'll start some work on something to do this but I can't promise how fast it'll be out - I've got to work 50-80 hours a week until the end of the year probably.

[Breemer]

my version of directparse is saving dumps to "C:\Program Files\Creative\Creative NOMAD Jukebox Zen Xtra\NOMAD Explorer\Dumps" instead of where the program is located at "G:\Share\Games\FFXI\DirectParse_2.0_Release\Dumps " and the browse button is greyed out, want me to post it as a bug on the SF project?

[Amele]

my version of directparse is saving dumps to "C:\Program Files\Creative\Creative NOMAD Jukebox Zen Xtra\NOMAD Explorer\Dumps" instead of where the program is located at "G:\Share\Games\FFXI\DirectParse_2.0_Release\Dumps " and the browse button is greyed out, want me to post it as a bug on the SF project?

check your %path% variables first; but it's probably a bug either way; I just suspect the reason it's not working is because ~\nomad explorer\ is in your path and it's finding a dumps folder.

[Breemer]

my version of directparse is saving dumps to "C:\Program Files\Creative\Creative NOMAD Jukebox Zen Xtra\NOMAD Explorer\Dumps" instead of where the program is located at "G:\Share\Games\FFXI\DirectParse_2.0_Release\Dumps " and the browse button is greyed out, want me to post it as a bug on the SF project?

check your %path% variables first; but it's probably a bug either way; I just suspect the reason it's not working is because ~\nomad explorer\ is in your path and it's finding a dumps folder.

I searched through the registry and looked in my environment variables and found no reason for it. I should have mentioned that the dumps folder isn't actually there, however in checking the nomad folder there are some files from punkbuster there so it is obviously something on my pc, is there any way to un-grey the browse box?

[Gere]

Is there a reason this wouldn't work?

When a player damages <mob name>, start dps timer.
When <mob name> is defeated, stop dps timer.

[Amele]

Is there a reason this wouldn't work?

When a player damages <mob name>, start dps timer.
When <mob name> is defeated, stop dps timer.

greater colibri. (or any other non-nm mob that you might pull more than one of or otherwise link before the other dies.)

what would work is:

when <player> records a combat action (attack/miss/weaponskill) start timer.
when <player> fails to record a combat action for some period of time (10seconds to 1 minute?) stop dps timer.

but this adds (potentially) alot of extra logic.

edit: "non-nm merit" is redundant with respect to the point I was making

[Breemer]

Nevermind about my previous posts, I realised what I did, i dragged the program to the "pinned" part of the start menu instead of a shortcut to it /facepalm

[Zhais]

Nevermind about my previous posts, I realised what I did, i dragged the program to the "pinned" part of the start menu instead of a shortcut to it /facepalm

haha, I was wondering about that :D all file system stuff right now is set to the directory that the .exe is currently in. I believe I disabled the browse functionality because it didn't work altogether or didn't work after setting a new directory. That's something we'll have to look at ((add it to SF!)).


Amele: you going to want to join the Sourceforge project?

[Amele]

Zhais: probably but I can't promise how active I'll be. (I think I mentioned earlier that I'm pretty damn busy until the end of the year )

[Zhais]

Zhais: probably but I can't promise how active I'll be. (I think I mentioned earlier that I'm pretty damn busy until the end of the year )

np! Its the same for me, same for everyone else :D I myself am getting close to the end of this semester, so I have 3 projects going simultaneously ;;

sign up on sourceforge and lemme know your username if you want~ Noone is obligated to spend more than 5 minutes if they don't have time to ^^

[Gere]

Is there a reason this wouldn't work?

When a player damages <mob name>, start dps timer.
When <mob name> is defeated, stop dps timer.

greater colibri. (or any other non-nm mob that you might pull more than one of or otherwise link before the other dies.)

I don't see how that matters at all to the true value of your dps.

[Jer]

Is there a reason this wouldn't work?

When a player damages <mob name>, start dps timer.
When <mob name> is defeated, stop dps timer.

greater colibri. (or any other non-nm mob that you might pull more than one of or otherwise link before the other dies.)

I don't see how that matters at all to the true value of your dps.

If all mobs are named the same and there are actions being performed on them, it will not be able to tell if the one that died first was the first you attacked, what actions occured to each mob, etc skewing it's results. If damage was actually being done at the same time, the first mob to die would have an inflated dps number while the next to die would be lower. I think that was the way it was explained earlier.

[Amele]

^ this is the gist of why the suggested method would not work. it is impossible* to distinguish whether the mob that just rolled past as defeated was the same mob that you were attacking the last time you swung. (or indeed, if it was even your mob depending on filters).

*to my knowledge

[Croaker]

If all mobs are named the same and there are actions being performed on them, it will not be able to tell if the one that died first was the first you attacked, what actions occured to each mob, etc skewing it's results. If damage was actually being done at the same time, the first mob to die would have an inflated dps number while the next to die would be lower. I think that was the way it was explained earlier.

Its not damage per mob. Its just damage per second. I doesnt matter if there are 100 mobs with 100 HP or 1 mob with 10,000 hp. All that matters is how long it took you to do 10,000 damage. The error comes from periods of time while you are waiting for a pull to arrive. If multiple mobs are always pulled then you have the least error because it approaches the results you would get from 1 mob with infinite HP.

The mobs themselves are just an on/off trigger for the counter so you can reduce the error from long pulls. The actual dps should still just be player damage divided by counter time and no way be tied back to particular mobs.

[Amele]

If all mobs are named the same and there are actions being performed on them, it will not be able to tell if the one that died first was the first you attacked, what actions occured to each mob, etc skewing it's results. If damage was actually being done at the same time, the first mob to die would have an inflated dps number while the next to die would be lower. I think that was the way it was explained earlier.

Its not damage per mob. Its just damage per second. I doesnt matter is there are 100 mobs with 100 HP or 1 mob with 10,000 hp. All that matters is how long it took you to do 10,000 damage. The error comes from periods of time while you are waiting for a pull to arrive. If multiple mobs are always pulled then you have the least error because it approaches the results you would get from 1 mob with infinite HP.

did you read what gere suggested as a response to my initial post?

Is there a reason this wouldn't work?

When a player damages <mob name>, start dps timer.
When <mob name> is defeated, stop dps timer.

<mob name> is the trigger that he's asking about as start and stop. this gives stupid behavior in constant chain situations because you stop when something is killed then start on the next swing.

over time you lose (delay/60) seconds per mob you kill if you do it this way. even assuming you're the only party in the area. artificially inflating your dps.

if there are multiple parties in the area killing the same mob then you see (delay/60) seconds of time lost per mob of that name killed within range of your chat window artificially inflating your dps.

this is why the system doesn't work; it doesn't approach a mob with infinite hp at all. it degenerates the faster you pull. (which is why I addressed merit in specific as where it would not work.) The error doesn't come from waiting or not waiting. the error comes from not timing when you should be or timing when you shouldn't be and that's algorithmic and has nothing at all to do with actual player behavior except where player behavior interacts with the algorithm.

[Gere]

<mob name> is the trigger that he's asking about as start and stop. this gives stupid behavior in constant chain situations because you stop when something is killed then start on the next swing.

over time you lose (delay/60) seconds per mob you kill if you do it this way. even assuming you're the only party in the area. artificially inflating your dps.

Skip the first swing then.