Zugg Software :: View topic - [2.29] Pattern Matching... I think it is a bug with {} within trigger patterns

Adept Joined: 27 May 2008 Posts: 299

This output...

[ Enemy: 33% 5073/5843hp 2537/4431mn (4610)mv 4090tnl (767353)G 39qt T:0] >

should match to this pattern...

~[{ Enemy: (%d)~% |}(%d)~/(%d)hp (%d)~/(%d)mn ~((%d)~)mv (%d)tnl ~((%d)~)G{ Dbl:(%d) | }(%d)qt T:(%d)~] *~>$

the reason for the {} is sometimes the output can look like

[5073/5843hp 2537/4431mn (4610)mv 4090tnl (767353)G 39qt T:0] >

or

[5073/5843hp 2537/4431mn (4610)mv 4090tnl (767353)G Dbl:09 39qt T:0] >

Important to note: This worked fine in 2.28.

Doing simple trigger tests with {} in patterns worked... Like #TRIGGER {{|Good} Test} fired with output of "Good Test" as well with just " Test"

Adept Joined: 27 May 2008 Posts: 299

Upon further review, the perl regex that cmud builds for the pattern looks like this

[(?: Enemy: (\d+)|)(\d+)\/(\d+)hp (\d+)\/(\d+)mn $(\d+)$mv (\d+)tnl $(\d+)$G(?: Dbl:(\d+) | )(\d+)qt T:(\d+)] .*\>$

If you notice its not including the ~% which should interperet to regex as \% or at least thats what Im thinking.

It looks as if it IS matching the 2nd and 3rd pattern, just patterns with Enemy: in it or with Dbl: in it

Posted: Thu Jun 26, 2008 12:44 am

% isn't actually a special character in regex, so it should just be in there verbatim.

Adept Joined: 27 May 2008 Posts: 299

ah, well either way, its not getting converted when the pattern is converted to regex

Adept Joined: 27 May 2008 Posts: 299

Looks like 2 bugs here. One is keeping the Dbl: part from matching and probably the Enemy: too if it appears...

another is with ~%...

Simple test shows this.. #TR {^{|(%w)~%} test$} creates a perl regex of ^(?:(\a+)) test$

And if you feed it output of "Good% test" It doesn't match.

EDIT: Further testing... It looks like all issues revolve around the ~% bug. If you take out the ~% and also the % in the output It matches in all cases.

EDIT AGAIN:

if I use

Posted: Thu Jun 26, 2008 4:00 am

After doing some testing myself, I've come across an interesting thing:

If you have:

#TRIGGER {~[{ Enemy: %d~% | Test |}~]}

it should match on the following:

[ Enemy: 13% ]
[ Test ]
[]

However, the ONLY thing it matches is the [], meaning it's not even paying attention to what's inside.

In fact, the perl regex right below it says this:

Perl regex: [(?: Test | Enemy: \d+|)]

which tells me that it's not converting the pattern correctly to Perl - it SHOULD be [(?: Enemy: \d+% | Test )?]

Now, change the trigger to:

#TRIGGER {~[{ Enemy: %d | Test |}]}

and it matches

[ Enemy: 13 ]
[ Test ]
[]

However... the perl regex is STILL wrong:

Perl regex: [(?: Test | Enemy: \d+|)]

It appears the whole conversion from zscript to Perl has been mucked up somehow. Hope this is an easy fix.

Charneus

Posted: Thu Jun 26, 2008 4:17 pm

I have no idea what happened to this. I didn't change anything in 2.29 that should have messed up the ~% conversion. But I'll add this to the bug list.

Sigh...this just never ends does it Sad

Adept Joined: 27 May 2008 Posts: 299

hehe I'm sorry that {}'s are giving you so many issues. In this case its pretty easy to work around if your proficient in cmud/regex, but for more novice users trying to convert bugged patterns to regex might cause some issues.

Posted: Thu Jun 26, 2008 10:12 pm

Btw, you have several other problems in your first trigger. Your text from the MUD has () around the mv value: (4610)mv, but your pattern doesn't escape the () with ~ properly. However, your pattern *does* escape the () for the "tnl" value, but your text from the MUD doesn't have () around that number.

Anyway, you might want to get the basic trigger pattern working without the optional {} subpatterns first, and then add the optional parts.

CMUD currently only converts a null value in a {} list to the proper (...)? regex when you are using a string list or database variable. When specifying the list inline directly I don't think it converts it properly. I'll try to add that to the next version.

And yes, it appears that the %~ is broken and I'll fix that too. But even fixing that won't fix your trigger with the other problems that it has.

