Working Parser?

[Croaker]

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.

You are right.

I was thinking that (delay/60) of the fastest melee was <<<<<< than kill time, but there will still be error.

Even with some error, anything you can come up with will be vastly superior to the current metric of "we got chain 100" or "I outparsed a MNK by 2%".

[Xrave]

Since you're already scanning the game memory for damage done instead of parsing log files, is there not a value in there somewhere that indicates whether or not you're actually engaged (weapon drawn) and can just use the time that you have your weapon out to calculate DPS?

[Amele]

<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.

which just moves the problem over to another area (you're effectively proposing to skip up to 25% of most merits)

@croaker:
a cleaner way is to trigger off <player> does action as start and to use some duration of no action as stop (And then roll back the timer count slightly to account for the non-action) which is what I had originally suggested. additionally, if you track each player individually (probably by adding: an accumulator, a timestamp, and a flag) you can get 'fairer' dps results for individuals, which would also help identify which players are doing better dps but are losing in the overall damage parse due to slow engaging or not being engaged (which might actually help improve some player's play)

this prevents long periods of inaction from dropping your dps and is also greedy enough to avoid losing single or double delays from kill switching.

[Zhais]

Since you're already scanning the game memory for damage done instead of parsing log files, is there not a value in there somewhere that indicates whether or not you're actually engaged (weapon drawn) and can just use the time that you have your weapon out to calculate DPS?

What we're scanning is all the information that goes into those log files, but we aren't waiting for the game to update to the files. Engaging/disengaging doesn't show up in the chat log, so we can't detect that.

[Amele]

Since you're already scanning the game memory for damage done instead of parsing log files, is there not a value in there somewhere that indicates whether or not you're actually engaged (weapon drawn) and can just use the time that you have your weapon out to calculate DPS?

What we're scanning is all the information that goes into those log files, but we aren't waiting for the game to update to the files. Engaging/disengaging doesn't show up in the chat log, so we can't detect that.

this isn't strictly true; I could modify the chat monitor to provide other data if we found a use for it zhais; (like say, your own player name)

but to answer xrave's question: no, I don't know if there is an easy way to detect whether or not a given player is engaged. unfortunately, SE doesn't exactly give us an api interface :3

[Zhais]

Since you're already scanning the game memory for damage done instead of parsing log files, is there not a value in there somewhere that indicates whether or not you're actually engaged (weapon drawn) and can just use the time that you have your weapon out to calculate DPS?

What we're scanning is all the information that goes into those log files, but we aren't waiting for the game to update to the files. Engaging/disengaging doesn't show up in the chat log, so we can't detect that.

this isn't strictly true; I could modify the chat monitor to provide other data if we found a use for it zhais; (like say, your own player name)

but to answer xrave's question: no, I don't know if there is an easy way to detect whether or not a given player is engaged. unfortunately, SE doesn't exactly give us an api interface :3

oh, I know. Just saying we aren't explicitly handed that info with our current methods :D

And I'd assume there is some value for engaged or not, as the music changes upon battle. Would just have to find it in the memory structure like we did for the parser, albeit much more difficult since it doesn't rely on text ;;

[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.

which just moves the problem over to another area (you're effectively proposing to skip up to 25% of most merits)

We're not trying to get exact super-accurate dps here though, just a benchmark to tell how much atk to use vs how much haste etc.

[Amele]

right, but why choose a less accurate method if you don't have to? it isn't particularly faster to code either way really.

I'll work on a dps feature when I have the opportunity.

[Blubbartron]

It's nice to see that this project has been taken up again. I've always preferred this parser method to the others I've stumbled across. One thing I've always been curious about though; just what is adjusted counter % anyway? Is it simply your calculated counter % multiplied against accuracy (to adjust for the accuracy check portion of countering)? But this seems wrong, because counter % should already include that adjustment as the check was made in game. As you can see, my problem gets rather circular and confusing.

[dvsparse]

Been a long time, but I think it's your parsed counter% with your accuracy REMOVED, so you can get a true baseline. It makes it more useful for testing equipment that has +Counter. Without removing the accuracy check nobody will ever get consistent numbers testing +counter gear.


And about the dps counter, consider the situation where the mob is killed while you are out of range to see the death message.

[Breemer]

And about the dps counter, consider the situation where the mob is killed while you are out of range to see the death message.

you could use the exp gain or the "too far to gain exp" messages right? i realise that wouldnt work on mobs that dont give exp but then it should be possible to use the defeated, if you're out of range of a mob that doesn't give exp why would you want to know your dps?

[Zekyr]

Might be a small glitch, but my Parry and Evaded stats seem to be additive, i.e. I'm gaining 10% per time I do rather than it being an actual percent.

I'm up to 340% evasion right now, lol.

[Zhais]

Might be a small glitch, but my Parry and Evaded stats seem to be additive, i.e. I'm gaining 10% per time I do rather than it being an actual percent.

I'm up to 340% evasion right now, lol.

o.o

[retice]

Seems the new version doesn't parse the drops from the fights. and I have the box checked in settings to do so.

[Hakamaru]

Might be a small glitch, but my Parry and Evaded stats seem to be additive, i.e. I'm gaining 10% per time I do rather than it being an actual percent.

I'm up to 340% evasion right now, lol.

Are you fighting 2 different mobs at the same time? I remember seeing this when I farmed Wild Karakul and they'd pop fleas.

[Croaker]

Seems the new version doesn't parse the drops from the fights. and I have the box checked in settings to do so.

Uh OH! I NEED that. Keeping drop stats while farming is 80% of what I use the parser for.

[Hakamaru]

Seems the new version doesn't parse the drops from the fights. and I have the box checked in settings to do so.

Uh OH! I NEED that. Keeping drop stats while farming is 80% of what I use the parser for.

And this is exactly why the MEMLOC needs to be read in from a file. This feature is broken on every version of the parser that works with the current MEMLOC. If the config file had been supported earlier, he could roll back to whatever version he had that worked and just enter the current MEMLOC. Now he's screwed til someone gets time to fix the loot feature.

[Zhais]

Seems the new version doesn't parse the drops from the fights. and I have the box checked in settings to do so.

Uh OH! I NEED that. Keeping drop stats while farming is 80% of what I use the parser for.

And this is exactly why the MEMLOC needs to be read in from a file. This feature is broken on every version of the parser that works with the current MEMLOC. If the config file had been supported earlier, he could roll back to whatever version he had that worked and just enter the current MEMLOC. Now he's screwed til someone gets time to fix the loot feature.

I should still have all my files... I'll see if I can't find out later what the differences are.

and btw people, use the sourceforge for reporting bugs! a lot easier to keep track of them that way, and I also get e-mail notifications when they are placed up.


edit: I lied, I don't get email notifications. Thought I set that up use sourceforge!

[Amele]

Seems the new version doesn't parse the drops from the fights. and I have the box checked in settings to do so.

Uh OH! I NEED that. Keeping drop stats while farming is 80% of what I use the parser for.

And this is exactly why the MEMLOC needs to be read in from a file. This feature is broken on every version of the parser that works with the current MEMLOC. If the config file had been supported earlier, he could roll back to whatever version he had that worked and just enter the current MEMLOC. Now he's screwed til someone gets time to fix the loot feature.

I was under the impression that the drops were read right off the chat list and not from the treasure memory block? (I really need to spend a weekend just reading through this application start to finish lol)

[Hakamaru]

I just found the problem with Evades & Parries. It's stupid-easy to fix evades, and I have that done now. Parries will take a little more testing, but hopefully I'll have it up on SourceForge tomorrow.

I have a question for everyone though. For the parry rate, would you be interested in seeing the raw parry rate (numParries / (numParries + numEvades + numMeleeHits))? Or would you rather have the evades left out of the denominator? That would report your parry rate of hits that got past evasion-check.

Edit : there is one small issue I see on top of the calculations being messed up in previous versions. Hits for 0 are not being reported as anything as far as I can tell. Hopefully, no one cares too strongly about that, but I can look into that as well some time. I'll get the big fix out ASAP, then worry about this minor issue later.