Zugg Software :: View topic

Apprentice Joined: 04 Mar 2007 Posts: 103

i have found a couple help pages on #cond and trigger states. but i am having trouble understanding how the differnt states are supposed to advance.

I think i have found a few ways to do it, but i am not sure if i am doing it wrong.

I think the #state command allows me to change the state of the trigger but not match the pattern of that state.
where as the #set command allows me to set the trigger state and if i put a 1 after the state number it will be like the pattern was matched.

I am confused about how a trigger naturally moves from one state to the next, asssuming that it is even supposed to.

Often the trigger pattern would be set to {} supposedly matching anything, but some times my triggers seem to get stuck on a state with a {} pattern. I have tried to fix this by putting the set command at the end of each trigger command section.

also i am confused about the newline and prompt options and when to use which or if i should use both or neither.

lastly i can't seem to make sense of the looplines and pattern because they don't always act like i expect. but then that could be becuase i am miss using other parts of the commands.

I know this is alot of rambing but if anyone could comment on my interpretation of how these functions are supposed to be used and if i am barking up the right tree i would appreciate it.

p.s. whats the difference between a command and a function? and why is does a function look like a variable when i make one?

I really have tried to look this stuff up but i havn't found a place where there is a discussion about the use of a command, and some times the help files are a bit ambigious.

i think after i get a few more puzzle pieces of the syntax and concepts it will all start falling together.

Posted: Tue Mar 13, 2007 1:04 am

Ok.. you asked a few things. You are correct about the #STATE command, but I've not used #SET very often so I can't be sure, but based on the documentation it seems you are also correct there.

Moving from condition to condition is relatively simple. When the expression (either mathematical or regular expression) is matched then you move to that state. You can not skip states, meaning if you have a trigger with 3 states the text for state 3 will not match if the text for state 2 has not been matched.

Setting the trigger {} does match anything it matches nothing, or more accurately and empty line. I think what you want is {*}. Consult Pattern Matching for the pattern matching symbols.

The newline and prompt options work together to tell zMUD how to divide the text received. If NewLine option basically trigger on the text between the last CR/LF i.e. '\n' received and this one. Prompt acts in a similar fashion but with prompt instead. At least that is how I visualize, others may explain it better.

Looplines and Loop pattern will always match on their text unless they are used in multistate triggers. In multi-state trigger looplines says look for the pattern in the next N (the number you specify) lines before you go on to the next condition. Similarly Loop patterns says match the N times before you move on to the next condition. So if N is 3 looplines will attempts match on the next 3 lines of text, before going on to the next state. For loop pattern it will match 3 times before moving on to the next state no matter how many lines are in between. It's like having 3 conditions of the same matching text in the multistate trigger.

Commands are a single unit of work. For example you can #EVAL a particular function. But what if you needed a particular functionality within a command, for example setting a variable to the result of an expression then you would use the %function.

#EVAL 100/4

will print 25 to the screen. If you wanted to store that in a variable you could use

#VAR Result %eval(100/4)

Yes there are other ways to accomplish that example, but it should give an idea.

A custom defined function look like a variables because of a limitation in how the feature was implemented. In CMUD among the features in the pipelines is a more robust support for custom functions..

I think I covered all the questions. Everyone else is free to expound.

Wizard Joined: 15 Jan 2002 Posts: 1644 Location: USA

In no particular order:

Apprentice Joined: 04 Mar 2007 Posts: 103

Wow those answers help alot.

to further alaborate on the prompt concept ... if i set the trigger to match the pattern on prompt it will match as soon as the text has entered the buffer? as opposed to having to wait for a cr/lf before it attempts to match the pattern?

Apprentice Joined: 04 Mar 2007 Posts: 103

Thanks to the missing pieces you two filled in and all the other help i got i finally finished the first step in my mapper bot grabbing the exits and putting them in a variable.

Posted: Tue Mar 13, 2007 7:40 pm

The trigger for you first line can be simplified a bit.

Posted: Tue Mar 13, 2007 7:43 pm

Adjusting the client's word wrap settings won't change this any - zMUD checks for triggers before it does the word wrapping, not after.

Adjusting your MUD's screenwidth or linelength options either to 0 or something astronomically high can get rid of this kind of thing, though.

Apprentice Joined: 04 Mar 2007 Posts: 103

I am trying to get this code to work :(

I type StartMapper to get the this going
This should enable my multistate trigger to start ...jumping to the State 1 and then execute a look command
state 1 of my should catch the exits of the current room then advance to state 3 if the exits fit on one line.
jump to state 3 execute glance and advance to state 4
if the exits are on 2 lines then it should progress to state 2 capture the rest of the exits
jump to state 3 execute a glance and advance to state 4
State 4 should capture the short name for the room.

my goal after i get this part running is to execute my AutoMove alias which will get my move to a random room and then start capturing the room description using state 0 of my trigger. advancing to state 1 once the exits line shows up.

It doesn't work write... the debugger output is below.

Apprentice Joined: 04 Mar 2007 Posts: 103

its almost like when you artificially move a mutistate trigger forward after its executed the condition it was forced to it jumps back to where it was?

Apprentice Joined: 04 Mar 2007 Posts: 103

Also, the #SET command can be used to fire a particular trigger state before it would normally be executed. Then, when the trigger gets to that state normally, it will detect that the state has already matched, and skip it.

i found this line of documentation in the online manuals

it implies that using a set command could allow you to jump from state 1 to 4 execute state 4 then automatically go back to where it was i.e. somewhere in state 1?

its almost like using the set command pops that trigger state onto a stack and once that state is done executing it is back where it started. with the only exception that the state will not fire again normally in the normal state incrementation, because its already been run once this round?