Gammon Forum : MUSHclient : General : Triggers across lines

Entire forum ➜ MUSHclient ➜ General ➜ Triggers across lines

Triggers across lines

It is now over 60 days since the last post. This thread is closed. Refresh page

Pages: 1 2 3 4

Posted by

Shadowfyr USA (1,791 posts) Bio

Date

Reply #15 on Fri 23 Apr 2004 01:08 AM (UTC)

Message

Umm.. Frankly I would have never considered actually specifying the number of lines to expect. It frankly makes no sense to do so. Exa:

^You are carrying:$((?s)(.*))$You are carrying (.*) items\.$

wouldn't work. Which part are you going to match multiple times, the first, middle, last or every item? Take for instance:

You see .....
and a large toad.

and

and a large toad.
You see .....

It appears under your logic, both of these would create a match, but the point of multiline triggers is to match known information that spans multiple lines in a *specific* order. There are imho far better ways to match lists and it makes no sense at all to use a multiline trigger with a predefined number of lines to match an inventory that could contain more or less lines that you ask it to. And if it does work in the right order, then there are still cases where it doesn't make sense. It is also certain to be slower than necessary, the behaviour is frankly going to confuse people that use such things in other programs and if I am right can even be completely wrong in cases like my example above.

Ok, maybe for a list with a known length where you have a single line that starts it and you *know* that it will only have x lines, this is an interesting idea, but the other 99.9% of the time it makes no sense. However, even for such lists, this would make more sense:

T1> "^You are carrying:$" - enable T2 and T3.
T2> "^((?s)(.*))$" - calls script, etc.
T3> "^((?s)(.*))$^$" - disables T2 and T3.

You get the exact same result, it still works as intended and it doesn't need to know how many lines to look for. This to me makes sense and is how 'everyone' that uses other clients that support multiline matching would expect to handle it.

So, if you really have a good reason for your method... But I frankly just don't see it.

Top

Posted by Nick Gammon Australia (23,158 posts) Bio Forum Administrator

Date

Reply #16 on Fri 23 Apr 2004 01:11 AM (UTC)

Amended on Fri 23 Apr 2004 01:19 AM (UTC) by Nick Gammon

Message

Huh? Matching in any order? That wasn't my intention. My earlier example, which works, was this:

match: ^You are carrying:$((?s)(.*))^$

Analysing that, you are matching:

You are carrying:
(x lines containing your inventory)
(a blank line (^$) )

Where "x" is limited to the number of lines you specify as the trigger match limit (eg. 10). As triggers are still matching in sequence, it will only match lines that occur in that order, not some other random collection of lines which might happen to have "You are carrying:" somewhere in them.

I think I see what you are getting at with the wildcards, but it is no different than before. It will try to match where it can. I have done an example with a who list. Here is the list:



-----------------------------------[ IMMORTALS ]------------------------------

Supreme Entity  Nick the Recruit.
Supreme Entity  Shadowfyr the Supreme Entity.
2 players.

This has two wildcards in it - the list of names, and the number of players (2 in this case). Now to make it simpler the "2" could be represented as \d* however to demonstrate the point I'll use normal wildcards. Here is the trigger:


<triggers>
  <trigger
   enabled="y"
   lines_to_match="10"
   match="^\-*\[ IMMORTALS \]\-*$(?s)(.*)^(.*) players?\.\z"
   multi_line="y"
   regexp="y"
   send_to="2"
   sequence="100"
  >
  <send>Match = 
"%0"</send>
  </trigger>
</triggers>

And this is what I see:


Match = 
"-----------------------------------[ IMMORTALS ]------------------------------

Supreme Entity  Nick the Recruit.
Supreme Entity  Shadowfyr the Supreme Entity.
2 players."

Thus the matching text is the whole thing. Let's look at wildcard 1:


Match = 
"

Supreme Entity  Nick the Recruit.
Supreme Entity  Helen the Supreme Entity.
"

That is indeed the multiple lines between the opening (identifying) line and the closing line. This seems fine to me.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Top

