Zugg Software :: View topic

Apprentice Joined: 06 Apr 2004 Posts: 173

Hi, I have a request for a new trigger type [, or a function that fetches the sort order number of the current trigger.]

There is a specific order for when all of the triggers are supposed to execute.

I would like to be able to force a trigger/response to be next on the list.

This would be similar to the way an #ALARM {+0} (illegal syntax I know) would respond, except that it would be guaranteed to be next on the list, and would take place after all of the cleanup of the current trigger's execution.

[Optionally you could create a function to set the order of the newly created trigger to be the "current trigger's order + 1", but I think this is more error prone, because new trigger creation could force the order to change.]

For example if you are in a trigger, and use this new trigger type, the current trigger will continue to operate normally, but when it finishes the next trigger to fire would be this one.

Enchanter Joined: 09 Sep 2007 Posts: 605

Set reparse option for an initial trigger and add a substate(s) for it.

Apprentice Joined: 06 Apr 2004 Posts: 173

nah, this would only be a temp trigger. The reparse stuff and multistate stuff would be a permanent addition to the trigger.

Posted: Sat Mar 28, 2009 8:45 am

So why not create a #TEMP trigger with a priority of 1. Something like

Apprentice Joined: 06 Apr 2004 Posts: 173

that would still run *after* the current triggers in the queue.

Posted: Sat Mar 28, 2009 9:00 pm

Can you explain in more detail exactly why you want that functionality. I'm having a hard time imagine a situation where that would apply that can't be met by current CMUD functionality.

Posted: Sat Mar 28, 2009 10:11 pm

Mmm, I'm really not sure what it is you're after. Can't you just put the commands you want to run after the script... after the script?

#trig {whatever} {list
of
commands

and
then
some
cleanup}

Posted: Sun Mar 29, 2009 1:17 am

have you tried a #WAITFOR within the trigger?

Apprentice Joined: 06 Apr 2004 Posts: 173

My problem is that if I output a #SAY in the middle of a telnet 200 trigger, the ansi gets garbled.

The problem is that any solution offered is going to have to take place *after* the current trigger expires, so that the telnet ansi codes are no longer in dispute. Every solution to the problem involves racing against the other triggers that are about to fire. I want them to fire. I want them to fire quickly. I just want to anticipate their order.

Every solution seems like a hack. The closest solution would be to make a multistate trigger with the reparse or similar options. The problem is, multistatehood is permanant. I can't remove the second state short of disabling the trigger, and having a duplicate trigger do the same job... But what if the second state is contingent on what happens in the first state? Then there are bunches of different triggers, each very specialized, and each almost always disabled.

I want to be able to create a #TEMPSTATE, a temporary multistate trigger. that fires immediately after the current trigger fires. The options might be that it reparses the same text, but maybe not, actually in most cases I think it would just fire. The conditions are already matched using #IF statements in the first trigger.

Posted: Sun Mar 29, 2009 9:04 am

Simply, raise an event and use an event handler. That'll solve your problem. If that seems like a hack, well, it works.

Apprentice Joined: 06 Apr 2004 Posts: 173

Tried it, didn't work the event fires before the telnet trigger ends... I have a solution to my particular problem, I just thought this was a great idea for a feature request.

Posted: Tue Mar 31, 2009 12:37 pm

Well, it's just that it only applies in the specific case that you want to print text to the screen using a telnet trigger. At other times, you don't need this kind of break between sections of your script.