 |
Larkin
Wizard
Joined: 25 Mar 2003
Posts: 1113
Location: USA
|
 Posted: Tue Dec 13, 2005 8:03 pm
Variable line wrap triggers
|
Will there be any method by which we can capture variable newlines in trigger patterns reliably? Sometimes a person's name is unusually short or long and the end of a line in a multi-line pattern falls in a different place from the one we expect. Usually, that's easy to deal with, and I do have triggers that can work around this. However, there are some triggers that are much more complicated than that, with more variable terms throughout the entire pattern.
I know that it's nearly impossible to have a PCRE engine capable of matching an arbitrary number of carriage returns on an unknown number of lines, but perhaps if we could specify a maximum number of lines to check, it would help? I have successfully implemented triggers in MUSHclient this way, and it's only because it allows you to tell it how many lines to use in matching a trigger. I may not know where the newlines are, but I usually know how many there are (or at least a maximum that there can be).
In Lusternia, this is especially important when fighting warriors. The messages have verb lists for things like hack/slash/slice/etc that appear in the text, but also a weapon name (which can get quite long), their name, and the results of the blow to your body.
| Code: |
Swinging a shining mace in an underhand arc, Rakor strikes at you, and you
partially parry the blow with a dark steel broadsword. You are barely phased
from getting smashed in the gut.
Swinging a shining mace in an underhand arc, Rakor strikes at you. You are
barely phased from getting smashed in the gut.
Rakor swings a shining mace at you. You are barely phased from getting pounded
in the gut. |
Different attacks, different weapons, different actions (parrying or not), but the same end result to track as an affliction status.
I've tested the use of a pattern such as putting [\s\n]+ anywhere I found a space or newline (beyond a certain point, of course), and in MUSHclient I can tell it to trigger on three lines, which works for most situations, but even that still has "overflow" and can get the trigger into a sort of middle state when too few lines match (as in the second and third messages).
In zMUD, I found that I can make it work sometimes by matching phrases with only some of the spaces converted to [\s\n]+ patterns, but that required a secondary (very short) wait state to reset it properly and didn't match on all possibilities. Matching on single words or very short phrases doesn't really work, either, because of the nature of all other messages and getting unwanted triggering from the wrong things.
Maybe there's a way to break up the text and pre-process it into multiple (new) lines (swing, parry, rebound, body hit, affliction, etc) rather than one line wrapped. From there, it might be possible to trigger the wounds and afflictions.
Anyway, will there be any change at all in how CMUD deals with multi-line patterns? I won't be too disappointed if the answer is 'no' because I know how tricky it would be to implement. |
|
|
|
|
Rainchild
Wizard
Joined: 10 Oct 2000
Posts: 1551
Location: Australia
|
Posted: Tue Dec 13, 2005 8:17 pm
|
I can definately see use for processing like this. I know Zugg totes the "MUDs should leave the formatting up to the client" banner, but bottom line is MUDs don't, so the client needs to have some smarts to cope with multi-line input.
The one that I have the biggest problem with is working out how long of a chat to capture to the chat window -- I mean, it would be easier if the MUD marked it up with MXP, but it doesn't, so you hafta kludge it along. Likewise, it can be formatted in multiple ways --:
| Code: |
Rainchild tells you: "Hey there"
Rainchild tells you:
"Hi, this is a bit of a longer tell so that it breaks off onto a separate line."
Rainchild tells you:
"Spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam
spam spam spam spam spam spam spam spam spam spam"
Rainchild tells you:
"You thought that last one was spammy? Well... get a load of this... spam
spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam
spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam
spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam
spam spam spam spam spam spam spam"
|
It would be nice to have a couple of options...
* pattern ends on next empty line
* pattern ends in up to 'n' lines
* pattern ends at prompt
* pattern ends if line does / does not start with 'regex'
* pattern ends at 'regex' or 'ansi-code' |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Tue Dec 13, 2005 8:29 pm
|
Rainchild, those are some interesting options that you mentioned at the end. I'll put that on my list to think about.
In the past, the way I wanted to handle this was to figure out a way to "unwrap" the text from the MUD, then let zMUD re-wrap it. Then it would treat something like your examples as single lines and you could use a simple trigger for it.
In Rainchilds example, each "wrapped" line is indented by a couple of spaces. So it's obvious to our human eyes that this is a single line that is wrapped. But not all MUDs add spaces when wrapping a line. So yes, some way to tell CMUD "the end of a line" is needed for some triggers.
Anyway, I'll give this more thought. Since it's not something that is already on my tight schedule, it's unlikely that you'll see anything like this in the first beta version. But it's yet another example of the kind of thing that could be added to CMUD to make it even better in the future.
It's actually stuff like this that makes me sad that I got distracted and didn't just keep working on zMUD over the past couple of years. There are just *so* many areas that can still be improved. |
|
|
|
|
Larkin
Wizard
Joined: 25 Mar 2003
Posts: 1113
Location: USA
|
Posted: Tue Dec 13, 2005 8:41 pm
|
Awesome! Those options really seem like they may be a good solution for this, and I know of many places I'd use all of them. Thanks, Rainchild. I'll be really interested to see if this idea makes it into any version of CMUD one day.
|
|
|
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
