conditional triggers

[Caled]

I am muddling my way through this with the help in the manual, but even if I get it working, there is no guarantee that I will get it working in the best way intended by you, Heiko. So I am asking this question here; it will be a useful example for others as well.

zMud/CMUD Solution

Code: Select all

#TR {You ease yourself out of the %w stance.} {curStance=cankipup}
#COND {*} {} {within lines|param=1}
#COND {^You swiftly swing up} {curStance=nostance} {reparse}
#COND {%e[33m*.} {curStance=nostance} {reparse}

Explanation:
The first condition matches the first line following the initial trigger pattern.
The next two conditions are "reparse" type, which function like a mudlet trigger/filter chain.

In mudlet, could do this with two multiline triggers, and a single line trigger. I can't help but wonder though, if I can combine them into one trigger chain. I cannot figure out how to have a multi-line conditional trigger flow into a trigger filter chain. The manual explains enough to do each type on its own, but not enough to know whether it is possible to combine them.

Code: Select all

Trigger: You ease yourself out of \w+ stance.
Script: curStance="cankipup"

Trigger: You ease yourself out of \w+ stance.
Type: multline - within 1 line
Condition 1: You swiftly swing up
Script: curStance="nostance"

Trigger: You ease yourself out of \w+ stance.
Type: multline - within 1 line
Condition 1: Colour trigger matching ROOM TITLES
Script: curStance="nostance"

Can the above be one trigger rather than three?

[Heiko]

Yes, you can combine elements. I'll explain everything in more detail in the manual.
The manual is still lacking information on *filters*. Filter chains and trigger chains are entirely different mechanisms and serve different purposes.
Both types of chains are switches that only let information pass to their children in the chain if their condition is fulfilled. However, they differ in terms of what they pass on to their children.
Trigger chains pass on the original line to their children while filter chains do not pass the current line to their children, but their matches[] table or multimatches[] table respectively.

If you combine these features with multi condition triggers things get more complicated.
What I've called "multi-condition triggers" is an implementation of a programmable state machine - programmable by the condition list, the pattern list and the line margin. Because you can use Lua code as a "pattern", this is pretty flexible. I haven't fully understood your problem, but I'm sure that you can solve it with the state machine and make it a single trigger item. However, as I understand the problem, the ideal solution would be to have another pattern type "color trigger". We can add this feature to the state machine later.

All of this needs to be explained in detail in the manual - especially what happens if you combine elements.

[Caled]

Hrm, wait - I thought we already could trigger from colours? Did I misunderstand what you were talking about when you said 'colour trigger'?

[Vadi]

Yeah but I think by 'adding it to the state machine' he meant that color triggers can actually be part of this 'chain'. Atm they are on their own - see, fire.

[Heiko]

Hrm, wait - I thought we already could trigger from colours? Did I misunderstand what you were talking about when you said 'colour trigger'?

Yes, you can make color triggers. Color triggers can also be part of trigger chains and filter chains or they can be a chain head. However, as there is currently no trigger *pattern* to describe a color condition, you have to use more than 1 trigger to solve the problem as you cannot include a color condition in the state machine at this point. If we added a color pattern to the state machine, you could express your example triggers in a single trigger instead of 2 triggers.

We have the problem that the trigger engine has new features that no other clients have to offer. This is why we cannot rely on common terminology to describe the different units and the underlying concepts.
I cannot get too technical lest most people wouldn't understand what I'm talking about. This is why words like state machine etc. are taboo.

Our "multi-line" triggers are very different from the multi-line triggers Mushclient and cmud are using, judging from what I've read about those 2 programs though i haven't looked at the code. Both clients use multiline regex whereas we use a state machine in conjunction with a list of conditions that are applied to single lines and expressed in one or more of the available pattern sets. The result is the same, with the exception that our approach is faster, more flexible and more powerful. What I've called multi-line triggers is basically a list of conditions described by patterns of a variety of mostly unrelated pattern sets. Right now these pattern sets include anchored or un-anchored string matching, regex and Lua code. We might add color patterns or even anchored color patterns, but I don't believe that this is really necessary as color triggers are rarely used. We could also offer a color test function that could be used within a Lua condition in the state machine.
I hope this helps.

PS: If anybody comes up with a well thought out terminolgy that makes describing our engine easier to understand, I'd be grateful to hear about it.

[Caled]

I don't understand the technicalities, of course. I'm not convinced, given your explanation, that zmud's multi-conditional trigger system is less 'flexible.' The triggers always have one active state, moving to the next automatically only when their conditions are met, or are told to in script. There seem to be a lot more options available for those conditions as well (though I do understand that we don't actually know what options are available in mudlet, because the documentation is not done).

Still, in zmud I could have a state active for the next 20 lines, then at the end of the 20 tell it to move backwards one state if it matched less than 10 of the lines, or move ahead one state if it matched more than 10, while moving ahead 2 states if it matched all 20 lines. I could have it active for the next x milliseconds, inactive until after the next x milliseconds, and so on.

I don't doubt for a moment that Mudlet's is much quicker, but I've not seen anything with the state machine (which I think is an acceptable term, by the way) that seems to be more flexible. I look forward to hearing about it though.

[Heiko]

I haven't claimed that Mudlet's state machine is more flexible than zmud's condition states. I have claimed that Mudlet's multiline triggers are more flexible than conventional regular expression multiline triggers and I've used this concept to shed some light on the concepts behind the term "multi-condition triggers" that is used in the manual. What is unique in Mudlet is the concepts of trigger chains and filter chains, condition lists and the flexiblility involved with Lua code as a trigger condition. Note that this is as flexible as you want it to be depending on the Lua code that formulates the condition. This can be used for a simple variable trigger or for an entire fight system.
I believe it was Zhiroc who brought up the concept of zmud's trigger states at the time when we were doing the planning for Mudlet's trigger engine, but I do remember you taking part in that discussion.
Some of the concepts that were brought up in the discussion did not seem to be necessary for our system because some of the concepts can be handled implicitly in Mudlet by combining elements to chains or using filters. Unwinding trigger states, fast forwarding states etc. doesn't seem to be necessary in our implementation as Mudlet's state machine is using a multiple-state approach. This means that there may be other states that reach maturity before any other given state.

--> cond #1/state1
........some lines of text
--> cond #2=true /state1
...... some lines
--> cond #1 /state2
........
--> cond #2 /state2
.... some more lines
*** state#1 reaches line delta and gets deleted ****
... some lines
--> cond #3 /state2
===> all condtions are true ===> trigger fires & activates chains

Fast forwarding or reverting states isn't necessary in well designed trigger sets in my opinion, and even if it is necessary it can be implemented via Lua trigger conditions.

[Caled]

Good to know. I'm looking forward to more examples/documentation that will obviously come in the future. I wish I could help with that, actually - but obviously that's not possible yet

[Heiko]

You have already made many valuable suggestions and your comments over the last 6 months have certainly helped clarify a lot of issues and contributed to improving a number of things. The lack of documentation at this point is big problem, indeed. However, it's not easy to come up with good simple examples for the manual as the concepts that still need to be explained are fairly complex and the terminology is still too fuzzy. I'll take up the manual again when I've finished the last couple of missing features/bug fixes.
I'd be happy if you could help improve the manual directly or indirectly. You'd get the necessary support.