Closed GoogleCodeExporter closed 8 years ago
I haven't been able to find a fail point for timestamp values, as the parser
works
fine for me if I try using Timestamp 2.1. Nevertheless, I've revised the line
parsing around the area of the timestamp value which will hopefully catch more
possible variations in value code order.
Would appreciate confirmation of if the next version fixes it for you.
Original comment by Kinemati...@gmail.com
on 1 Feb 2009 at 11:57
Hmm is there any sort of information I can assist to provide you with so you can
check on it better? I turned on Debug but it doesn't seem to help much. It
does
capture some chat on the Unparsed Data tab though.
Some of the captured info on unparsed tab:
[10:51:31 PM] 06,00,00,8050ff60,00000064,00000069,001b,00,01,01,00,・
22:51:31] <Aluris> zzz
[10:51:43 PM] 05,00,00,8020c0a0,00000065,0000006a,001b,00,01,01,00,・
22:51:43] (Aluris) zzz
[10:51:45 PM] 05,00,00,8020c0a0,00000067,0000006c,001f,00,01,01,00,・
22:51:45] (Aluris) testing
[10:51:45 PM] 7b,00,00,60a02c34,00000068,0000006d,002c,00,01,00,00,・
22:51:45] {There are no party members.1
[10:51:47 PM] 01,00,00,80585880,00000069,0000006e,0020,00,01,01,00,・
22:51:47] Aluris : wahahaha
Lemme know if you need more info. Thanks!
Original comment by Uris...@gmail.com
on 4 Feb 2009 at 2:53
Hmm. Odd.
The issue is that the opening bracket for the timestamp (the '[' in [22:51:31])
is
missing from those unparsed messages. The character just before them is
unicode hex
value 1EB7. That's not a known prefix value for the Timestamp plugin (known
values
are 1EFA, 1EFC, 1E3F).
There's the possibility that the character values got messed up in either the
display
output or in copying into google's comment page.
If you could, please do a parse with debug mode on for a few chat lines like
you did
above, stop the parse, and then find the file DebugOutput.txt. It should
either be
in KParser's directory or in the directory where you save your parses. Add
that as
an attachment to this bug page.
If the timestamp is for some reason using yet another different start
character, I'll
add it to the list. Also doing some more testing on my end.
Original comment by Kinemati...@gmail.com
on 5 Feb 2009 at 5:15
Hmmm.
What you mean 1EFA, 1EFC, it should mean HEX value right?
Doesn't seem to show 1EB7 by the way from what I see in the file.
I'm on Japanese language for non Unicode program if that counts for anything.
My
default input language is Japanese - Microsoft IME Standard 2002 v8.1
Original comment by Uris...@gmail.com
on 5 Feb 2009 at 4:32
Attachments:
Btw, just realized you have updated the parser. I have just d/led and tried
it.
Same issue.
Noticed that the debug log is slightly different now? Also, it seems that
gardening
can go through. I am sure that damage can't go through either but don't have
the
time to run out to hit some mobs. I will try to give you the debug log for
that over
the weekend.
Original comment by Uris...@gmail.com
on 5 Feb 2009 at 4:51
Attachments:
Ok, I've managed to replicate the issue (getting the 0x1EB7 code just before
the time
value and no open bracket). It happens if the re-encoding process (converting
the
string to Shift-JIS encoding so that Japanese characters show properly) happens
before the timestamp value is removed from the text line.
Of course the problem is that that should never happen. The check for the
timestamp
value happens before the encoding conversion.
Currently reworking the handling of the initial message extraction.
Original comment by Kinemati...@gmail.com
on 7 Feb 2009 at 9:28
Looking over the process flow, I'm almost certain it's related to your use of
Japanese as your primary input language. Both the Unparsed tab and the debug
output
file should show the original text line value, and that value is read-only
after its
initial storage. In other words, while it could supposedly be possible to
corrupt
the text due to a bug in the program flow, the text that would be corrupted is
'working' data, not the original. The original is what was pulled out of RAM.
Since the corruption matches the effect of an encoding conversion to Shift-JIS,
it's
probable that that encoding conversion happens by default in the marshalling
function
that converts the original raw data to a string, using the default system
culture.
If that's the case, then the core problem is a flaw in the implementation of the
insertion of text by the Timestamp plugin, but I can put in a workaround for it.
Original comment by Kinemati...@gmail.com
on 7 Feb 2009 at 11:34
Hmm. I need to be using Japanese for the IME plugin to work though.
It will be great if you can do so though! Thanks.
P.S. Attached a battle parse in case you need to make sure
Original comment by Uris...@gmail.com
on 14 Feb 2009 at 5:41
Attachments:
Updated version (1.2.2) should fix this problem.
Original comment by Kinemati...@gmail.com
on 16 Feb 2009 at 3:55
Original issue reported on code.google.com by
Uris...@gmail.com
on 1 Feb 2009 at 5:34