Incorrect Offense Details

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Solo any monster
2. Fight it long time (like 150+ hits)
3.

What is the expected output? What do you see instead?
When under Offense Details Tab, i select the last monster on the list, i 
expected to retrieve ALL damage i did by verifying with my in game log.
Instead, i retrieved them splitted through the 2 last monsters of the 
list, like if my damage were done on 2 distinct mobs... while actually i 
fought only one.

What version of the product are you using? On what operating system?
KParser 1.4.2 on Vista 32bits

Please provide any additional information below.

Original issue reported on code.google.com by raphael.morineau@gmail.com on 15 Oct 2009 at 1:26

[GoogleCodeExporter]

Did another solo parse on steelshells. I think i understood when that bug 
occurs: As 
soon as KParser reads on log "[NamePersonLambda] defeats the Steelshell.", KP 
thinks 
the mob currently fought is dead and starts a new one. Result: while i was 
soloing 
my mob, someone else were soloing too another mob nearby and killed his before 
me, 
then, from this point, KParser parsed next hits i did on a new "mob" (while in 
reality i'm always on same one still not dead), and ended up "splitting" my dmg 
into 
2 "mobs", one called "Steelshell(0)" with all dmg done between my previous mob 
kill 
and the other guy kill message, and the rest of dmg done on normal 
"Steelshell(100)".
Looks like KParser doesnot make check "if [PersonLambda] in same party as [me] 
then" ?
The repercussions of that "bug" affects greatly KP accuracy when for example 
someone 
wants to analyze a merit pt parse by selecting options "ALL" and "Exclude 0 exp 
mobs", which make them lose a good chunk of dmg done if another pt were 
meriting 
nearby.

Original comment by raphael.morineau@gmail.com on 15 Oct 2009 at 11:13

[GoogleCodeExporter]

This is definitely a bug, but unfortunately I haven't worked out a way to 
reasonably
fix it given the current database structure and the info available during a 
parse.

Have noted this as a requirement to consider when I revise the database 
structure. 
Will give more thought to possible ways of fixing it.

Original comment by Kinemati...@gmail.com on 2 Nov 2009 at 8:57

• Changed state: Accepted

[GoogleCodeExporter]

Just an idea that could helps you fix this issue:

Considering KParser is able of listing all names it "see" on log, an idea would 
be 
to have :
- 2 checkboxs "Party" & "Alliance",
- a field in regards of each of the 2 above checkboxs, for "PT Size" & "Ally 
Size",
- a checkable droplist (like the custom moblist) with names parsed.

So user can select the names in his PT or alliance, up to the size specified, 
provided KParser gets the names within the minute it started parsing.

Just an idea, there are certainly others maybe easier i don't know, hope that 
helps :)

Original comment by raphael.morineau@gmail.com on 2 Nov 2009 at 10:02

[GoogleCodeExporter]

As general info --

All log messages have a type code.  For this particular issue, you'd want to 
look at
the death codes (killing mob, not being killed): 0x24 for when I kill a mob, 
0x25 for
when someone in my party kills a mob, 0xa6 for when someone in an alliance with 
me
kills a mob, and 0x2c for when anyone else kills a mob.

All well and good (setting aside the issue of determining if any given mob is 
being
attacked by your or someone else, and whether they're claimed or free-for-all 
{ie:
besieged, campaign, /help}) if you're by yourself or in a standard party.  
However
pets (wyverns, avatars, puppets, jug pets, charmed pets, etc) all get flagged 
in the
'other' ("not in my party or alliance") category.  Well, it's possible to 
determine
which entities are pets, but what happens when the bst nearby has a charmed pet 
that
gets the kill?  How can you tell for sure whether it was your pet or someone 
else's?
 Perhaps you might ignore that for simplicity, but then what happens when -you- are
the bst with the charmed pet?

