Regular Expression Double Match on Multi-Line Trigger

Posted by Xavious on Fri 18 Apr 2014 07:18 PM — 11 posts, 38,287 views.

Xavious Fri 18 Apr 2014 07:18 PM #0

I have been having a lot of problems creating a multi-line regular expression trigger. The issue surrounds the complicated situation of lines that may or may not be present in the overall expression.


'king crown unique armor' is type armor, extra: rare
This item needs 150000 gold coins before it can be refined.
Armor class is 205. [+197% Enhanced Defense]
This item is covered with razor sharp spikes.
Affects strength by 5.
Affects intelligence by 5.
Affects wisdom by 5.
Affects dexterity by 25.
Affects constitution by 15.
Affects agility by 5.
This item has 525 points of magical resistance.

The line: "This item is covered with razor sharp spikes" may or may not be present on any given item. Example:


'king crown unique armor' is type armor, extra: rare
This item needs 150000 gold coins before it can be refined.
Armor class is 205. [+197% Enhanced Defense]
Affects strength by 5.
Affects intelligence by 5.
Affects wisdom by 5.
Affects dexterity by 25.
Affects constitution by 15.
Affects agility by 5.
This item has 525 points of magical resistance.

My expression is as follows (I inserted newlines for ease of viewing):


Your eyes glow bright yellow for a moment.\n
'(?:king|grandmaster) (?:[a-z]+) ([a-z]+) [a-z ]+' is type (?:[a-z -]+)?( weapon|armor|light), extra: rare\n
This item needs [0-9]+ gold coins before it can be refined.\n
Armor class is [0-9]+. [[0-9+%]+ Enhanced Defense]\n
(?:This (item|weapon) ([a-z ]+).\n)?
Affects strength by [0-9]+.\n
Affects intelligence by [0-9]+.\n
Affects wisdom by [0-9]+.\n
Affects dexterity by [0-9]+.\n
Affects constitution by [0-9]+.\n
Affects agility by [0-9]+.\n
(?:This item has ([0-9]+) points of magical resistance.|\s+)

*Note* The final line was causing me the same problem of double firing, but I found a work around by using "|\s+" because immediately after that line is a blank line. The trigger fires perfectly when the line for the spikes is present. However, if that line is not present it causes the trigger to match two times and I really have no idea why. I also tried "(?:This (item|weapon) ([a-z ]+).\n|\n)?" But it would match twice as well. If that line would only match one of the OR clauses it would be fine, but it matches for both. This project has propelled my regex knowledge quite a ways, however it seems I still have a lot to learn. Any help you guys can offer is greatly appreciated! :D

Nick Gammon Australia Forum Administrator Sat 19 Apr 2014 12:47 AM #1

Personally I wouldn't try to do something that complex with one trigger, but rather with 3 triggers as described here:

Please read the MUSHclient FAQ - point 37.

Next unless we aren't seeing all of your backslashes in the forum post, this is not right:


Armor class is [0-9]+. [[0-9+%]+ Enhanced Defense]\n

Those square brackets that you actually want to match should be escaped, eg.


Armor class is [0-9]+. \[[0-9+%]+ Enhanced Defense\]\n

Xavious Sat 19 Apr 2014 03:23 AM #2

For whatever reason the forum did, in fact, exclude my forward slash for the enhanced defense part. I actually do have that included in my expression already and the trigger fires perfectly every time, except when the line concerning the spikes is missing.

I'm trying to master regular expressions, so this particular scripting project has become a bit of an obsession for me. If I have to use multiple triggers to accomplish the task I will, but I'm still hoping I can find a way to do it with the multi-line capture. I've stepped through the logic on this trigger several times now and I just can't figure out why it fires twice when that line is missing.


(?:This (item|weapon) ([a-z ]+).\n)?
                                   ^ I thought this was supposed to make this whole group optional. The trigger fires perfectly when this line is here and it fires two times when it isn't.

In any case I appreciate the FAQ reference, Nick. Good to see your still at it man! I think that FAQ already helped me think up a simpler way to accomplish this with multiple triggers, but I'm still interested if I can pull of the complex multi-line trigger as a personal challenge.
You helped me with a regular expression years ago and I still never really understood it until recently. I've reached a part in a programming course that is covering regex, so I was inspired to use it to build a few scripts. I have a way better understanding of them now than I ever did before, but I'm still a newbie :D.

Nick Gammon Australia Forum Administrator Sat 19 Apr 2014 04:13 AM #3

It would help to see your exact trigger (eg. number of lines in the multi-line trigger). Plus, you can "escape" the backslashes, as described here:

For advice on how to copy aliases, timers or triggers from within MUSHclient, and paste them into a forum message, please see Copying XML.

One thing you can do to stop multiple matches it to have the very last thing in the trigger by "end of subject" ( \z ) or "end of subject or newline at end" ( \Z ). That will tend to stop multiple matches.

Otherwise with a lot of lines in the multi-line match it can match twice like this:


aaaaaaaaaaaaa
bbbbbbbbbbbbb
ccccccccccccc  <--- first match


aaaaaaaaaaaaa
bbbbbbbbbbbbb
ccccccccccccc  <--- second match
ddddddddddddd

However with "end of subject" as the last thing it only matches once:


