Parsing a line arriving -before- the trigger

Alaran
Posts: 27
Joined: Sat Dec 19, 2009 2:51 pm

Parsing a line arriving -before- the trigger

Post by Alaran »

Very simply I have the following problem. When I type look I receive text like this:

line 1: room title
line 2: room desc + items + players.
line 3: room exits.

Line 1 and 2 can always vary almost entirely. Triggering off of colour alone isn't something I prefer doing either. So my only choice is to trigger off of the room exits. But I want to parse the contents of line 2 to find any specific strings (for example monoliths).

Now my problem is that apparently mudlet splits up this one line into several. My wrapwidth in the mud is 0, mudlet is set to 100. If I moveCursor to (for example) 2 lines -prior- to the current one then I receive only part of what line 2 originally was - noticeably the part that is 1 line on my -display- now.

In other words mudlet seems to -add- linebreaks permanently. Is there any way to parse my line 2 entirely by triggering off of line 3?

User avatar
Vadi
Posts: 4878
Joined: Sat Mar 14, 2009 3:13 pm

Re: Parsing a line arriving -before- the trigger

Post by Vadi »

Iocun seems to be doing this in the screenshot he gave me before: http://www.mudlet.org/wp-content/upload ... wbxsgg.png

I'll check the permanent linebreak thing though. Sounds very wrong.

ixokai
Posts: 63
Joined: Fri Dec 25, 2009 7:43 am

Re: Parsing a line arriving -before- the trigger

Post by ixokai »

As is in that screenshot, I think the only way to do it is to match color followed by the exit line (so the color elsewhere doesn't hit).

Alaran
Posts: 27
Joined: Sat Dec 19, 2009 2:51 pm

Re: Parsing a line arriving -before- the trigger

Post by Alaran »

I'll try that. Thanks.

User avatar
Heiko
Site Admin
Posts: 1548
Joined: Wed Mar 11, 2009 6:26 pm

Re: Parsing a line arriving -before- the trigger

Post by Heiko »

Alaran wrote:Very simply I have the following problem. When I type look I receive text like this:

line 1: room title
line 2: room desc + items + players.
line 3: room exits.

Line 1 and 2 can always vary almost entirely. Triggering off of colour alone isn't something I prefer doing either. So my only choice is to trigger off of the room exits. But I want to parse the contents of line 2 to find any specific strings (for example monoliths).

Now my problem is that apparently mudlet splits up this one line into several. My wrapwidth in the mud is 0, mudlet is set to 100. If I moveCursor to (for example) 2 lines -prior- to the current one then I receive only part of what line 2 originally was - noticeably the part that is 1 line on my -display- now.

In other words mudlet seems to -add- linebreaks permanently. Is there any way to parse my line 2 entirely by triggering off of line 3?
1. This is a classical example for the use of a multistate trigger.
2. multimatches[3][1] will get you the original line of #2 if you chose the conditions below:
#1 color pattern on room name
#2 line spacer : 1 line
#3 perl regex: .*
#4 your exit triggers ...

All lines in the buffer represent lines as seen on the screen i.e. they do end with \n if you use moveCursor() and retrieve the content of the line under the cursor position. However, you can still use perl regex multiline parsing in your Lua script, but the solution above is better. To be more technical, lines in Mudlet's underlying buffer do not contain any \n or softlinebreaks whatsoever - just the characters and their respective text format specs. The \n at the end of the line is added when triggers are being run or when the content of a line is being retrieved in order to simplify regex matching as most people expect a line to end with \n. Using the idea of soft linebreaks in the buffer would be unefficient as Mudlet is primarily designed for high performance.

Alaran
Posts: 27
Joined: Sat Dec 19, 2009 2:51 pm

Re: Parsing a line arriving -before- the trigger

Post by Alaran »

Thanks for the explanation. It worked.. for the most part. I have a couple questions now though:

Let's go with my three lines again:
line 1: room title (cyan)
line 2: room desc (grey), room items (cyan), players (white).
line 3: exits (light cyan)

I set my trigger up like this:
1st line: room title - regex
2nd line: colour pattern - cyan on black
3nd line: exits - regex
4th line: prompt - regex

It matched, but I ran into a couple problems.

1) The "cyan on black" colour trigger did not match the items in the second line, but instead matched the room title. Even though the room title had already been matched by the 1st trigger line. So my question is: Is there any way in a multiline trigger to tell the trigger -on which line- to match a colour pattern? (my line delta was 4, my fire length 0 or 4.. didn't seem to make a difference in this.) (I decided to just switch the colour of the items to something unique to solve this.. but I'm curious if there's another way.)

2) What if I wanted to match players too with a "white on black" colour trigger? My problem with that is that sometimes there will be some, sometimes there won't. But if there aren't any players then my entire trigger won't match. Is there any way to make one line of a multiline trigger match if its there, but have the rest of the trigger match if it isn't anyhow? Or else, is there another way to do that without creating two seperate multiline triggers?