That's what would need to be considered on the programmatic side.  If instead 
you had
a user-settable flag to only include selected people in the list, you have the 
issue
of back-tracking data after the fact (if your crab was 'killed' by someone else 
that
you hadn't already marked, it's not easy to then, while parsing, change things 
so
that the crab didn't get killed at that point).  Also, it's secondary data; you
cannot perfectly recreate the original parse based on the records of what came
through the chat log without that info.  And of course you need somewhere to 
store
that flag, which is not possible at present (as I said, there are plans to 
revise the
database structure).

There's also the problem that I don't make very much use of the player type at 
this
time, partly because it was difficult to come up with any scenario where it was
useful to know, and partly because there are a number of ambiguous codes that 
could
be generated by different types of players (or even mobs).  In the case of 
battles, I
have a field to store the type of player that killed the mob, but not the type 
of
player that 'claimed' the mob (initiated action on it); that's my own fault, 
but it's
still a current restriction.  I'd also need to work on associating actions by
different types of players (you hitting your crab, the other player hitting 
their
crab) with the appropriate claimed mob type (though doing so would trash any
coherency in free-for-all situations).

On the party/alliance/etc checkboxes you're proposing, I do plan on including 
more
control over the descriptive aspects for recorded players/mobs, to more easily 
handle
including/excluding them in various reports.  I should probably look into a more
high-level solution, though.  Instead of saying "don't include 0xp mobs", it 
should
be "don't include mobs killed by non-party members".  Adjusting things to make 
that
actually feasible will take some work.

Anyway, just some ramblings to help explain the problems with this bug.

Original comment by Kinemati...@gmail.com on 2 Nov 2009 at 10:57

[GoogleCodeExporter]

a yes if you know even the memory locations for "in pt" and "in alliance", 
that's 
even cleaner.

Ouch indeed i didnot thought about pets, but since jugs, puppets, wyverns and 
avatars have (MasterName) in game, maybe a memory location exists for that 
(MasterName). Then if that's implemented one day, would have to say in 
changelog "KParser doesnot supports bst charmed pets" as a trade off :/

For the rest, i don't think i can fully understand since i don't have my nose 
into 
the actual code, but i'm sure (like many others), you will find a solution ^^

Thank you for your answer and GL + /cheer up !

Original comment by raphael.morineau@gmail.com on 3 Nov 2009 at 9:40

[GoogleCodeExporter]

I've patched together something that seems to work.  It's been uploaded as 
1.4.5pre1.

It assumes that if an 'Other' type got the kill that we need to check to see if 
that
combatant performed -any- action during the fight.  Presumably for it to get 
the kill
it needs to have at least hit the mob or cast a spell or something.

If you have filters all the way down so that you can't see any actions taken, 
can't
really do anything about that, and it would be up to you to fix that on your 
end.

In any case, I'd appreciate it if you could test this out.  Try reparsing the 
parse
that gave you the problems in the first place.  You should still see two 
fights, but
one should have no combat data, and the other should show all your combat 
stats.  If
you can try it out in any other circumstances, that'd be nice as well.

Original comment by Kinemati...@gmail.com on 5 Nov 2009 at 6:14

[GoogleCodeExporter]

Indeed im using filters, usually only leaving PT dmg on foe unchecked. But 
still i 
dunno why i still see someone not in pt with me displays in log "defeats the 
Steelshell."
I guess if a filter allow to not see that, that would fix the problem by 
itself, but 
i dont see where is the appropriate filter.

Original comment by raphael.morineau@gmail.com on 5 Nov 2009 at 3:05

[GoogleCodeExporter]

I don't know of a filter setting that will turn off that message without 
turning off
pretty much all messages.  The filters I was talking about were if you set it 
to not
see any melee damage at all (such as if a rdm were parsing the party for curing 
data,
but had damage turned off so that they could see what they needed of what was 
going on).

Basically, you need to be able to see the actions of any pets in your own party 
in
order to be sure that their kills get counted properly using this new method. 
Doesn't have anything to do with the filter settings for kills outside your 
party.

Original comment by Kinemati...@gmail.com on 5 Nov 2009 at 6:54

[GoogleCodeExporter]

The update to fix this is in the 1.4.5 release.  Marking fixed.

Original comment by Kinemati...@gmail.com on 10 Nov 2009 at 5:47

• Changed state: Fixed