Zugg Software :: View topic - Testing wildcards within {} trigger patterns

Posted: Wed Apr 30, 2008 4:51 pm

I was looking at the CMUD source to try and see why wildcards no longer work within {} patterns (they worked in zMUD). And I found that back when I first wrote CMUD, I added a preference option called "Wildcards" to enable/disable this feature. This preference is off by default, and it seems that I never added it to the UI.

So, if you have a chance, please test to see if this works. Enable the Wildcards preference using the command:

#CALL %pref("Wildcards",1)

and then see if you are able to use wildcards within {} patterns. Let me know if this works and I'll add the UI option for this in v2.23. Also, if you can think of a reason why this shouldn't be ON by default, let me know.

Apprentice Joined: 26 Apr 2007 Posts: 113

Tested and works.

Posted: Wed Apr 30, 2008 6:04 pm

Yes that test is good and I can also confirm it works in fact I created a trigger loop with my test. Twisted Evil

As for being on by default the only reason I could think of is if it potentially slows CMUD down which I doubt it would anyway.

Posted: Wed Apr 30, 2008 7:19 pm

It would slightly slow down the initial conversion from zScript trigger pattern into a regular expression pattern. When "Wildcards" is enabled, then the pattern within the {} is recursively passed to the regex conversion routine, otherwise it just quotes any wildcard characters. Since this is just done once when the trigger is first used, I doubt the speed difference will be noticeable at all.

Wizard Joined: 14 Oct 2000 Posts: 1368

The bad thing with making it the default now could be if people are matching {} characters. Wouldn't those scripts then need to be changed to ~{~}?

Posted: Wed Apr 30, 2008 8:32 pm

No - they were always a special character and always needed escaping.

Posted: Wed Apr 30, 2008 9:45 pm

Fang is correct. This change only effects wildcard characters within the {}, such as *. I can see where this might cause a side-effect if someone was using {@varname} and @varname was a string list that happened to have wildcard characters in it, like "item *1*|item *2*|..." etc.

But since this is how it worked in zMUD, it seems like CMUD should handle it the same way. I don't remember any specific reason why I turned it off and couldn't find any form post about it with some simple searching. But since I've seen several questions recently about this, I think it might be better to turn it back on by default.

Adept Joined: 27 May 2008 Posts: 299

Was this ever enabled as default in CMUD 2.25? Im assuming not since its not working for me, but wanted to check. And this would work for any of the predefined wildcards yes? ie %w %d etc.

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

By default usually means that if you create a new session then it will already be checked.
But your pre-existing sessions will remain as they were.

Adept Joined: 27 May 2008 Posts: 299

My packages were created fresh in 2.25, not carried foward from a previous version... So are they default?

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

Then I would have to say probably so. I just check and both the untitled session and the session I just created had it set.

To check your sessions click prefs -> scripting -> Allow wildcards within {} trigger patterns.

If it is not checked check it. If it IS checked show me the patterns that are not working. And the text they are supposed to match.

Adept Joined: 27 May 2008 Posts: 299

Trigger pattern is ^({@{dbvar}})$

dbvar = {"This is a (%w) test string."="test value"|key2 = val2}

output is

This is a good test string.

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

I needed to set the variable to be a database variable and put the keys in manually but yeah, it worked after that.

Adept Joined: 27 May 2008 Posts: 299

What was your output? Just curious as to what {%1} reports back as.

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

This is a good test string.
This fired the trigger. {This is a good test string.}

Adept Joined: 27 May 2008 Posts: 299

How, if possible, could I pull out the Good in the above script?

so I could assign good to a var inside the trigger?

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

I don't know and I don't have time to test so, odds are Vijilante or Zugg will have to answer that one sorry.

Adept Joined: 27 May 2008 Posts: 299

Can anyone help me further with this?

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

Adept Joined: 27 May 2008 Posts: 299

could I do?

#CALL %match({%1},"*(@stringlist)*", and then somehow store %i into @vartoputgoodin)

%i being the string in the list that matched?

Adept Joined: 27 May 2008 Posts: 299

Just a thought but maybe...

#FORALL @stringlist {#CALL %match({%1}, "*(%i)*", @vartoputwordin)}

Adept Joined: 27 May 2008 Posts: 299

Still looking for a solution to this. Just a recap on what I'm looking for.

I currently have

Wizard Joined: 22 Mar 2007 Posts: 2320

You have an extra set of parentheses in your trigger pattern. Change it to:

Adept Joined: 27 May 2008 Posts: 299

Thanks, I knew it had to be something small, but yes, that makes sense.

Wizard Joined: 22 Mar 2007 Posts: 2320

Maybe you could explain in a little more detail exactly what you are trying to do. From what you have so far, I have a feeling you may have some problems.