Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » zMUD General Discussion
Blerghass
Beginner


Joined: 25 Nov 2001
Posts: 26
Location: USA

PostPosted: Thu Dec 27, 2001 2:54 am   

Preventing a trigger from going off after T+
 
Basically, I'm wondering how to T+ a class of triggers so that those triggers will start acting when the next line comes in instead of on the current line.

Here's my situation. One trigger is set off by ^(*)GSM. This trigger in turn has the line {T+ barfclass}. "barfclass" has a trigger set off by ^(*)$. "barfclass" is disabled when the GSM line comes in, so the ^(*)$ trigger in "barfclass" doesn't go off immediately when that line comes in. But because the T+ line goes through, the ^(*)$ trigger in "barfclass" then goes off on the same line that caused the {T+ barfclass} in the first place.

#GAGging and "notrig" don't seem to help. Any ideas?
Reply with quote
Blerghass
Beginner


Joined: 25 Nov 2001
Posts: 26
Location: USA

PostPosted: Thu Dec 27, 2001 11:08 am   
 
The partial solution I found after more tinkering was to {#sub ""}. This does not work, however, if you actually want to display the line as it was.

Also, I could pad the ^(*)$ trigger like this:

#trigger {^(*)$} {#if (@stat = 1) {do something; @stat = 0} {@stat = 1}}

This works because a trigger will only set off once per match.

A third but still imperfect option is to have the ^(*)$ trigger have higher priority, so it will not set off after the other trigger #T+'s it.

Is there any simple way to prevent any other triggers from going off on a given line of text?
Reply with quote
iljhar
GURU


Joined: 10 Oct 2000
Posts: 1116
Location: USA

PostPosted: Thu Dec 27, 2001 8:36 pm   
 
That's one of the drawbacks of classes, in my opinion. As you experienced, a trigger turns on a class, that class has a trigger that catches everything and processes that line. Since the first trigger turned on the class it also gets processed inside the class. I don't know how to stop that "feature", but it looks like you may have found a good solution, setting a variable. Now, you probably don't want to reset the @stat var to 0 until right before you disable the class, just in case you happen to get more than 1 line before the GSM line comes in.

Iljhar
Reply with quote
Blerghass
Beginner


Joined: 25 Nov 2001
Posts: 26
Location: USA

PostPosted: Thu Dec 27, 2001 10:23 pm   
 
I found another solution that is pretty robust.

I put all my "normal" triggers into one class, call in NormalClass. I then put a couple triggers in another class, call it OtherClass:

#trigger {^*$} {#T+ NormalClass; #T- OtherClass}
#trigger {^$} {#T+ NormalClass; #T- OtherClass}
(second one because ^*$ doesn't match the empty line)

Whenever I want a trigger to disable all other triggers from triggering on a given line, I simply put #T- NormalClass; #T+ OtherClass at the end of it (probably make it an alias just to save some time).

As long as OtherClass has lower precedence/priority than NormalClass, I think this works (my tests have gone fine). It appears to be very robust and pretty efficient.
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » zMUD General Discussion All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by Wolfpaw.net