[Home] [Downloads] [Search] [Help/forum]

Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  General
. . -> [Subject]  Help with Triggers, Is This Possible?...
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?
(New message)
Subject: Help with Triggers, Is This Possible?...
Name:
Your forum user name.
Register forum user name
Password:
Your forum password.
Forgotten password?
Message:
Message to be posted (in English, please).
Forum codes:
Check this if your message uses 'forum codes' or templates (auto-detected for new posts).
Forum codes Templates

Save this message ...

Subject review (reverse sequence)

Pages: 1 2  3  

Posted by Etzli   USA  (4 posts)  [Biography] bio
Date Mon 22 Aug 2011 01:15 AM (UTC)  [ quote  ]
Message
It should probably also be noted that in CMUD, there is now a #PRINT command that will print the message on the screen but will not fire any triggers. This is similar to the Note functions in MUSH (as far as I can tell).
[Go to top] top
Posted by Fiendish   USA  (848 posts)  [Biography] bio   Global Moderator
Date Mon 22 Aug 2011 12:04 AM (UTC)  [ quote  ]

Amended on Mon 22 Aug 2011 12:06 AM (UTC) by Fiendish

Message
Quote:
The triggers are always evaluated once, per line received. Why is a line index required?
Triggers are evaluated once per line "seen", not necessarily per line "received". I am distinguishing here between lines from the server (what I call received) and lines that appear on the screen (seen). If I have a script in zMUD that echos text to the screen, triggers will fire on that text as well, even though it didn't get "received" from the server. This is all because zMUD apparently does not distinguish between echoing and printing mud output in the same way that MUSHclient does. In fact, if you have a trigger that echos a line of text that it also matches on, you *will* get into an infinite loop in zMUD because the echo is a new line. This is obviously something very easy to avoid in practice, but it gives an insight into the inner workings.

I will also note that zMUD detects infinite loops and offers an opportunity to kill the runway script.
http://aardwolfclientpackage.googlecode.com/
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Sun 21 Aug 2011 11:09 PM (UTC)  [ quote  ]
Message
Fiendish said:

I think the line index comes into it in the sense that at some point you need to decide to allow the first trigger to fire again. I guess this might be at each newline received from the server.


I don't fully understand this part. The triggers are always evaluated once, per line received. Why is a line index required?
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Fiendish   USA  (848 posts)  [Biography] bio   Global Moderator
Date Sun 21 Aug 2011 06:53 AM (UTC)  [ quote  ]

Amended on Sun 21 Aug 2011 06:56 AM (UTC) by Fiendish

Message
Nick Gammon said:

Fiendish said:

zMUD will not easily let you get into an infinite loop, because a given trigger won't re-sub for the same line index.


Does zMUD let you substitute the actual contents? In other words, change the line "in situ" so that the next trigger matches the changed line? If so, the line index wouldn't come into it, would it? THe trigger has already been processed.


Yes it does. If the server is sending "I am Fiendish", triggering on the pattern "Fiendish" (zMUD patterns implicitly begin and end with glob * unless specified otherwise) with the script "#sub awesome" makes it look like the server had sent you "I am awesome" instead of "I am Fiendish". And if you have that AND a subsequent trigger on the pattern "awesome" with the script "#sub delighted" it will look like the server had instead sent "I am delighted". But if you have another trigger that #subs "delighted" into "Fiendish" again, the first trigger will not fire a second time. Thus, no loop.
I think the line index comes into it in the sense that at some point you need to decide to allow the first trigger to fire again. I guess this might be at each newline received from the server.
http://aardwolfclientpackage.googlecode.com/
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Sun 21 Aug 2011 06:07 AM (UTC)  [ quote  ]
Message
Fiendish said:

zMUD will not easily let you get into an infinite loop, because a given trigger won't re-sub for the same line index.


Does zMUD let you substitute the actual contents? In other words, change the line "in situ" so that the next trigger matches the changed line? If so, the line index wouldn't come into it, would it? THe trigger has already been processed.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Sun 21 Aug 2011 06:04 AM (UTC)  [ quote  ]
Message
Yes I understand that. But at present if two triggers fire on "apple" (and are set to keep evaluating) they both fire. One can't change the line (eg. change apple to pear) so that the other doesn't fire at all.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Fiendish   USA  (848 posts)  [Biography] bio   Global Moderator
Date Sat 20 Aug 2011 11:25 PM (UTC)  [ quote  ]
Message
Etzli said:
As for how other clients prevent infinite loops, it's really on the part of the scripter to prevent infinite loops. What I mean by this is given a trigger that substitutes a line, if a scripter substitutes that line back to the original, that'll no doubt cause the infinite loop.
Not entirely true. zMUD will not easily let you get into an infinite loop, because a given trigger won't re-sub for the same line index. If you have one trigger that replaces "apple" with "pear" and another that replaces "pear" with "apple", the first trigger will not fire again.

Nick Gammon said:

I see. So the net effect is that triggers no longer can be designed to fire on what arrives from the MUD (which is probably well-defined). They now have to fire on whatever-it-is that previous triggers changed the line to. And this is somewhat dependent on trigger evaluation order.

Well, MUSHclient does already have a set evaluation order.
http://aardwolfclientpackage.googlecode.com/
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Sat 20 Aug 2011 07:20 AM (UTC)  [ quote  ]
Message
I see. So the net effect is that triggers no longer can be designed to fire on what arrives from the MUD (which is probably well-defined). They now have to fire on whatever-it-is that previous triggers changed the line to. And this is somewhat dependent on trigger evaluation order.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Etzli   USA  (4 posts)  [Biography] bio
Date Sat 20 Aug 2011 06:19 AM (UTC)  [ quote  ]
Message
Nick Gammon said:

