kolbot utf-8 changes

[imbalanced]

-Convert encoding of all files into utf-8, and use ÿ character instead of hex values
-Fix item desc substring method to lenth 4 in Misc.js and Mulelogger.js (Since ÿ is 2 bytes in UTF8)
-Add ethereal property to itemobj in Misc.js and Mulelogger.js
-Fix trim() method in Prototypes.js to not trim away part of multibyte string (such as 0xa0)

All these changes must go with corresponding changes in d2bs core and d2bot# as well.

[mf022]

-Convert encoding of all files into utf-8, and use ÿ character instead of hex values

Is the use of ÿ character showing colors on non ANSI encoding files for print or me.overhead messages?
For me these are showing only unreadable characters on other than ANSI.

anyway, #520 was merged 3 days ago, and I guess that were more happy people about that.

[imbalanced]

Is the use of ÿ character showing colors on non ANSI encoding files for print or me.overhead messages?
For me these are showing only unreadable characters on other than ANSI.

anyway, #520 was merged 3 days ago, and I guess that were more happy people about that.

Changes made here will work properly after d2bs core and d2bot# update. I already have created pull request for those. Problem with using hex values is that it's codepage specific solution and it may not stay the same under different system locales. For example, ÿ is two bytes in utf-8 (0xc3 0xbf) and whole bunch of different things under different ANSI locales... So forcing 0xff won't do any good if someone was to use non English based system locale. You just showed perfect example of why we should refrain from using ANSI encoding. In your case, it showed correctly on ANSI because your locale happened to match.

So what previous fix did was forcing Latin codepage (1252) on d2bs core but this didn't allow printing other languages or using other language d2 clients.

The point is to have scripts independent of codepage issues by using utf-8 all across and support all language that people want to use. You can print any strings and colors in any system locales without running into broken characters as long as all script encodings are in utf-8.

me.overhead function is little different and someone more knowledgeable should look into that and fix it in d2bs core. Currently I just added bandage fix to print ansi specific locale characters so it will print other languages fine (based on your locale) but colors won't fully work on non-English locale system as of now.

There are still problems such as not being able to use path or profiles names that contains unicode etc...This because d2bs core was never written with unicode in mind and didn't use wide win32 api functions where necessary. But this is fix for another day and currently only a issue if you have path containing "special" characters.

[noah-]

thanks @imbalanced, this will be part of a much larger release with d2bs/d2bot changes

[noah-]

This has been merged with the limedrop-utf branch

[jaenster]

Would it be also an idea to do the same @ NTItemParser.dbl ? =)