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

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD Beta Forum
Larkin
Wizard


Joined: 25 Mar 2003
Posts: 1113
Location: USA

PostPosted: Wed Jun 21, 2006 3:53 pm   

Trigger syntax problems/questions
 
In toying with CMUD, I'm trying to experiment with a couple new features and also see what works and what doesn't. I thought I'd try out the trigger priority and "stop further processing" options. I've noticed several oddities in trying to create my triggers, and I wonder if anyone has thoughts on these.

First, I manually created four triggers in the settings editor. Pattern = "fire", Commands = "#say {one}" (or two, three, four), Priority = "1" (or 2, 3, 4). These triggers don't fire because of the little bug that you have to save them and reload the settings.

Okay, I delete those and start over. I tried the second time to create them from the command line. I first used the same command (#TRIGGER {fire} {#say {one}}) for each and found that my original trigger was overwritten, so I had only one trigger instead of four. I attributed this to the automatic setting of trigger ID to the pattern when no ID was specified. I can accept that. That seems like reasonable behavior.

I then tried the following script, which also replaced the trigger and left me with only the fourth one remaining. This, to me, doesn't make sense. I would expect to see four distinct triggers with unique ID's and the same pattern. (The setting of the ID actually does work, even though the little reference window for #TRIGGER doesn't show ID as being a possible parameter. It doesn't work for #REGEX, however. Replacing #TRIGGER in the following script with #REGEX causes the CMUD parser to crash.)

Code:
#TRIGGER "fire1" {fire} {#say {one}}
#TRIGGER "fire2" {fire} {#say {two}}
#TRIGGER "fire3" {fire} {#say {three}}
#TRIGGER "fire4" {fire} {#say {four}}


Other oddities that I noticed in this little experiment:

1. Where does one specify the trigger options when making a trigger from the command line now? I tried a test with #TRIGGER {fire} {#say {fire one}} and got an infinite loop (thanks for the 'disable triggers' button!) and so tried to add the "" {notrig} code to the end of it. The parser doesn't like that, so I'm wondering if it's broken in this regard now. (What are the abbreviations for the new "stop further processing" and priority options, anyway?)

2. I tried the drop down box next to the pattern, where you can edit the pattern in a larger edit field. I entered text there, hit enter, it updated the pattern, but hitting the Save changes button made it revert to the previous text.

3. Changing trigger options on the Trigger Options tab and hitting Cancel does not revert to previous options (or at least the check boxes are not visually updated because closing the settings editor and re-opening it shows the correct options again).

4. I was viewing Trigger Options for a trigger and then created a new trigger, where it was still on the Trigger Options tab. It's more intuitive to me that it should switch back to the Trigger Definition tab and switch focus to the pattern field when you create a new trigger (or any similar setting that has tabs like this).
Reply with quote
edb6377
Magician


Joined: 29 Nov 2005
Posts: 482

PostPosted: Wed Jun 21, 2006 7:11 pm   
 
I was able to reproduce all of these. Another odd quirk however.

Code:

#TRIGGER "fire1" {fire} {#say {one}} {triggertest} {disable}
#TRIGGER "fire2" {fire} {#say {two}} {triggertest} {disable}
#TRIGGER "fire3" {fire} {#say {three}} {triggertest} {disable}
#TRIGGER "fire4" {fire} {#say {four}} {triggertest} {disable|notrig}


Will create all 4 just as you want it to. Course they are disabled. I can only assume it allows creation of triggers with the same pattern because it sees no ACTIVE trigger.

Sometimes if you test by changing disable to enable and dont remove your old triggers you can end up with 2 of a trigger due to the options being different i.e. notrig. Tested with #4 removed notrig and it happened again

As for the commands for stopping and priority. Priority is automatically set based on the order you input the triggers in series of 10. If its deleted and recreated it moves to the back of the bus. so for your example they would all be right at 10 20 30 40 deleted try again 50 60 70 80 lol.

I have tried many option commands and havent found the right one yet.
noprocess|stop|noparse|stopprocess so on and so forth. tried about 20 thus far no go with finding the stop or priority one. Going to try priority = in a bit.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Wed Jul 05, 2006 7:01 pm   
 
There isn't a command line option to control the "stop processing" option yet. I'll probably use the "stop" option when it is added.

The rest of your items have been added to the bug list.
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD Beta Forum 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