Zugg Software :: View topic

Novice Joined: 07 Feb 2008 Posts: 40 Location: Italy

I can't make this trigger without wildcards:
2.97x) As you try to behead the Egyptian elite soldier, something distracts you and you only manage to slice his shoulder.
%dx) As you try to behead %w, something distracts you and you only manage to slice his shoulder. -doesn't work
%a As you try to behead %a, something distracts you and you only manage to slice his shoulder. -deson't work
(%a) As you try to behead (%a), something distracts you and you only manage to slice his shoulder. -doesn't work

* As you try to behead *, something distracts you and you only manage to slice his shoulder. -works

Posted: Thu Mar 20, 2008 8:06 pm

You'll find that leaving out the star at the beginning works fine, too. Since a match can begin anywhere on the line unless you tell it not to, it's superfluous. It's possible to create a more specific pattern that'll match that string (As you try to behead [%w ], something distracts you and you only manage to slice %w shoulder. for example) but you're right - any pattern to match that line will contain a wildcards. Even if they worked, your three other examples also contain wildcards, and so does mine. So you'll need to use a regex, which works slightly differently.

As you try to behead [\w ]+, something distracts you and you only manage to slice \w+ shoulder\.

Is a regex that matches this line. You can put regexes in a stringlist just fine:

#var something {As you try to behead [\w ]+, something distracts you and you only manage to slice \w+ shoulder\.|some other pattern}

But then in your trigger, you need to use () rather than {} to create the list:

#regex {(@something)} {behead}

If you need more info on regex syntax, try here.

Wizard Joined: 17 Jun 2006 Posts: 1201

Wizard Joined: 17 Jun 2006 Posts: 1201

I found a great way to demonstrate why you shouldn't use ".*" at the beginning of a line.

You can download The Regex Coach for free to test your regex patterns. Then do the step check and you will be amazed at how many steps it takes to match when you use a greedy star at the beginning of a line. Regex Buddy is better but you have to dish out some cash for it and this one is free.

You can download it at the link below.

http://www.weitz.de/files/regex-coach.exe

Also, using a negated character class is much faster and better than using a greedy or lazy star or plus.

Posted: Fri Mar 21, 2008 6:22 am

Thanks muchly for that link - I new there were free tools out there that did this sort of thing, but never took the time to find one. Excellent work. It'd be ten kinds of awesome if CMUD could include number of steps on the trigger tester tab, but I guess it doesn't need to when there's this, except to save me some copying and pasting.

And yeah, one of the first things I say when people moan about their triggers being slow is to make their patterns better. Most of the time when people use .+ they don't actually don't mean it anyway, and their laziness costs them in match speed. 20ms might not seem a lot, but when you're getting 10 lines a second in combat, that's a fifth of the second wasted before a single line of code is run.

Wizard Joined: 17 Jun 2006 Posts: 1201

I found one better...a free demo version of Regex Buddy.

http://www.freedownloadscenter.com/Best/free-regexbuddy.html

Now this program rocks. Just past in your patterns and the line you are trying to match and click debug. It shows you step by step instantly every single step and where it backtracks.

I know after reading the last few hours that ".*" and ".+" will be much slower than ".*?" and ".+?". Adding the question mark makes it lazy not greedy and lazy is faster.

However, I noticed above your pattern of "[\w ]+". This fails much faster than ".+?", but it is twice as slow when matching the correct pattern. I'm also wondering if we can use possessive quantifiers which would make things even more faster since it wouldn't backtrack. Explanation found here: http://www.regular-expressions.info/possessive.html.

Here is an example from the debugger in Regex Buddy.

To match the line "Look this is a test." from the pattern:

Posted: Fri Mar 21, 2008 12:06 pm

Basically, when choosing between match-success speed and match-failure speed, you should think about what's going to happen more often. Apart from stuff like prompt triggers, most triggers are going to be matching rarely compared to the number of times they'll be failing. The trouble with [\w ] in this case is that it's not much better than . for that line, since it contains mostly words. If you tried a totally irrelevant line like a prompt or a channel message, [\w ] will hopefully fail faster.

But I won't make any claims to being much more than passable with regexes, since that's all I've needed for most situations. If you have any more insights (I'd never looked into possessive quantifiers and I'm not sure if CMUD supports them - definitely something to check out, thanks) I'd love to read them.

EDIT: Been reading more about these possessive quantifiers, and they sound awesome. It always bugged me than when you use a construct like [^"]+ you usually follow it with the character in your range, and the engine should've understood that backtracking was pointless in that situation since of course " isn't going to match anything that was previously matched by [^"]. Funky stuff.

EDIT2: Seems like I was right and some regex engines already do that. Ace.

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

Based on some simple tests, it looks like possessive quantifiers, atomic groups, etc. ARE supported, at least by the new regex code that's in 2.20. Not surprising, since it's using the updated PCRE library that Vijilante worked up. That means that you can exert some serious control over matching efficiency by writing regexes carefully. I may switch to using regex triggers now, for this very reason.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

The current PCRE library actually supports nearly everything in the Perl 5.10 specifications. As well as some pattern syntaxes that are not part of Perl. Those additions are mostly where a regex feature appeared in another language first and Perl addopted the feature with a slightly different syntax. The things that are in Perl and not supported by the library are only non-matching extensions.

Wizard Joined: 17 Jun 2006 Posts: 1201

Damnit. Just delete this. My connection is in a bad way.

Wizard Joined: 26 Mar 2008 Posts: 1547

When accounting for error, I'd say the numbers aren't statistically significant between regex and trigger patterns, but there's an obvious significant difference between stars and no stars.

Posted: Mon Jul 21, 2008 12:53 pm

Wanderer Joined: 24 Jun 2008 Posts: 68 Location: Texas

Posted: Tue Jul 22, 2008 1:30 pm

Interesting thread. Seems like changing the test patten

Posted: Wed Jul 23, 2008 10:36 am

There are only two obvious possibilities.

1. Your patterns are wrong, or
2. Your mud is not normal, and is sending something strange (every line being sent like a prompt or something similar. Try playing around with the 'new line' and 'prompt' options in the trigs.

Also, when you can, post examples of the mud output with the xml of the trigger that won't fire.

Wizard Joined: 14 Aug 2004 Posts: 1269

Caled appears to be directing his message to Nicodareus. Yeah, we might need the debug output too, but I think it should go into a different thread since it is not related to speed.