Zugg Software :: View topic - Another Solution to Multi-byte triggering without using ?or*

Beginner Joined: 22 Sep 2004 Posts: 28

CAUTION: This post contain Chinese words, if you do not have the codec pack install, it will not display correctly, but it is okay.. I have everyone on screen shot, even if the chinese word does not display in text, there is always screenshot, and the screenshot is detailed enough where you will understand what I am talking about!.

This method takes more time in my opinion, and since most of the time ?? will do the trick, I recommend everyone to just use ?? to replace the problematic words. But since I am helping Zugg out in figuring out a solution, I thought this post would help him more in understanding the problem.

I have some new finding, understand in the multi-byte problem, it seems the only problem ever, is zMud's triggering problem, as zMud without parasing turn on will work 100% with Chinese or any other Multi-byte mud (in essence, zMud without parasing is like a regular telnet).
The problem zMud have is not in receiving or displaying the data, however problem comes in the parasing process, which I would not go into detail to explain, as the post is to propose a walk-around solution.

I will go with my usual method of screenshot to explain this.

Snap1

This snap has the pattern -> 您的英文名子: <- as pattern, and execute the command -> myid;mypassword

Snap2

Following the method described in my other post, I proceed to the test tab to check on the pattern for problem. And here we are, we have problem! As you can see just by matching, the problem seems to be occuring with the 3rd word, as you see "您的" and "字:" appears to be fine, and the three letters "英文名" is not displaying correctly.

Snap3

This is the beginning of the problem solving process, I proceed to copy the entire pattern into the "Value:" section. The reason I do this is inside value input box, everything is treated in one-bye mode, as you can see my cursor is in middle of the word "英".

Snap4

I proceed to highlight the second half of "英" this would make the OS display the two seperate side of the word (don't ask me why Microsoft OS would do this, I have no clue, I just know this is the way to get the OS to show the gibberish that makes up the word). Here you can tell the problem lies with ^ (I say this by experience, because usually the stuff that cause problem is just zMUD "Special Characters" listed under the setting menu, but for some reason zmud also have problem with ^, I am sure Zugg would know why, cause this has to do with parasing).
Another method of figuring out which words is causing problem is remove them one at a time and go back to test tab to check, because once the problematic word(s) is removed, the sentence will show correctly in the test tab.

Snap5

Here I add a "~" before the problematic byte "^", in zMUD, anything that comes immediately after ~ will not be phrase, hence to type ~ you have to enter ~~ not ~, and same with any control character, # is ~#. (This may not be 100% correct, but again the main point here is we need to make sure zMud doesn't parase ^).

Snap6

Here I copy the end result from Snap5, and copy it back onto the "Pattern:", notice the word "英" changed into "迴^", that is because we've "TECHNICALLY" replaced second part of "英" from "^" into "~", so to Windows, this is displayed as a different word. But this is OKAY! This is what we want actually. We'll see why in the snapshot below.

Snap7

As you can see, even though our pattern is "您的迴^文名子:" but inside the test tab input, it is shown as "您的英文名子:" which is what we wanted!!!

Snap8

Now I proceed to test this, I enter "您的迴^文名子:" and strangely, it shown up as "您的英文名子:" inside the mud output window, and fired the trigger I set.

Snap9

This time I enter "您的英文名子:" , it also show up as "您的英文名子:" and also fired the trigger.

Snap10

I went on and did another test with another pattern: -> "才是這樣" (That's why it's like this). And this pattern will execute -> "say why?"

Snap11

In the test tab, it show up as "互0這樣" so we know there is problem with the first word "才" (It is always the first word inside a screw up phrase that is causing problem, as I say in other post, they are screw up cause the wrong bit is match up to create the word, which obviouslly would create a wrong word).

Snap12

I again, copy the pattern "才是這樣" into the Value: input. And went ahead highligh the second half of "才" and found out this time around, the problem is because the second half of the word "才" is "~".

Snap13

Here, I went in middle of "才" and added "~" before the problematic byte "~", so now I have "~~".

Snap14

I copy the finished (fixed) pattern from the values input back into "Pattern:" input. This time it show up as "才~是這樣" The word did not change like it did in the previous example, because we simply added a ~, the composition of "才" did not change.

Snap15

We look into the test tab, and indeed the problem is fixed, as "才是這樣" is shown inside the test input. And the test passed with "PATTERN MATCHES"

Snap16

I tested this inside the mud, and enter "才~是這樣", "才是這樣" show up inside the mud and fired the trigger just as intended.

Snap17

However, when I enter "才是這樣" the same error we have with test tab show up in here! This is actually because your command line is also parased by zMud, in fact if you lick on the parasing icon to the right of command input to turn parasing off, you will be able to enter "才是這樣" without it being screwed up. But there is an alternative to this, as you don't really want parasing off.

Snap18

Here I enter -> "才是這樣"
notice from the screenshot, I also put 才是這樣 inside " "
this solve the problem as zmud would not parase anything in-between quotation mark " ".
This is not much of an issues except if you are tring to make ALIAS using Chinese words. This is not usually done, because it is easier for us to enter "killallmob" then it is for us to type "殺所有的怪物" <-- (kill all mob in chinese).
So what I am saying is, if a mud send me -> 才是這樣 <- , it will display correctly without me having to do anything and my trigger with pattern: "才~是這樣" will fire as intended!.

Reply my post if anyone have any question!.

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

Would

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

Actually, I think I defeated myself, because you need parsing on to execute aliases, and if you have a bad character in the string where parsing is turned on it will become corrupted, eg if you do 'makepattern bl~ah' the '~' disappears.

I suppose someone could write a javascript web page to do it though.

Back to the drawing board.. :)