So if Trigger1 changes the text, then Trigger2 won't fire at all? Because now the text is different?


Correct. Here's an example of how it goes:


TriggerID:        Test1
Trigger Pattern:  This is a test.
Trigger Output:   Sub with "This test is complete."
Trigger Priority: 0

TriggerID:        Test2
Trigger Pattern:  This is a test.
Trigger Output:   Print "This trigger should not fire."
Trigger Priority: 10


Now print to the screen "This is a test." Test1 will fire, subbing it with "This test is complete." Since Test2 has a higher priority, it never fires because the text is no longer "This is a test." Reverse the priorities, and both triggers fire.
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Sat 20 Aug 2011 05:48 AM (UTC)  [ quote  ]
Message
Etzli said:

The way they are handled is through priority. Example:

Trigger1 and Trigger2 have the same trigger patterns, but send different scripts for whatever reason. The trigger with the lower priority number will always fire first, and therefore, the trigger with the higher priority number will fire last.


So if Trigger1 changes the text, then Trigger2 won't fire at all? Because now the text is different?
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Etzli   USA  (4 posts)  [Biography] bio
Date Sat 20 Aug 2011 01:24 AM (UTC)  [ quote  ]

Amended on Sat 20 Aug 2011 06:22 AM (UTC) by Etzli

Message
The way they are handled is through priority. Example:

Trigger1 and Trigger2 have the same trigger patterns, but send different scripts for whatever reason. The trigger with the lower priority number will always fire first, and therefore, the trigger with the higher priority number will fire last. This can be seen in CMUD with the priority showing in the xml (and on the options tabs).

I imagine color boundaries are handled by "remembering" the location of the block of text being substituted. For instance, say the block of text was:

Quote:
This is a text block which I am substituting.


and you were wanting to substitute 'text block' with 'block of text.' The client sees that 'text block' starts at position 11 in the string (though with ansi codes, it'll count the beginning of the previous escape sequence) and ends on position 20. The rest of the string is stored in a temporary variable, preserving the ansi codes with it. The text is then substituted at position 11, therefore changing it to:

Quote:
This is a block of text which I am substituting.


Again, with the ansi escape sequences, the actual position will be much higher (e[1;34m, for example, adding another 7 characters) and the client would have to account for this.

My statement on color boundaries is pure speculation, as this is how I would imagine it works, but since I don't have the actual code itself, I cannot accurately give the proper procedure. That's the downside of non-open sourced clients.

As for how other clients prevent infinite loops, it's really on the part of the scripter to prevent infinite loops. What I mean by this is given a trigger that substitutes a line, if a scripter substitutes that line back to the original, that'll no doubt cause the infinite loop. Again with guessing, but it wouldn't surprise me if other clients put the text in a queue to be processed before being printed on the screen, something like below:

Quote:
Step one: Text received from MUD, place in internal queue.


Quote:
Step two: Is received text supposed to trigger substitution? If so, execute trigger. If not, proceed to step four.


Quote:
Step three: Is new text supposed to trigger a substitution? If so, repeat step two.


Quote:
Step four: Display text on screen.


Again, this is all speculation, and in a fantasy world, I'd be 100% right about the procedure, but maybe it'll serve as a ground point to implement what's being asked here today.
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Fri 19 Aug 2011 09:59 PM (UTC)  [ quote  ]
Message
Out of curiosity, how do other clients handle this issue? If possible give examples, and describe how they avoid issues of looping.

I don't mean specifically "triggering on notes" as they may not have the concept of notes. But how do they handle the underlying problem that is trying to be solved?

Assuming for the moment (which may not be correct) that they allow textual substitution in the incoming line (the line you are triggering on), which alters how further triggers "see" the line, how do you handle things like multiple plugins both wanting to see (say) "{channel_tag}*" - if one trigger removes "{channel_tag}"?

Also if textual substitution is permitted, how to they handle colour boundaries on the source text?
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Twisol   USA  (2,229 posts)  [Biography] bio
Date Fri 19 Aug 2011 03:27 PM (UTC)  [ quote  ]
Message
No, Simulate pipes a line back to the primary source. Triggers should act as a line source themselves. Only triggers that know what they're getting into (i.e. are chained to this trigger) receive the newly-emitted line from the first trigger.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top
Posted by Fiendish   USA  (848 posts)  [Biography] bio   Global Moderator
Date Fri 19 Aug 2011 05:17 AM (UTC)  [ quote  ]
Message
Quote:
In my concept, triggers listen on a line source, and act as line sources themselves.
As far as I can tell, this is what Simulate does. But I keep hearing that Simulate is to be avoided.
http://aardwolfclientpackage.googlecode.com/
[Go to top] top
Posted by Twisol   USA  (2,229 posts)  [Biography] bio
Date Fri 19 Aug 2011 05:11 AM (UTC)  [ quote  ]
Message
This probably isn't helpful in the context of MUSHclient, but I've thought a little about how I would implement this within Aspect. In my concept, triggers listen on a line source, and act as line sources themselves. By default, a trigger listens on the primary source (the lines coming in directly from the MUD). However, you could have a trigger listen to another trigger, allowing changes to propagate. Unrelated triggers are left unaffected.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

8,771 views.

This is page 1, subject is 3 pages long: 1 2  3  [Next page]

[Reply to this subject]  Reply to this subject   [New subject]  Start a new subject   [Refresh] Refresh page

Go to topic:           Search the forum

[Go to top] top

[Home]

Written by Nick Gammon - 5K

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Internet Contents Rating Association (ICRA) - 2K]    [Web site powered by FutureQuest.Net]