Zugg Software :: View topic - [2.33] Bug? Triggers sometimes not being created in the right classes

Apprentice Joined: 24 Jul 2008 Posts: 109

Sometimes when I run an alias, it randomly will not create a trigger in the proper class, and instead doesn't put it in a class at all. The trigger it creates outside the class seems random; sometimes it is one trigger and not another, and the next time it will be a completely different trigger, next time it might be two triggers instead of one, etc. Sometimes it does run properly and puts the triggers in the right classes, but it's not reliable.

This alias, for example, is within the class it tries to create the triggers in, in case it matters. (universal/generic_scripts/vocals)

Wizard Joined: 17 Jun 2006 Posts: 1201

Nattie have you considered using a database variable for your song types?

If you do, then instead of 32 #if statements you could just make it this:

Apprentice Joined: 24 Jul 2008 Posts: 109

The database is a good idea, thank you!

I need the while loop because it goes through and tests each time. If I don't hum it with the "slightest hint of difficulty" it means I need to try something harder or easier, depending on the messaging it gets back. So it goes through and tests until it finds the hardest "slightest hint of difficulty" hum I can do. Once it hits the one I fumble on, it stops the loop, subtracts one from the difficulty so I go back to the one before it (the hardest one I want to do) and then it needs the second set of #IFs to realign the difficulty with the appropriate word.

But still, the classes thing is buggy. The script itself works fine, does exactly what I want even without the database and everything. It always works. It just randomly doesn't create the trigger in an appropriate class. :-/

Wizard Joined: 17 Jun 2006 Posts: 1201

Okay. Regardless, using the database would make your life a lot easier.

Another thing I am wondering is why you are creating and destroying triggers? Have you thought about just enabling and disabling them? It would also be a big improvement.

Apprentice Joined: 24 Jul 2008 Posts: 109

Well, haha, the answer to that is because I only learned about how to enable/disable them the day before yesterday. ^^; I just started using CMUD about a week ago, so I've kept running back to the manual to figure out what to do... #UNTRIGGER stood out, but #T- didn't. I went through and read all the command things one by one the other day, so that was enlightening. I'm trying to do the same with the functions and such as well, so I know what's available to me. So I should probably go through and change the untriggers to #T-s.

Just to be sure, though... I have a few scripts where I have the trigger pattern do one thing, then delete it and create and new one with the same pattern that does something different. Basically, depending on when something happens, I don't want it to do the first thing and instead want it to do the second thing, and vice versa. If I give the triggers names, and then #T- them by name, that should work, right? It won't think I'm trying to disable and enable a class, or it won't try to create a class with the trigger's name to disable? Or in that circumstance, do I need to actually #TRIGGER and #UNTRIGGER?

Thanks a bunch for your help, I feel like I've learned a lot from you today. :-)

Wizard Joined: 17 Jun 2006 Posts: 1201

Apprentice Joined: 24 Jul 2008 Posts: 109

Thank you! :-) I'm going to try out both of those things; I need to look at the script again to be sure I can make them conditional properly, but I think I probably can.

Wizard Joined: 17 Jun 2006 Posts: 1201

An even EASIER way to handle those triggers would be to place all of them in a subclass of Vocals class. So lets say you call the class folder VocalTrigs or whatever.

Then all you would have to do to disable them would be:

#TRIGGER {^You finish humming} {#T- VocalTrigs}

and to enable them:

#TRIGGER {^You start to hum} {#T+ VocalTrigs}

That's probably not the trigger line you use but you get the point.

Edit: Just make sure the trigger or alias to turn that class folder on isn't inside the class folder. :-P

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Creating and destroying settings is quite slow. Turning them of and on is very fast, as is setting a variable (especially if the variable uses a default value) for use with #IF within the triggers. It is definitely better for you to learn to control your scripts with #T+, #T-, and #IFs.

It is possible there is a bug in creating and deleteing triggers, but I couldn't find it while playing with your scripts.

Apprentice Joined: 24 Jul 2008 Posts: 109

Okay, I finally got a chance to mess with CMUD some more today, and now I'm just having a problem where #T- doesn't always disable triggers inside a class. :(

Here are my #T+s and #T-s:

Posted: Mon Jul 28, 2008 6:49 pm

It is because of the ~ character in your pattern. The #TRIGGER command parses the trigger pattern a bit differently from the #T+/- commands (because they are designed to use *names* instead of patterns). When you put a ~ in a trigger pattern, it is passed verbatim to the #TRIGGER command (as you can see if you view your trigger pattern in the settings editor).

But in the #T+/- commands (and other commands that accept a string name in addition to a pattern), the ~ character is absorbed by the command, preventing the next character in the string from being parsed. So if you want a literal ~ in your string, you need to use ~~. So, in your example above, the correct command would be:

#T- {Mechanical Lore:%s%d %d.%d~~% mind lock} ranger

This is just something you'll need to remember if you are using patterns that contain ~ and refuse to use names. Also, any trigger that has a pattern longer than 64 characters or so probably also won't work unless you use a name. This is because the database index that is used to "lookup" a trigger by the pattern is limited to 64 characters in length. So if you have 2 triggers that have the first 64 characters the same, CMUD won't be able to distinguish between them and you'll need to give them names to access them via #T+/-.

Apprentice Joined: 24 Jul 2008 Posts: 109

I'm a bit confused... I put the ~ there not because there is actually a tilde in the pattern, but because I'm trying to escape the %. Do I not need to escape the % character?

In case I'm not being clear, this is the kind of text from the game that I'm trying to trigger off of:
Mechanical Lore: 29 28.91% mind lock

Thank you for the information about the 64 characters!

Posted: Mon Jul 28, 2008 9:42 pm

You need the ~% in the trigger pattern because % is normally a wildcard character in patterns (like the %w wildcard). So the ~ character "escapes" the character after it, telling the trigger pattern that it should match the % character from the MUD instead of using it as a wildcard.

When you are using #T+/#T- (and any other command that takes a *string* value for the name of a trigger), you need to create a string that exactly matches your trigger pattern. When using a string value, the ~ escapes the character after it. So if you just do this:

#T- {Mechanical Lore:%s%d %d.%d~% mind lock} ranger

then you are telling CMUD to look for the trigger with the pattern of:

Mechanical Lore:%s%d %d.%d% mind lock

But that doesn't match your trigger pattern. Your trigger pattern has the ~ in it before the % character. So, you need to use:

#T- {Mechanical Lore:%s%d %d.%d~~% mind lock} ranger

which tells CMUD to look for the trigger with a pattern of:

#T- {Mechanical Lore:%s%d %d.%d~% mind lock} ranger

Another way to think about this...the commands that take a STRING value for the trigger name (#T+/-,#UNTRIG, etc) execute the ~ character immediately. Whereas the #TRIGGER command doesn't execute the ~ until it matches the line of text from the MUD against the trigger pattern.

Apprentice Joined: 24 Jul 2008 Posts: 109

Ohhh, thank you! I get it now. :-)

To keep things simple I just went ahead and named my triggers that have an escape character in them, because they're always that type of trigger and the names are easy for me to remember. Things have been working much better since I named anything with a ~ or longer than 64 characters. Strange little errors no longer pop up. Thank you so much!