|
StonedMOFO Beginner
Joined: 22 Sep 2004 Posts: 28
|
Posted: Sat Aug 18, 2007 10:00 pm
multi-byte character (trigger support) |
Zugg, a good way to get rid of a lot of troubles with multi-byte language and special characters
is allowing user to turn on "Unicode compatibility mode" which essentially makes it so
your special character has to be doubles.
Example:
instead of @location_name you would need to use @@location_name
let me explain why this would solve a lot of issues.. cause problem with
multi-byte (as far as Chinese is concern, which i am sure is true for other language)
is sometime one of the byte contain zmud special character. This is like trying
to make a trigger out of " There is a book, the title reads [@%* art of Symbols]"
you would have to comment out all the special character by writing the trigger this way
^There is a book, the title reads ~[~@~%~* art of Symbols~]
but you see if special characters is also multi-byte, then the problem is solve!!!
cause there is almost zero percent chance of two symbol showing up in consecutive
order, it's just ... not possible as far as i know. (I did byte searches for @@ %% \ ~~ over about 30mb
of chinese text files and didn't find any.)
Anyway don't know if this makes much sense,
hope it did. |
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Sun Aug 19, 2007 4:25 am |
Sorry, but it's actually much more complicated than that. This would require making the entire parser support unicode, not to mention the trigger pattern matcher. That's a lot of work, and then people would just whine about all of the other parts of CMUD that don't support Unicode. As I've said before, the problem is that I choose Delphi to develop CMUD (and zMUD) and the Delphi visual components do not support unicode, and never will from what I've heard from the developers. I can whine about this, but I'm not about to port 1.5 million lines of Pascal code into another compiler. The amount of work that it would take to properly support unicode doesn't make it worth the small amount of income that I would make from those users (who, unfortunately, typically do not buy software).
At one point I thought it might be possible to do what you suggested, but then I uncovered all of the other problems that it would cause. Then, when the Delphi developers admitted that they would never support Unicode in their VCL, I pretty much gave up on this idea. |
|
|
|
StonedMOFO Beginner
Joined: 22 Sep 2004 Posts: 28
|
Posted: Sun Aug 19, 2007 6:31 am |
Hmm I do not understand what you mean trigger pattern matcher, it works fine at the moment
I just have to manually modify my multi-byte word so there is a ~ in front of every single special character
once I do that the pattern match without any error.. so ? it's already working the way it is .. dunno what you mean paraser support unicode. Nothing else in CMUD really need to support multibyte, you see... English is still the primary language, even when Chinese people write code they don't use chinese other than for pure display purposes (like display "hello"), variable and other junk is all in english. I certainly won't want an alias that would take me 6 second to type, sort of defeated the purpose of having alias.
I really want to get this working perfect, so msg me with further detail as to why this wont work?
Oh on another note, this is something I like to mention
Did you know I can run a robot made in different language on a mud that I can not even read *(cause my system unicode settings is wrong)* and the robot run just fine. Now the robot is running just fine despite the fact I can't read the text coming from the server, or the text that's in the trigger. In fact I can even use variable in chinese and call it with @<CHINESE> , as long as the <CHINESE> do not contain any uncommented (with ~) special characters. |
|
|
|
StonedMOFO Beginner
Joined: 22 Sep 2004 Posts: 28
|
Posted: Sun Aug 19, 2007 6:42 am |
grr basically i am saying there is no reason to "support unicode" since it's already supported, my zmud (or cmud) never had any issues displaying, inputing, or doing anything with unicode (in my case, multi-byte traditional chinese "BIG5" and simplified chinese which is also multi-byte).
I can do this because Windows has built-in font support for software even if the software doesn't, you can easily try this out
on your own computer (dunno how to set it for Vista but I am sure it's something similar).
jhero.twbbs.org 4567
just login, take a screen shot, save the image and log out (for future comparing purpose)
now goto Control Panel -> Regional Options
and goto Languages and select "Install files for East Asian languages" system will prompt for your Windows CD.
now goto "Advanced" tab and you'll see the first option is
Language for non-Unicode programs
This system setting enable non-Unicode programs to display menus and dialogs in their native language. It does not affect Unicode programs, but it does apply to all users of this computer.
in the Selection pick "Chinese (Taiwan)" now you will be prompted to reboot, do so
once you reboot you won't notice anything is different, cause remember, this doesn't affected Unicode program, so Windows itself is not affected. But now open zMud, and go back to the address
jhero.twbbs.org 4567
take another screenshot, now compare the screenshot, you'll notice the character clearly are "SHOWING"
as in well in my case I can understand them, but in your case they are just different. |
|
|
|
StonedMOFO Beginner
Joined: 22 Sep 2004 Posts: 28
|
Posted: Sun Aug 19, 2007 6:51 am |
check this out too http://www.microsoft.com/globaldev/tools/apploc.mspx
see zugg, multi-byte language was around before unicode even came around, i am not even talking about unicode support here, this is more of a 'multi-byte' support. |
|
|
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|