Posted by

Shadowfyr USA (1,791 posts) Bio

Date

Reply #17 on Fri 23 Apr 2004 01:52 AM (UTC)

Message

Ok.. I see what you mean. I still think it is inconsistent with what people will expect them to do. You are adding a feature that accounts for a situation that people don't use these kinds of triggers for in the first place. Most of the time if I am trying to match multiple lines it isn't going to be a list. It will be more specific information like a room description, that may in fact appear in a dozen different rooms, but with 'one' room having an extra line that I am looking for. Or something like the example that started this thread, which involves two lines that are technically part of the same line, but just happen be be broken up by the mud before the client gets them. Your adding functionality, extra settings people are not likely to expect and additional overhead to something that most people would never even consider using the way you suggest imho.

I wish a few other people that have talked about this feature before would post comments about it, because I expect that while some would consider your design to be useful, most would have never suggested such a radical shift from the way such triggers work in existing clients. They certainly wouldn't expect it in your implimentation. I don't think that specifically telling the client to look for x lines is necessary or so useful that it is a must have feature, nor do I think requiring that people add extra settings to make multiline matching work is an improvement over my idea, which simply extends the behaviour to do what a number of people expected it to do in the first place.

Again, *lists* are not the reason people are looking for this, they just want the client to behave the way the existing specification for regular expressions and multiple lines as well as they way they work in existing clients that support such. Who, inventory, etc. are literally at the bottom of my list of things I would use such a trigger for and I can think of 0 posts on this forum that even suggest that they are a problem that needs to be fixed. In most cases where I would want/need to match multiple lines, I know what the end looks like and what starts it, but I haven't a clue how many lines I need to have to look through to complete the match. If I ask it to look too far back, then it could even read the wrong line as the start. For example, lets say I am capturing gossip traffic:

[gossip] fred: Yeah. That was fun.
[gossip] Jim: Well, not really. After all...
...
...
[sales] grung: WTS fred.
Youn enter a forested area ...
...
...

Exits: ...
[gossip] fred: True.

Ok... How the heck do I capture multiple lines in this case if I have to tell it which lines to look for? You can't, because it can be anything from 1 line to whatever the buffer limit of the mud is, which is about 12-13 lines on Ages of Despair. If I set it at 13 lines, your method would look back 13 lines and capture the first "[gossip] fred: Yeah..." line, even though it *should* be capturing the line "[gossip] fred: True.". Also, in the above example, there isn't going to be any 'end line', but there may be a change in color that is just as critical to notice as the stop point. I expect you have it stop if it ever fails to match, but if someone dumps some ansi graphics in there right after one of those lines, is it by pure coincidence going to match anyway?

Basically -

1. I can see cases where it can completely fail or doesn't work.

2. It breaks both the expected behaviour of regexp, which only matches what you tell it, not 'everything between these lines'.

3. It requires an extra setting people are not going to expect.

4. It isn't compatible with any existing implimentation that people transitioning to Mushclient are going to be expecting.

5. Anything it does with the 'find x' lines trick can be done more effectively in other ways.

6. It does not and cannot fix the problems that already exist with capturing lists, since it only provides a way to match a special line at the end of the list, which isn't always possible even using existing methods.

Top

Posted by Shadowfyr USA (1,791 posts) Bio

Date

Reply #18 on Fri 23 Apr 2004 02:05 AM (UTC)

Amended on Fri 23 Apr 2004 02:06 AM (UTC) by Shadowfyr

Message

Oh.. BTW, doesn't regexp already allow for what you are doing the hard way anyway:


match="^\-*[ IMMORTALS ]\-*$((?s)(.*)){,10}^(.*) players?\.\z"
                                     ^^^^^

Or am I confused?

Top

Posted by Nick Gammon Australia (23,158 posts) Bio Forum Administrator

Date

Reply #19 on Fri 23 Apr 2004 02:06 AM (UTC)

Amended on Fri 23 Apr 2004 02:09 AM (UTC) by Nick Gammon