aaaaaaaaaaaaa
bbbbbbbbbbbbb
ccccccccccccc  
ddddddddddddd <--- this is end of subject

Nick Gammon Australia Forum Administrator Sat 19 Apr 2014 04:16 AM #4

Quote:

I thought this was supposed to make this whole group optional.

It does. However the multi-firing is likely to be because of the lack of end of subject in the match.

Nick Gammon Australia Forum Administrator Sat 19 Apr 2014 04:21 AM #5

To explain a bit more, if you have a 10-line multi-line trigger, then MUSHclient gathers up the most recent 10 lines (every time a new line arrives) and submits them to the regexp matcher. Thus it is quite possible for a multiple match to occur.

These 10 lines are the "subject" (of the match). eg.


aaa
bbb
ccc
ddd
eee
fff
ggg
hhh
iii
jjj

Each line has a newline at the end, however the last line (the "jjj" one) is the only one which is the end of subject.

So if you have a definite thing which is always at the end, eg.


This item has xxx points of magical resistance.

Then this is a good thing to have "end of subject" match at the end. That way it only matches if it is at the "jjj" position and not if it ripples up due to extra lines arriving.

Xavious Sun 20 Apr 2014 01:30 AM #6

Thanks for the in depth explanation Nick. I tried using the end of subject match, but it didn't seem to help with the problem. It could possibly be due to the fact that the last line of the trigger is optional as well.

I have found a workaround for my problem by being more picky about what EQ I loot using an in game mechanic called a junk filter. Previously I wanted to be able to filter between the top two tier items, Grandmaster and King. However, I decided to just limit it to the very top tier. By doing this I guarantee all lines will be present, thus ensuring it fires properly each time. King level EQ is never missing magic resistance or spikes. This is, however, a slight loss because occasionally a Grandmaster piece can be perfect. This scenario is pretty rare, though, so it's not that huge of a loss. In fact I have only heard it can be perfect, I have yet to witness it personally. That was my motivation for keeping it open.

Anyway my original script, for reference, was this:


<triggers>
  <trigger
   enabled="y"
   lines_to_match="12"
   match="Your eyes glow bright yellow for a moment.\n'(?:king|grandmaster) (?:[a-z]+) ([a-z]+) [a-z ]+' is type (armor|light), extra: rare\nThis item needs [0-9]+ gold coins before it can be refined.\n(?:Armor class is [0-9]+. [[0-9+%]+ Enhanced Defense]\n)?(?:This item ([a-z ]+).\n)?(?:Affects hit'n'dam by [0-9]+.\n)?Affects strength by [0-9]+.\nAffects intelligence by [0-9]+.\nAffects wisdom by [0-9]+.\nAffects dexterity by [0-9]+.\nAffects constitution by [0-9]+.\nAffects agility by [0-9]+.\n(?:This item has ([0-9]+) points of magical resistance.|\s)"
   multi_line="y"
   regexp="y"
   send_to="12"
   sequence="100"
  >
  <send>world.note "%1"
world.note "%2"
world.note "%3"
world.note "%4"
if "%3" = "is covered with gruesome spikes" and "%4" = "1050" then
   world.send "put '%1' perfect"
   count = count + 1
   world.note count &amp; " perfect items found."
else
   world.send "drop '%1'"
   world.send "sac '%1'"
end if
</send>
  </trigger>
</triggers>

I have my code in VBscript because it's just what I got comfortable with using for my MUSHclient scripts. The basic logic is probably obvious. When I loot a piece of EQ it fires a different trigger that has me cast "ID" on the loot. The resulting output is what fires this script shown above. It tests to see if a piece of EQ has the best possible spikes and highest possible magic resistance. If it does have both of these attributes it puts the EQ in a container labelled perfect and if the EQ fails to meet this criteria it gets junked. Incidentally, lower class armor may lack magic resistance or spikes entirely, which is why I had those lines set up as optional.

Nick Gammon Australia Forum Administrator Sun 20 Apr 2014 02:32 AM #7

I added \Z to the very end of the regexp.

Without it, it would fire twice, with it, it fired once (on your example above).

Nick Gammon Australia Forum Administrator Sun 20 Apr 2014 02:37 AM #8

I think my explanation above was correct. The match that failed for you was 11 lines long, but you were matching on 12 lines. Thus, without the \Z at the end it matched once, and then again when it scrolled up one line.

If you make it match on 15 lines (for example) it matches 5 times (because the 11 lines which cause the match fit into the "subject" 5 times before the first line goes outside the subject range).

Adding in the line "This item is covered with razor sharp spikes" fixed it for you (in a sense) because you now had 12 lines in the subject, and you were matching on 12 lines. Thus it only matched once.

Xavious Sun 20 Apr 2014 03:42 AM #9

Wow.. I just tried it again and it worked this time. I think before I thought I had to put /Z inside the last capture group and not on the outside. I think that just fixed it. Thanks a lot Nick!

Nick Gammon Australia Forum Administrator Sun 20 Apr 2014 04:17 AM #10

Glad it works. This is a more general solution, which hopefully helps others (compared to fiddling around with junk filters).

Quote:

I think before I thought I had to put /Z inside the last capture group

It is \Z not /Z