Beginner Joined: 22 Sep 2004 Posts: 28

ok this is just work around, this method alone, or my other method (using wildcard to replace the problematic word) will work fine.
I guess someone could try to fix this, but currently Zugg said is on his "look-into" list for the next zMud verison, and he already said he has some idea of how this may be fixed, so let's just stay put :)

SubAdmin Joined: 18 Nov 2001 Posts: 5182

You should be able to get around some of those problems by using the Verbatim option for simple triggers. This of course loses the complex facilities of capturing data, anchoring, etc.; basically everything described in the Pattern Matching help page. However for most triggers this isn't truly required and so the verbatim route may be helpful.

Beginner Joined: 22 Sep 2004 Posts: 28

Enchanter Joined: 10 Oct 2000 Posts: 698

Would it be possible to use the new spell checking to automatically fix this problem when entering on the command line Question

Just a thought. Confused

Beginner Joined: 22 Sep 2004 Posts: 28

Can't be done I don't think, cause the problem happen the second you press enter, and the command is sent into parasing engine,
not while it's being enter.

Enchanter Joined: 10 Oct 2000 Posts: 698

What I meant is that the spell checking module might be used to "break" the syntax automatically (inserting tildes (~)s as you type) so that when <enter> gets pressed, the now-messed-up-stuff is sent to the parser in such a way that tildes(~) have been inserted where they belong to make the commands/settings acceptable to the parser.

Anyway, it probably wouldn't work now that I think about it. The spell checking would have to be able to work on a language character basis to make it simple enough to do. Unless every word that would potentially cause a problem is entered into the spell checker, there would still be problems.

Beginner Joined: 22 Sep 2004 Posts: 28

well, no, it can work on byte basis, it doesn't matter which word is causing problem, the problem is not with the word as a whole (two byte), but part of the word.
So if any part of the word contain zMud special characters (~ @ # \ etc,.), it will cause problem. The spell check could fix problem with word disappearing during entry, but it would also have to be implemented inside the trigger module in order for it to work, and is essentially still a work around, kinda.

Beginner Joined: 30 Nov 2005 Posts: 12 Location: fwefas

Those picture links seems not valid anymore...I wonder if anyone have a copy of those and can help show them again?