Zugg Software :: View topic

Apprentice Joined: 26 Apr 2007 Posts: 113

Okay. I'm just going to post about this because it's a huge source of frustration for me on more than one count.

Basically, I've been building up a Cmud system for Aetolia and what's really getting me is inconsistent behaviour such as triggers that once worked now not working at all and stuff like that.

So I just have to ask: Is anyone else having similar problems? This sort of thing is making me regret my purchase, on the other hand when it DOES work I'm happy with my choice. I know it isn't a problem in the code I've been using. (I've hardly tampered with it from when it did work and now- When it doesn't.)

So yeah. Hoping I'm not alone in this. :(

Posted: Tue Jun 12, 2007 2:51 pm

There are all sorts of things that could be causing triggers and other settings to stop working as you expect them to. If you describe exactly what problems you're getting, I'm sure someone will be able to tell you what you're doing wrong and suggest a workaround. Either way, when you encounter something like this, it's wise to report it so that Zugg knows that something's wrong :)

Apprentice Joined: 26 Apr 2007 Posts: 113

Well, that's the trick. I -would- report it if I had a clue what was wrong with it. As I have said, it was working at one point, a few seconds later, it wasn't.

The most recent is:

#TRIGGER ^You may apply another salve to yourself.$ {#CO high,green;salvebal=0;salveheal}

The trigger doesn't fire period, where it did not too long ago. (Not even the coloring works.)

Bearing in mind I've not touched anything in the code recently related to that trigger in question, I can't see what is wrong with it.

All in all, I've tried a couple of variations of the same pattern to no avail.

Posted: Tue Jun 12, 2007 3:55 pm

Try going to the trigger and clicking both the Compiled Pattern and Compiled Code tabs in CMUD. This forces CMUD to recompile the code it has for these components.

Your current example looks fine, but it's always a good idea to use Ctrl-K to check syntax errors, or to run the Compatibility Report to see if CMUD thinks anything is wrong. Bear in mind that the report is not 100% exact and thus can give false negatives.

Posted: Tue Jun 12, 2007 3:55 pm

You *must* enclose the pattern of the trigger in {} characters. So it should be:

#TRIGGER {^You may apply another salve to yourself.$} {#CO high,green;salvebal=0;salveheal}

I just tried this on my copy and it worked fine. If it still isn't working for you, check the Trigger Options by clicking the More button at the bottom of the trigger script to see if one of your options got changed somehow.

You can also try removing the $ at the end of the pattern in case the MUD is sending extra spaces before the newline.

Also, be sure to read the Changes for zMUD Users section of the help file. There are several syntax changes in CMUD. While CMUD is very compatible with zMUD, it is not 100% compatible, so you might need to tweak some of your scripts.

Apprentice Joined: 26 Apr 2007 Posts: 113

I made the trigger using the GUI, so I'm doubtful it's the lack of {}. I just wrote my previous example up quickly.

I tried removing both ^ and $ to see if that was making a difference, but no luck there.

I'll try recompiling and see what that does for me. Thanks for the help!

Wizard Joined: 15 Jan 2002 Posts: 1644 Location: USA

Also make sure the trigger is enabled. Double clicking on a setting will toggle enable/disable and I have been frustrated by this more then once wondering why my trigger wasn't working. There should be a more visual clue to disabled settings.

Magician Joined: 25 Oct 2000 Posts: 461 Location: USA

Hmm... disabled settings are always greyed out on my screen, which has been enough of a visual clue for me - maybe this is affected by your theme. Maybe a very small 'no parking' style icon in front of disabled triggers to make it more obvious?

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

No parking? I'm thinking maybe the disabled settings should have the same icon logic Zugg used for the trigger/parsing buttons in the lower right corner that disables everything all at once. I think the icons are of similar size to those images, so the red X overlaying the standard settings icon should be easily visible.

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

I, too, have had problems with inconsistency. Events that sometimes refuse to be raised, variables that create themselves in other folders without setting any new default module/class, triggers that will not fire, etc. I can't report these problems because I can't reproduce them reliably. That's the part that makes it really frustrating.

My current frustration (with inconsistencies) is importing modules from scripts and the settings are going to the wrong modules despite having the #MODULE commands defined correctly before and after each block. Sometimes half of a new module goes to an already created module. Sometimes all of it goes to another module.

