Zugg Software :: View topic

Apprentice Joined: 17 May 2005 Posts: 108

So I have this one, small, but very annoying problem trying to match a pattern.

I have a trigger, the pattern of which is a variable. I set that variable with an alias, and it causes things to happen when I see a string that matches that variable's value when I scan (yeah, this is the same script I've been talking about in other threads).

The problem arises in one special circumstance. I have a command, "robscan," which looks for mobs that might have something I can steal from them. They are denoted on scan's output with "(Suspicious)".

I assumed that making my variable equal to "(suspicious)" would be fully specific enough to avoid problems with other "suspicious" mobs, but as it turned out that isn't the case. There is one mob that shows up on scan's output as "- a suspicious trader", and no matter how I quote or escape those parentheses, they just don't seem to matter when the time comes to match the pattern. "~(suspicious~)" doesn't work, for instance.

I could make the trigger case sensitive, but then I'd have to make sure that I get the case right on any target I might decide to scan for, which takes away the effortless utility of being able to scan for things when I might not know exactly how they're named. I could also make that trigger "~-%s@ScanSettings.String" instead of just "@ScanSettings.String", but that would cause the same problem. Now, instead of being able to match any part of a mob's name, I'd have to match at least the first part. So, for example, instead of using "mark crocodile" (to set my scan target to crocodile) I might have to do something like "mark "a large and hungry crocodile". Maybe I want to be non-specific and target any lizard I see, where there might be yellow lizards and red lizards and green lizards--that would be impossible, in this case.

I could also make the trigger something like "~-%s(*)", and do a #if (%1=~@ScanSettings.String) in the trigger body, with another check for that one specific mob to make sure it doesn't match, but honestly I'd just rather match the pattern right in the first place, and keep the script at its current level of non-specificity, which I find to be ideal in all other circumstances.

Failing finding a way to make the pattern match, I'll just continue using #substitute and changing the name of the mobile as it appears on scan. I'm just sort of hoping that somebody knows a trick I don't for this.

tl;dr: I have bouts of OCD and need things just so.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I would generally recommend avoiding using the pattern matching =~ operator. When you are working with a trigger you should be able to make the pattern specific enough that you know exactly what is matched. It makes a little more sense when it is an alias working with user input, but that tends towards being a parsing issue and you are better served using %match or %regex so that you can record parts into local variables.

Post a two sizable sets of scan output inside code tags. Try to make sure your samples cover a wide enough range of possible lines that we can be sure to get it right. After each set of scan outputs post a duplicate of some of the lines either those you want matched or those you don't want matched (whichever is less copying). For example:

Apprentice Joined: 17 May 2005 Posts: 108

Well, scanning from one location that I'm having an issue with looks like:

Posted: Fri Feb 12, 2016 9:53 pm

seems the dash beforore a suspicious character always has two spaces, where normals only have one, there is your big thing

#TR {- ~(suspicious~)(*)} {$mark=%1}

You will have to add to that to strip out the surplus characters you don't need and get to just the keyword for targeting purposes.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Your description in the first post is saying one thing and then what your stated with the output sampled from the mud sounds like something else entirely.
Your current trigger would be useful. I will probably also need to know specific values for some variables. Putting more information than is needed is usually better than not enough.

Apprentice Joined: 17 May 2005 Posts: 108

I really didn't intend to put anybody to any great effort here, just thought maybe there was a simple solution I was overlooking... I haven't tried setting my variable to $suspicious$ yet... maybe REGEX escapes would work? I went ahead and learned REGEX the other day, but I'm still not always sure where and how I can apply it within CMUD.

In any event, you can feel free to ignore this wall of text if you're not particularly interested, otherwise, read on :) Warning, I erred WAAAAY on the side of "to much information."

I wish it were as easy as setting the variable to "- ~(suspicious~)". When using a variable as a pattern to match, things like escape characters and parentheses don't seem to work as you'd expect. There seem to be too many layers of checks to get a pattern to match without the escapes and so forth parsing out. Trying to double the escape characters doesn't work (causes errors).

I'll try to run through the steps involved.

First step: I use an alias, "walk" to set my scan target to %params (or "mark" to set both scan target and combat target). This can be any string I hope to see on scan, if I want to find special characters, I can generally just double-escape them. I.e., to match "/^\" I might type: walk "~~/~~^~~\".

Then I scan, and get the output I've shown in the previous post. Assuming I use the alias "scan" (and not "sca"), at "Right here you see:" I clear out @Target_List, and set @Target_Position to "{Steps=0|Direction=L|Stack=0}". I also #T+ a couple of other triggers, the process doesn't start without the alias scan, and has checks along the way to quit processing things if I find no targets/etc. At lines like "(%n) (%w) from here you see: " I change Target_Position.Steps to %1 and Target_Position.Direction to "%left(%2,1)", while resetting Target_Position.Stack to 1 (not zero, because my walking in will change its position in the stack).

Whenever I see "%s~-%s" I increment @Target_List.Stack by 1. if I see a mob that matches my scan target string, I record its position in "@Target_List," Where the key is equal to the number of steps away, and the value is a string list where the odd items are direction and the even items are position in the room's stack. If there is more than one matching target in a given room, I only record the first--I can't think of a reason to do otherwise unless I just wanted to count mobs... and I'd use a less complex script for that.

Anyway, this gives me a Target_List variable with a value like:

SubAdmin Joined: 18 Nov 2001 Posts: 5182

You definitely erred on the side of too much information. You supplied mostly information that is already known from your other posts and not really the information needed to figure it out.

As near as I can tell the following are the details I need confirmed.
When you use the "robscan" alias it sets ScanSettings.String="(suspicious)".
The trigger using a pattern of "@ScanSettings.String", which you posted, is what detect mobs during the scan and records their positions to TargetList.

Given those I would also ask what else is stored in ScanSettings? How hard would it be to split the pattern string off to its own variable so you don't have the extra layer of record lookup activity? Record variables use parenthesis for nesting; if you are not using #ADDKEY then your parenthesis are likely being confused during the lookup.

Posted: Mon Feb 15, 2016 6:15 am

try changing the pattern to {@ScanSettings.String}, sometimes it needs the extra curly brackets to properly expand the value.
if that doesn't work, trying using: ScanSettings.String="~(suspicious~)"
or both

Apprentice Joined: 17 May 2005 Posts: 108

That's it!

Changing the pattern to {@ScanSettings.String} made it parse properly, and required no other changes to the package.

That has the added side effect of not requiring escape characters when using special characters in my target.

I had a feeling there would be something simple, thanks guys. Sometimes the finer points of syntax aren't exactly obvious to me, like when I can use $Variable vs ${Variable}.