Message

Quote:

Frankly I would have never considered actually specifying the number of lines to expect. It frankly makes no sense to do so.

Actually, it works around the problem that I had years ago when I explained why it wasn't easy to do multi-line triggers. (Now that I want it I can't find a forum post that covers that exact subject in detail, giving all the reasons).

The problem with multi-line triggers is *limiting* the trigger somehow. If you have something like:


You are carrying:
  (x lines here)
  (blank line)

Where "x" could be 1 to 70, say, then how does MUSHclient know when to start matching, and when to stop? Clearly it can't when it gets the line "You are carrying" because it doesn't have the rest yet, and how does it know when to start matching if the lines that it is matching on are themselves variable?

The solution I thought of, which you don't have to use if you don't want to, is to allow you to specify a limit (eg. go back 60 lines). This then lets MUSHclient assemble a block of lines (60, say) and pass them to the regexp processor.

Clearly the more lines you specify the slower it will be, however if you specify too few, you may miss a match (eg, 5 would be too few if you had 10 items in your inventory).

Thus, you compromise between speed and whether you match a lengthy sequence or not.

What you could do, if you wanted to speed things up, would be to have a normal trigger match the first line (eg. "You are carrying") and have that enable the multi-line trigger. That means you know that the multi-line trigger should match soon. Then when the multi-line trigger matches it could disable itself, ready for next time.

(edit) This was written while you were writing your recent post, so it doesn't address the issues you raised there.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Top

Posted by

Shadowfyr USA (1,791 posts) Bio

Date

Reply #20 on Fri 23 Apr 2004 02:18 AM (UTC)

Amended on Fri 23 Apr 2004 02:54 AM (UTC) by Shadowfyr

Message

Well yeah. My point is that I think regexp already provides and internal limitation on that, though you are right, it would complicate things a bit to check to see if something ending with a $ is in () and followed by such a limiter. In most cases though the way the matching multiline trigger are designed, there is an assumption that they will only match as many lines as there are $ in them, not including of course anything that followed the last $. Basically, if you tell it ...$..., it should always be two lines, unless you actually do something silly like using (^ ... $)+, which would make the number theoretically unlimited. That could definitely be a problem, but a user error type problem, not something the client necessarilly has to fix for them.

In any case, I expect that using a look-back would be bound to add extra overhead that is not really needed in most cases it will be used, if at all. That is more worrysome that needing to say build an endless loop manager that only lets stuff like {1,} or + match 50 lines before it automatically bails out as a safe guard. Most will not be that open and will already match by definition a very specific number of lines.

At this point I am getting the feeling that maybe you are mixing up two similar but completely unrelated issues.

Top

Posted by Nick Gammon Australia (23,158 posts) Bio Forum Administrator

Date Reply #21 on Fri 23 Apr 2004 02:47 AM (UTC)

Message

I really don't see how that will work. Your suggestion of counting "$" signs falls down on a number of counts. For one, regexps allow for .* to match newlines if you use the "dotall" option, thus there could be *no* "$" in the regexp.

Second, you gave the example of match room descriptions, or gossips. Here is a room description:


Darkhaven Academy
You stand inside the Darkhaven Academy, an establishment designed to teach
the basics of play inside this game.  Each room has a specific purpose and
contains information on the various commands to maneuver around and interact 
with the players.  We recommend you explore the Academy in full, taking the 
time to read the instructions in each room.

And another:


North-West Corner
This area will allow you to further hone your combat skills. Kill the beasts
that wander here. If you wish to leave, exiting up will take you to the room
for Toric, the Lord of Healing, in the Darkhaven Academy.

They have different numbers of lines. How can I make a regexp that counts "$" signs to match a variable number of lines in a description? I can't. (I think I see where you got this idea, zMUD seems to do just that).