Best I can think of would be to use a tempLineTrigger in the room title that then calls a function on line 2.. but then I'd get everything, not only the part with the "white on black" players. Or alternatively, enable a "white on black" colour trigger.. but where? And where to disable it again? :/

3) The above trigger had another purpose too, and that was to act as a filter for an exit line parser. The problem is that (I think?) the last line of a multiline trigger gets passed on. So my exit line parser only works when line 3 is the last line (as in I had to remove the extra prompt check). Not a big thing, just wondering if there's another way - to specify which line gets passed on or some such.

User avatar
Heiko
Site Admin
Posts: 1548
Joined: Wed Mar 11, 2009 6:26 pm

Re: Parsing a line arriving -before- the trigger

Post by Heiko »

For starters, look at my example again. That's what line spacers are for. Line spacers #n formulates the condition: return true if n lines have passed. Remember that Mudlet's multistate condition trigger engine is much more powerful than multi line regex pattern matching. The trigger engine creates a new match state whenever condition #1 evaluates to true. Then it evaluates condtion #2, #3 etc. until a condition == false. This also anwers some other questions of yours as this means that unlike Perl regex multiline matching, where you have to know exactly where the new lines are positioned in the pattern, Mudlet doesn't need to know that as all patterns could be on the same line or spread over a varying amount of lines as long as the all condtions are fullfilled in the correct sequence within the specified line delta. If the line delta gets higher than allowed, the respective match state will simply be discarded and the trigger will wait for some of the other states to mature enough to fire the trigger. For examples on how to do practical multiline matching search the forums.

Second, multistate triggers operate on logical AND conditions in sequence sensitive context. Mixing AND with AND and sub-OR conditions is not directly supported because it's not really necessary because you can emulate such a behaviour with perl regex + Lua conditions. Adding this to the state machine would make it more difficult to visualize what's going on. There have been discussions about this in the past and how this could be visualized -> developer forum. Maybe in the future, but it's not really necessary.

Acolyte
Posts: 2
Joined: Mon Feb 01, 2010 7:23 am

Re: Parsing a line arriving -before- the trigger

Post by Acolyte »

Hey.

Just trying this out, and I've gotten the script to work. I'm trying to append it to a separate window I created, but whenever I do, all the formatting seems to have been stripped. Any idea what's going on?

Also, when I used display(multimatches) to see what was being saved in the tables, I seem to get several tables (4-5). Not sure how to reference the elements in these tables.

User avatar
Vadi
Posts: 4878
Joined: Sat Mar 14, 2009 3:13 pm

Re: Parsing a line arriving -before- the trigger

Post by Vadi »

Use copy() and related functions to preserve formatting: http://mudlet.git.sourceforge.net/git/g ... =HEAD#copy