I agree with the disabled settings needing a better visual cue, too. I had a trigger that wasn't firing as I had created it because of the bug with the local variable capture in the trigger pattern. The trigger didn't compile, so it disabled itself quietly, and I had no idea this was the default behavior. It used to complain and spit out the code, which at least gave me a hint that I'd done something wrong. When I went to look at the trigger, it looked okay to me (compiled and everything) and I couldn't tell it was disabled without looking at the context menu and seeing it was unchecked.

Posted: Wed Jun 13, 2007 4:09 pm

Umm, triggers don't disable themselves if they don't compile. At least not here. If the Enabled option in the context menu was really unchecked, then it must have been disabled by accidentally double-clicking, or via a #T- command somewhere. Triggers should never get disabled "by themselves".

You should start another topic on the problem with importing modules (unless it's already in another thread that I've missed). If you are using the GUI to import a module, then you shouldn't need the #MODULE command at all.

It's difficult to change the icon when something is disabled, because this icon is just a representation of the settings record type (trigger, alias, etc) and this doesn't change when it's disabled. I *do* have complete control over the font/color of the item in the tree, so maybe using something like a strikeout font would be better.

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

I started a thread on the #MODULE problem about a week ago, actually.

My trigger was disabled without me clicking on it, using #T-, or anything such as that. I don't know if it was a fluke or a compiler thing or what, but I know I didn't do it. I would submit it as a bug report, except that it's just elusive enough that I can't reliably reproduce it. If I figure it out, I'll definitely send it in.

Posted: Wed Jun 13, 2007 8:19 pm

I've had triggers disable on me but I figured out what was causing it in my case.

Triggers were capturing lines to another window. If the window was closed the next time the trigger fired it would pop up with a compile error and then disable.

Really an annoying feature if you are using the same package for multiple different characters. I've had to add to my autolog to make sure all default windows I need are in existence.

Wizard Joined: 15 Jan 2002 Posts: 1644 Location: USA

Sorry for the slight hijacking about the enabled/disabled settings, yes a strikeout would be nice more visual clue! for my eyesight its hard to tell apart some color changes :p

Posted: Thu Jun 14, 2007 5:05 pm

Llwethen: thanks for the info on how I might be able to reproduce this. I'll add it to the bug list and see if I can get it to fail here.

Larkin: I must have missed the thread that you mentioned, so I have replied to it so that we can continue the discussion of the #MODULE problem over there.

Nexela: I'll add strikeout to the next version to see how other people like it.

Apprentice Joined: 06 Apr 2004 Posts: 173

yeah, I was having the triggers disable themselves too, but couldn't reproduce it as well... I posted on this but never did a follow up because I couldn't find what caused it.

This is kinda a strange request, but maybe to not have the triggers disable with a mere double click?

I tend to double click everything... windows force of habit... In zmud you would have to right click and then select it from a menu... I like that method. usually when I'm disabling triggers it's not on a double-clicking whim. It's usually in a #T+/- or some other method. When I do it manually it's because there's a unusual reason.

Right clicking is too easy? hehe.

Posted: Mon Jun 18, 2007 10:29 pm

I think zMUD allowed double-clicking to enable/disable too, didn't it? If zMUD didn't do it, then I can certainly remove that "feature" from CMUD. But it's in CMUD because I thought zMUD did it that way.

You'd be amazed by the number of people who don't know (or don't remember) to right-click on stuff in Windows to get a context popup menu.

Wizard Joined: 03 Mar 2001 Posts: 1127 Location: London

I don't remember it being in zMUD. It's the double-click on a class having two actions at the same time (expand/collapse and enable/disable) that's really annoying for me though. If I want to look inside a class chances are I'm not going to want to disable that class at the same time.
I'd class the "feature" as a quirk of CMUD and zMUD and put it into the "odd things to remove" category

Apprentice Joined: 06 Apr 2004 Posts: 173

I had to check to make sure... no in zmud single-click and double-click have the same effect.

Posted: Mon Jun 18, 2007 11:49 pm

Thanks for confirming this for me...I'll add it to the list to remove from CMUD then. It's funny that zMUD is so complex, that even I can't remember how it works sometimes Wink