Zugg Software :: View topic

Newbie Joined: 14 Sep 2001 Posts: 6 Location: USA

Here is my relatively simple trigger:

^It looks like it is {^in prime condition}.

Which triggers:

#COLOR red

It should match every line that starts with the words: "It looks like it is" excluding any lines that say "It looks like it is in prime condition."

The trigger doesn't seem to work on the mud, also when I try to test the text in the trigger tester with the text: "It looks like it is in a fine condition." it does not match.

Cardyin

Newbie Joined: 14 Sep 2001 Posts: 6 Location: USA

Note to Zugg: I figured out that the problem has to do with the way that the trigger is converted into PERL Regexp. If you convert the above it gives you something really awful and inaccurate. After doing some research I found that PERL has the negative lookahead construct (?!...) Using that, the trigger works like a charm. I've included the PERL equivalent below:

^It looks like it is (?!in prime condition)

Posted: Fri Feb 20, 2004 1:36 am

Thanks for posting this. zMUD is already using the (?!...) construct, but there appears to be some extra stuff getting added that shouldn't be.

Posted: Mon Feb 23, 2004 12:20 am

Actually, no, this isn't right either.

The (?!...) regex is for negative look-ahead. But in zMUD, the {^abc} syntax can be ANYWHERE in the string. So, you might have a trigger like this in zMUD:

{^Zugg} tells you

and if you just converted this to

(?!Zugg) tells you

then you'll find that this regex doesn't work. This is because (?!...) is looking AHEAD. In the case above we need to look BEHIND, so we use the PERL (?<!...) expression for Negative Look-behind.

So, now I'm really annoyed at regular expressions because it doesn't seem possible to totally mimic the zMUD {^abc} pattern. PERL can prevent it from being BEFORE a string or prevent it from being AFTER a string, but can't handle both.

I'm now experimenting with the syntax: (?!abc)(?<!abc) to see what specifying both does. Seems to work fine until you want to try and capture the value. For example, in zMUD, we could do this:

({^Zugg}) tells you

and if the MUD displayed:

Darker tells you

then the trigger would file and %1 would be "Darker". Well, neither the (?!...) nor the (?<!...) reg ex syntax captures any text. These are both "zero-width" expressions. So, it turns out the zMUD expression is not well defined. For example, if you have the zMUD trigger:

({^a}) test

and the MUD sends

big test

then should %1 contain the value "big" or just the value "g"? Either way looks equally valid from a regular expression point of view.

In most cases, people are trying to match a word. I can put stuff in the RegEx to force the {^abc} syntax to always match a word. But I've seen unusual triggers where people are not matching a word. In these cases, there is no () around the expression because they don't want to return anything. One example that I saw someone post was the zMUD trigger:

^~[{^Exit|GUILD|Page }*~]$

In this case, it should match the lines:

[ Bad PW: Alaura [126.0.0.1] ]
[ Ghasra force extracted (idle). ]

but not match things like:

[ Exits: e d ]
[ Page 1 of 2 - Options: (Q)uit, (R)e-read, (B)ack, or page number. ]

Notice the trigger contains "Exit" and not "Exits". So, this is not a full word. If I force this trigger to match a full word, then the

[ Exits: e d ]

line would match because "Exits" is NOT the same as "Exit".

So, what to do with this mess? It's a case where the old zMUD trigger parser was doing something odd and trying to make sense out of it. What I'm going to TRY and do for the next version is distinguish between the case where you want to capture the result, like ({^abc|def|ghi}) and the case where you are NOT trying to capture the result, like {^abc|def|ghi}

In the first case, with the (), I'm going to force the pattern to match word boundries. In the second case I will not force any word boundries.

So, if you do something like:

({^a}) test

and send

big test

then %1 will have the value of "big" as a whole word, rather than just "g" like PERL would return.

Anyway, this is really messy, so the chance of fixing this correctly the first time is pretty slim. If 7.02 doesn't work with these triggers, send me your example triggers so that I can tweak it some more.

Posted: Mon Feb 23, 2004 12:38 am

Further clarification here between the {^abc} and the ({^abc}) cases.

Consider the trigger:

#TRIGGER {{^a|b|c} says} {#BEEP}

This will NOT fire on

aaa says

because there is an "a" before "says"

But in the new version (7.02...out in a couple of days) if you use the trigger:

#TRIGGER {({^a|b|c}) says} {#BEEP}

then

aaa says

WILL FIRE the trigger because "aaa" is not "a" or "b" or "c" as words.

This should allow both kinds of triggers and produce results consistent with the old version of zMUD. The old version of zMUD did NOT WORK in the second case. The trigger still would NOT fire, even though some people thought it should. This causes a particular problem when using the {^@Friends} kind of syntax to match anything except the WORDS listed in the Friends list.

I've got this working now. If you click the Convert button to convert these simple zMUD patterns into Regular Expressions, you will NOT LIKE the results...they are REALLY UGLY. But they seem to work.

For now, it's a really good idea to stick with the zMUD trigger syntax for {^abc|def|ghi} because this concept is so hard to code properly as a regular expression.