multimatches[line #][match #] will do. A table is created for each pattern inside it.

Acolyte
Posts: 2
Joined: Mon Feb 01, 2010 7:23 am

Re: Parsing a line arriving -before- the trigger

Post by Acolyte »

Yeah. I did try that. Here's my code. I just display multimatches just to get a sense of what was being captured, and where. Looks like it's matching, but the display is what I'm having trouble with.
Code: [show] | [select all] lua
display(multimatches)
selectString(multimatches[3][1], 1)
copy()
append("CombatSummary")
Here is what shows up when I test the trigger:
Glasfor Pavilion.
This location is flooded with shallow, crystal clear water. Though bustling with activity, this
locale offers a breathtaking vista of the Estate, filled with the scent of fresh grass and the
sounds of birds singing from the great oak trees that provide shade. The cobblestone here is
arranged in a circular pattern, with walkways extending off to the north towards Glasfor Manor, and
to the east and west through the outer grounds. In the center sits a great marquee filled with
various wares that are for sale. Smaller tents have been set up in the grasses between each path,
giving visitors a place to shelter from bad weather and to catch a quick nap. Servants and
groundskeepers stir about, trimming hedges and clipping vines. In the distance, immense snow-capped
mountains rise over the horizon, adding the finishing touch to the glorious landscape. A golden
retriever is here, panting quietly to himself. You see a sign here instructing you to use the PORTAL
command to enter the aetherplex system. You see a sign here instructing you that WARES is the
command to see what is for sale.
You see exits leading north (open door), east, west, and down (closed door).
table {
1: table {
1: ' You see a sign here instructing you that WARES is the command to see what is for sale'
}
2: table {
1: '
'
}
3: table {
1: 'This location is flooded with shallow, crystal clear water. Though bustling with activity,
this locale offers a breathtaking vista of the Estate, filled with the scent of fresh grass and the
sounds of birds singing from the great oak trees that provide shade. The cobblestone here is
arranged in a circular pattern, with walkways extending off to the north towards Glasfor Manor, and
to the east and west through the outer grounds. In the center sits a great marquee filled with
various wares that are for sale. Smaller tents have been set up in the grasses between each path,
giving visitors a place to shelter from bad weather and to catch a quick nap. Servants and
groundskeepers stir about, trimming hedges and clipping vines. In the distance, immense snow-capped
mountains rise over the horizon, adding the finishing touch to the glorious landscape. A golden
retriever is here, panting quietly to himself. You see a sign here instructing you to use the PORTAL
command to enter the aetherplex system. You see a sign here instructing you that WARES is the
command to see what is for sale.'
2: 'This location is flooded with shallow, crystal clear water. Though bustling with activity,
this locale offers a breathtaking vista of the Estate, filled with the scent of fresh grass and the
sounds of birds singing from the great oak trees that provide shade. The cobblestone here is
arranged in a circular pattern, with walkways extending off to the north towards Glasfor Manor, and
to the east and west through the outer grounds. In the center sits a great marquee filled with
various wares that are for sale. Smaller tents have been set up in the grasses between each path,
giving visitors a place to shelter from bad weather and to catch a quick nap. Servants and
groundskeepers stir about, trimming hedges and clipping vines. In the distance, immense snow-capped
mountains rise over the horizon, adding the finishing touch to the glorious landscape. A golden
retriever is here, panting quietly to himself. You see a sign here instructing you to use the PORTAL
command to enter the aetherplex system. You see a sign here instructing you that WARES is the
command to see what is for sale.'
}
4: table {
1: 'You see exits leading north (open door), east, west, and down (closed door).'
2: 'exits'
3: 'north (open door), east, west, and down (closed door)'
}
}

table {
1: table {
1: 'Glasfor Pavilion'
}
2: table {
1: '
'
}
3: table {
1: 'Glasfor Pavilion.'
2: 'Glasfor Pavilion.'
}
4: table {
1: 'You see exits leading north (open door), east, west, and down (closed door).'
2: 'exits'
3: 'north (open door), east, west, and down (closed door)'
}
}
Nothing is being appended to the correct window, even though it's obviously matching. Also, should it be matching that many times?

Post Reply