Incorrect Offense Details
Closed this issue · 9 comments
GoogleCodeExporter commented
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 commented
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 commented
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 commented
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 commented
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 commented
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 commented
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 commented
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 commented
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 commented
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