The regular expression matcher (which I didn't write) is called like this:

match = regexec (regular_expression, text_to_match);

Now the regular_expression bit is easy - you supply that. But the text_to_match? How do I assemble the text if you want me to match multiple lines, and I don't know how many are going to match (eg. a multi-line room description)?

In your simple example, of say two lines, in my system you would do this:

match = line 1 \n line 2
number of lines = 2

That will be as quick as any other method.

However for multi-line things (like room descriptions) you basically have to give a limit (eg. 10 lines) and it will go back that many lines and try to match for you.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Top

Posted by

Shadowfyr USA (1,791 posts) Bio

Date

Reply #22 on Fri 23 Apr 2004 03:31 AM (UTC)

Amended on Fri 23 Apr 2004 04:03 AM (UTC) by Shadowfyr

Message

Hmm. I think the problem here is that such expressions in most clients don't use 'dotall' and .* to mean everything including the end of a line. This is probably why most clients don't even provide that as a possibility. In the case of room description like you mention, or even with channels, there may be no way to know how many I need to match. Even attempting to specify a number will result in incorrect results. You can't tell the trigger how many to look for unless there is something very specific, like a color change or obvious change in a line. I doubt other clients do any better of a job with that sort of thing than mushclient, even with multiline ability. You method flat out cannot and does not solve it. But the fact that people transitioning to Mushclient, that wonder why the heck they need to tell it to match two lines, when the match text appears to already specify that, are likely to be a bit confused to be more of an issue.

Your concept works, but only in cases where you are sure of how many lines for it to look for. Mine can't match multiple instances of the same line in a group of lines (and making it do so would be complicated, so imho should probably produce an error if attempted), but behaves as I expect it to in the first place when defining a normal multiline trigger. Both are useful, but both have flaws as well. I am not sure that telling something to match:

^You smile and congratulate (.*?)\, conferring upon (.*?) the right to wear the $(.*?) belt\.$

as in the start of this thread makes sense to also require that you tell it two lines. It should be implied in this case. Allowing someone to specify 'dotall' to mean 'everything including the end of line' is frankly just complicating what 'should' be very simple. It makes sense in a text parser with unlimited run time and no interactivity, but having to artificially limit it, even when the limit is implied, in a client to make it work right means you didn't design the implimentation right in the first place imho. Again, there are better ways to do lists, which don't require obfuscating syntax that people migrating to mushclient are going to expect to work another way. Most people are never going to use it the way you suggest and as I said before, there are already ways to handle those cases when it does make sense.

Now.. I 'may' be willing to accept it is the line count was automatically set when the expression can and does imply a specific number, but I don't think it is reasonable to force people to set it manually when it is completely unneeded or setting a special flag to activate what *should* be implied in the expression in the first place.

Frankly, I doubt I would even try using such triggers for capturing room descriptions or channels or anything like that anyway. If I had to guess, though they make useful examples. I would be extremely surprised if even 1% of the uses for multiline triggers exceeded 2-3 lines or *ever* tried to capture generic unknowns like lists. I have never seen any such use, possibly because other client designers didn't think that was or should be a feature of multiline triggers any more than I would have thought it was, until you suggested it should. I would rather that the syntax used do what I specified and generate an error when you try something stupid like 'dotall' or (^...){some_limits}, which won't break the behaviour people are expecting (by requiring extra settings) and that there be a seperate feature for what you are suggesting that does break it, but provides added functionality. If you forget about the whole 'what happens if it needs to match on more lines than there are $' issue, then it may be technically broken with respect to the full regular expression syntax (but what client isn't), but it doesn't require all the extra junk you are doing to make it work, unless you really truely absolutely need it.

splitting out the two problem and not trying to treat both as equal situations should make everyone happy. The overhead for implied limits would be limited and apply to 'all' regular expressions, while your extended function would work for those cases it makes sense to do it the hard way. No one said you had to implement everything standard regular expressions do, including the concept that 'dotall' really means everything. For a mud client allowing that is imho probably a stupid idea anyway and not particularly useful.

Top

Posted by Nick Gammon Australia (23,158 posts) Bio Forum Administrator

Date

Reply #23 on Fri 23 Apr 2004 04:11 AM (UTC)

Amended on Fri 23 Apr 2004 04:12 AM (UTC) by Nick Gammon

Message

Quote:

Most of the time if I am trying to match multiple lines it isn't going to be a list. It will be more specific information like a room description

...

Frankly, I doubt I would even try using such triggers for capturing room descriptions or channels or anything like that anyway.

Can you clarify what you want to match multiple lines for? Your two posts here really contradict each other. First you say you want to capture stuff "like a room description" and then you say "I doubt I would even try using such triggers for capturing room descriptions ".

Quote:

Your concept works, but only in cases where you are sure of how many lines for it to look for.

The "line count" I specify is only a maximum number to go back. You can specify an "anchor" (eg. \z) at the end of the regexp to anchor it to the end of the group (as I have done in some examples here) so that if you have two inventories it won't find the first instead of the second.

Quote:

Allowing someone to specify 'dotall' to mean 'everything including the end of line' is frankly just complicating what 'should' be very simple.

I can't agree with that. Allowing a match of multiple lines (eg. a room description) seems to me to be the very thing that multiple line matching would be about. Matching multiple lines, including newlines, and with an indefinite number to match. The line count is only an upper limit, for speed purposes. For instance, if your inventory is normally 15 items or less, and you want to capture it, then you would set the line count at 15. However that handles cases of 14, 13, 12 and so on as well.

In the case of the example that triggered off this thread, he could do it like this:


<triggers>
  <trigger
   enabled="y"
   lines_to_match="2"
   match="You smile and congratulate (.*?), conferring upon (.*?) the right to wear the\nred belt."
   multi_line="y"
   regexp="y"
   send_to="2"
   sequence="100"
  >
  <send>match = %0
%%1 = %1
%%2 = %2</send>
  </trigger>
</triggers>

Testing this reveals this match:


match = You smile and congratulate Salazar, conferring upon him the right to wear the
red belt.
%1 = Salazar
%2 = him

This seems pretty natural to me, and is pretty-well what he asked for in the first place.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Top

Posted by

Shadowfyr USA (1,791 posts) Bio

Date

Reply #24 on Fri 23 Apr 2004 04:58 AM (UTC)

Amended on Fri 23 Apr 2004 05:00 AM (UTC) by Shadowfyr

Message

Well.. I used them as an extreme example, but virtually every case I have seen has either been someone saying "I can do this in zMud, but how do you do it in mushclient" or are otherwise trying to match fairly specific cases where the number of lines are implied by default. The problem involving lists doesn't show up when trying to search on multi-line issues, because none of us expected that sort of ability in such a trigger. The problem was more of a "how to get it to stop, if we don't know where it will end." Tacking a termination line on it doesn't work, since the cases where these problem happen don't have any line you can match on to stop the capture, multiline triggers are never even mentioned in those threads.

Yeah, you saw it as a problem, but we never thought of it as one, because we never expected such triggers to match more than a few lines in the first place. We never mentioned lists and multiline triggers in the same threads, *that I know of*.

All I am saying is that in general, the same problem exists with your trigger as already exists with existing methods. You haven't really solved anything that isn't still a problem for other methods and you have added the need to specify the number of lines to look at, even in cases where the trigger itself implies that it can't match more lines than that anyway, which is redundant. As for 'dotall', as I said, I don't plan to use it, people migrating from zMud won't expect it, other clients don't allow it and providing it adds extra settings that are unnecessary for most uses, and doesn't fix the original problem that lists, without known termination lines, already have using the existing methods. What exactly does the extra overhead and the requirement for use to specify how many lines to look for actually provide? Not much as far as I can see, it just adds one more setting we have to import or set in scripting to get the trigger to work right when we do use it.

But that is unfortunately only my opinion, Magnum and most others probably haven't even bothered to check this thread, since it doesn't indicate that we are discussing a feature to be added, not just someone elses problem. For that matter, I haven't seen Magnum on the mud for a few days, so he may not have even seen this thread. I would prefer more feedback from some other people on the subject, especial those that previously asked about the implimentation of such a feature in the first place. :(

Top

Posted by Nick Gammon Australia (23,158 posts) Bio Forum Administrator

Date

Reply #25 on Fri 23 Apr 2004 07:10 AM (UTC)

Amended on Fri 23 Apr 2004 07:11 AM (UTC) by Nick Gammon

Message

Quote:

... we never expected such triggers to match more than a few lines in the first place ...

So it does *more* than you expect? Excellent!

To cover your other points:

This is an optional extra. If you don't specify the multiline flag then triggers will behave the same as before, so writing plugins etc. will not change
By using a reasonably powerful regexp I can see lists being matched fairly well. For instance:

Match: You are carrying:\n(([ ]{5}.*\n)*)(?![ ]{5})\z

This will match my inventory list starting with "You are carrying:", capturing lines starting with 5 spaces (the inventory) and stopping at a line that *does not* start with 5 spaces. The final \z anchors it to the end of the buffer, so if it happens to have more than one inventory in it, this trigger will match the latest one.

Effectively this encapsulates the original idea of 3 triggers (first, middle, last) into a single trigger which doesn't need enabling/disabling, so it seems neater to me, not more complex.
It won't break existing behaviour, as you have to turn it on.
For people that just want to match 2 consecutive lines, like the example at the start of this thread, it does just that, in almost exactly the way the thread originator expected.
As for "automatically counting lines" - apart from the issue that the line count could vary, if you are matching a 3-line sequence, that you see in front of you, it isn't too complex to type in the number "3" into the "number of lines" box. I suppose it could count \n characters, but in the example above of the inventory, the \n is inside a "repeat count" which could be any number, so it would get the count wrong.

Comments from other "multi-line" users are also solicited. :)

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Top

Posted by

Shadowfyr USA (1,791 posts) Bio

Date

Reply #26 on Fri 23 Apr 2004 06:24 PM (UTC)

Message

Car planes do more than expected to, but they tend to perform badly as both cars and planes. Not to mention the inconvenience of having, for most designs, to dig the wings out of the trunk to strap them on every time you need to fly one. Using /n and telling it the number of lines it needs to look at, even when it is technically redundant, just seems cludgy and is definitely not the behaviour any of us where looking for. Yeah, it does more than we asked, but in some cases that isn't a good thing. I personally think that what you are doing makes sense as a special list reader, but that making regexp behave more like they do in other clients when using $ is a different issue. Trying to shoehorn both the wanted behaviour and something requiring an extra setting to work all into one function isn't practical. I could care less about how easy you think it is to tell it '3 lines', it still isn't directly compatible with existing implimentations and the behaviour of regexp, unless you explicitly give it a number is still *broken*.

It is also an example of why most clients impliment their own modified regexp system, instead of relying on one that was never intended to parse streaming text from an interactive source. I seriously doubt any of them have to even worry about matching multiple lines using this method. It doesn't make any sense for them to do so, unless it is static text. Your trying to turn what should be a line by line matching system into one that attempts to manipulate the mud output as static. This is not the way regexp in mud clients do things for a very good reason, the lines can change (as you have pointed out) in ways by other triggers that make them unparsable. Also, you *only* want to parse the *muds* output, not anything you may post as a note in the same window. If the note is timed output, it could very easilly end up in the middle of what is being parsed, a possibility which also breaks the expected behaviour, which should only parse the mud output, not anything else.

Top

Posted by

Shadowfyr USA (1,791 posts) Bio

Date

Reply #27 on Fri 23 Apr 2004 06:42 PM (UTC)

Message

Oh yes.. And also:

> Thus the matching text is the whole thing. Let's look at wildcard 1:
>
>
> Match =
> "
>
> Supreme Entity Nick the Recruit.
> Supreme Entity Helen the Supreme Entity.
> "

Ooh! Brilliant, if what I wanted to do is capture every name seperately as one wildcard and deal with them individually, your method slaps me with one huge wildcard that I am now forced to reparse all over again to return the results I originally wanted... How is that an improvement over using the three trigger method to capture each line as it arrives? Having wildcard 1 contain the 'entire' list would be completely useless. I doubt anyone else would disagree. In then end I end up doing more work to retrieve the results than I did making three seperate triggers to start reading the list, capture the list contents item by item and finally terminate it.

I was so busy arguing about the implimentation of simple muliline triggers that I failed to notice just how (forgive me for saying so) dumb this idea really is. It doesn't make it easier to capture lists, it actually requires extra and normally totally unnecessary work to use the information it captures in any useful way.

Top

Posted by Nick Gammon Australia (23,158 posts) Bio Forum Administrator

Date Reply #28 on Fri 23 Apr 2004 09:54 PM (UTC)

Message

OK, thanks Shadowfyr, I gather you don't like the idea? ;)

I was interested to look into your claims that "other clients" handle it much more easily. I checked out zMUD, and I notice a couple of things. First, in the help file I see this:

Quote:

Sometime you just need to capture a bunch of lines. Things like who lists, room descriptions, inventory lists, etc. can be tough to grab with single triggers. This script captures multiple lines and stores them in whatever format is needed, this is a highly advanced script, and while I will try to explain it thouroughly it may still be difficult to follow.

Then a lengthy script follows which is similar in concept to what MUSHclient users have needed to do so far, enable/disable multiple triggers.

However I also notice that simple multi-line capture is possible by simply using the "$" symbol. I presume it must count them and go back that many lines, which is what you want, I gather.

But, that is using his own regular expression matching syntax, which he has control over the parsing of. Using the publicly available (and more powerful, if I say so) PCRE syntax that wouldn't be as easy.

I note also that zMUD is now offering PCRE regexp matching as an option, I wonder if multiple lines are supported if you use that?

Quote:

Ooh! Brilliant, if what I wanted to do is capture every name seperately as one wildcard and deal with them individually, your method slaps me with one huge wildcard that I am now forced to reparse all over again to return the results I originally wanted...

You use Split on the newline character. Or, the new table-management code in MUSHclient if you are not using a script language that supports Split or something similar.

I don't think there is an easier way to handle multiple lines, where you might have 50 matches.

However, again, you don't need to do it that way if you don't want to. Use the old method if you prefer it.

I think however this system would make things like stat rollers much simpler. Something like this:


Rerolling please wait.
-====================== CHARACTER ATTRIBUTES SELECTION ======================-
            Strength (ST): 30( 77)   Constitution   (CO): 33( 53)
            Quickness(QU): 40( 40)   Agility        (AG): 52( 52)
            Presence (PR): 24( 84)   Self-Discipline(SD): 29( 39)
            Empathy  (EM): 20( 68)   Memory         (ME): 40( 40)
            Intuition(IN): 26( 47)   Reasoning      (RE): 29( 39)
            
Are you happy with these attributes?

This could be a single trigger with a single regular expression (with \n to indicate line breaks), rather than the previous method of about 7 triggers that have to turn each other on and off, remember variables and so on.

I really can't see what the big objection is to that. :)

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Top

Posted by

Nick Gammon Australia (23,158 posts) Bio Forum Administrator

Date

Reply #29 on Fri 23 Apr 2004 10:44 PM (UTC)

Message

Quote:

Also, you *only* want to parse the *muds* output, not anything you may post as a note in the same window.

My system does exactly that. It keeps track of the last 100 lines of output from the MUD, and uses that to assemble the text to match on. Notes, timers, commands etc. will not be included.

Quote:

It is also an example of why most clients impliment their own modified regexp system, instead of relying on one that was never intended to parse streaming text from an interactive source.

Strange, then, that zMUD now offers PCRE matching. Perhaps the modified regexp system isn't all it is cracked up to be.

Anyway, comments from other interested parties?

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

158,236 views.

This is page 2, subject is 4 pages long: 1 2 3 4

It is now over 60 days since the last post. This thread is closed. Refresh page

Go to topic: Search the forum

top