Kparser not working with Windower's Timestamp v2.1 about kparser HOT 9 CLOSED

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.

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!

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.

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

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.

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.

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.

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

Updated version (1.2.2) should fix this problem.