Adept Joined: 27 May 2008 Posts: 299

Zugg, not meaning to be arguementative but my pattern is correct. It does qoute the () around the mv value and there are no () around the tnl. Im not sure which pattern you're looking at heh. The ONLY issue in the pattern was the ~% conversion from zscript to regex.

Posted: Thu Jun 26, 2008 11:05 pm

Blah, you are correct. I must be going blind.

OK, there were two bugs with the ~%. The first bug was when using it on the command line, like:

#TRIGGER {~[{ Enemy: %d~% | Test |}~]} {#show fired}

The ~% was getting converted to just % in the trigger pattern in the settings editor. This was bug #1 and is fixed for 2.30.

The next bug was with ~% in the pattern in the settings editor when used within {}. As Toxic mentioned, it was getting stripped from the regex. This is also fixed for v2.30.

The next bug was with converting lists that had null values. I think I must have been waiting for a final answer on converting {a|b|} to the regex (?:a|b)? with the ? at the end because when I looked at my code, I wasn't doing that anywhere, not even for string list or database variables as I incorrectly posted above. Since I don't see any problem with this regex conversion, I have added it to 2.30, so hopefully null values will be handled correctly now.

Finally, I also fixed some bugs in the Trigger Tester where it wasn't able to create a sample pattern correctly when wildcards like %d were within a {} list.

I have tested all of the examples given in this thread in v2.30, and they all work as expected now. I ran my other normal test script and it doesn't look like I've messed anything else up, but I had to make several changes that I was a bit nervous about changing.

This certainly was *not* working properly even before 2.29. CMUD has *never* converted a null in a string list to the proper (a|b)? regular expression, so it was always relying upon a null value in the regular expression, which sometimes works and sometimes doesn't. Also, the %~ on the command line was also stripping the ~ when viewed in the settings editor in older versions too. So, these weren't all just bugs in 2.29 but were all rather inter-related problems.

Crossing my fingers that this is finally fixed in v2.30. Not sure when I'm going to release 2.30 yet. I'm not very happy with the large number of "quick" releases that I've been making lately. While part of me wants to release a new version to fix these issues for people who consider them important, another part of me doesn't want to keep burdening all of the other CMUD users with yet another release so quickly.

Adept Joined: 27 May 2008 Posts: 299

you 'could' release 2.30 as a beta for us people who are having issues with these last few bugs... and not worry about a public version until you have more to include.

Just a thought. The thing is, with this bug, changing the pattern to regex fixes all of it. The problem with that is anyone who encounters this issue has to be smart enough to come to these forums and either search or post about it so someone can help them convert the pattern correctly, so in that sense it may not be worth a release at all. Like I posted I just switched the pattern to regex and so this bug is not even an issue for me anymore.

Posted: Thu Jun 26, 2008 11:21 pm

I think, personally, people would favor a large number of quick releases than having to deal with workarounds or just not having their scripts work at all. Case in point, this post - it's obvious Toxic is wanting to use the wildcards within some of his triggers (based on his last few posts), but can't until this is fixed.

Same with me - there are things that aren't working correctly that I feel I need to have fixed before I can continue to add on to my script or distribute them. Without fixes, our scripts are full of bugs themselves, and we're at a standstill until the next version comes out.

I do understand your point, though - and ideally, you'd have everything fixed in the next (and final!) version. But that's never going to happen. Even the most perfect software is going to foul up somewhere, and without new releases, we'll probably never detect them. I know every time a new version of CMUD is released, I find new ways to break it. Why? Because the script I was working on that found a bug in the previous version now works, and I can move on to another script.

But that's just my two cents. :P

Charneus

Posted: Thu Jun 26, 2008 11:26 pm

True, it *is* rather obscure.

But the reason I wanted to go ahead with another public version rather than waiting is because I expect there to be a big gap before the next beta version (with the beginnings of the new mapper) is released. And once I get into working on the mapper, I'm going to be less willing to fix these other kinds of bugs. It's hard for my brain to multi-task and keep everything in my brain that I need. I tend to get immersed in a particular part of the code and concentrate my effort there. So this is the right time to be fixing the trigger pattern stuff, since it's already all in my brain.

Once I get my brain full of the mapper code, then I'm going to want to concentrate on that and not deal with regex, parser, mxp/ansi, and stuff like I have been fixing recently.

But it's definitely a fine balance to determine when the current public version is "good enough" and when I need to do another quick fix. I'll probably go ahead with a 2.30 version just because, as you said, if there is a new problem with trigger patterns, using a regular expression can always get around it.