Zugg Software :: View topic

Beginner Joined: 12 Aug 2009 Posts: 15

I'm trying to figure out what the right way to use a multistate trigger to collect some stuff. What I want the trigger state to do is to fire the script as long as the line matches and then move on without firing on the first line that doesn't match.

For example, if the mud gives me this text:

a=1
a=2
b=1
b=2

And I have a trigger that is like this:
State0 pattern: a=(%d)
State1 pattern: b=(%d)

I want state 0 to fire on "a=1" and on "a=2" and then move to the next trigger on "b=1" which would then be caught by state 1. Then "b=2" causes State 1 to fire a second time.

There are other ways I can work around this, and ways to do what I need to get done, but they seem kind of ugly to me (for example I could easily do (%a)=(%d) and then do an if to see if %1 is a or b). So while I'm always happy to have inventive solutions, the problem is less that I'm absolutely stuck and more that I feel like there's probably a cleaner way to do what I want to do.

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

Depends on the character of the lines. If the list is always the same length with no chance at all of changing then you can use LoopLines. However, if the list length changes then you'll want to use the Manual state. With that one, you will need to match some unchanging line before the variable-length list and then in the manual state determine when you've come to the next unchanging line immediately after the list.

For example, give a list like so:

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

Why not then have something like this?
state 0 a=({1|2})
state 1 b=({1|2})

At the end of both states have an if that says if %1 == 2 switch to the other state.

Beginner Joined: 12 Aug 2009 Posts: 15

Well I've resolved this problem mostly satisfactorily (along the lines of what Matt suggested)

by having something like this:
State 0: PatternThatInitiatesTheSequence
State 1: (StuffI'mLookingFor)|(.*)
script (if %2 = "" ) {DoSomeStuff;#state thistrigger 1} {#gag;#show %line}

So this way, if the stuff I'm looking for isn't found, then the whole line will go into the second parameter. Then I can use the presence of the second parameter to determine whether I found what I want. If I do, I just gag and redisplay the line, so that it looks normal to me, and the next state in the trigger will process the line. If not, then we process it and manually loop back to the same state.

It's not as clean as I'd like, but it does work and doesn't involve extra trigger states or anything too horrible.

The situation is that I'm basically writing a custom room analyzer, and the specific context is the items and mobs in the room.

So I get something like:
An Example Room
This Room is an example blah blah
blah blah blah
blah blah

[Exits: north east south west down]
An item is sitting on the ground
( 2) A different item is sitting ont he ground
(Humming) A feature of the room is here.
(White Aura) A mob is here
Another mob is here

My Prompt 100hp 100mp etc

So as you can see there are a few different ways an item can look. What I want is to store all the items and mob lines in a list which I'll process, look up in a database of mobs and items and then associate with the room. I also want to parse out the tags like (glowing) (humming)

So the pattern for the items is ^(?:\s+|\( \d+\))\s*((?:\(\a+\)\s*)*)(.*)|(.*)

The pattern for the mobs is ^((?:\(\a+\)\s*)*)(.*)

I'd still like it if there was a trigger that would basically look at an incoming line of the mud, execute if it matches the pattern and stay on that state, or, if the pattern wasn't matched, move on to the next state, and try its pattern. That would be the cleanest way to do what I'm doing, I believe.

And the reason I'm doing this is because I've never had any luck getting the automapper to really work for me. Maybe it's just the mud I play (carrion fields) but it really doesn't seem to be able to map correctly. Plus I want some features it simply isn't designed to support. I plan to use it as sort of a front-end for the stuff I'm doing, which will go into a postrgesql database.

Here's the XML for the whole thing, if anyone's curious. It's still totally raw, so the naming conventions and style are crap right now. :)