Zugg Software :: View topic

Novice Joined: 21 Mar 2009 Posts: 35

I have 2 triggers, with the same name. They are in separate classes of their own. Now here's something a bit annoying. If I do #T+ <trigname>, it only does the trigger that has the highest priority, regardless if either class is disabled.

Should it not ignore everything in the disabled class?

Posted: Mon Apr 20, 2009 11:17 pm

If by "name" you mean "id", then you simply need to give your triggers unique IDs. You may be able to use "\classname\id", but giving your triggers different IDs is the simplest solution.

If you mean "pattern" when you say "name", then give your triggers unique IDs and use the IDs instead.

Novice Joined: 21 Mar 2009 Posts: 35

Sorry, yes I did mean ID.

I'm aware I can give them unique ID's except, I have multiple characters that use the same session simple because they all use similar triggers. So if I write something for one character, I should just be able to disable the appropriate class....

Alas as I asked though, shouldn't disabling the parent class disable anything being able to reference it too?

Posted: Tue Apr 21, 2009 1:28 am

The #T+ and #T- commands ignore whether or not a trigger is currently enabled. If #T+ ignored triggers that were disabled, then there wouldn't be any way to re-enable them!

So as Fang mentioned, you can use the full /ClassName/ID syntax to specify the exact trigger that you want to enable. But in general, ID values are meant to be unique.

Novice Joined: 21 Mar 2009 Posts: 35

It doesn't make sense though to be able to enable and disable triggers in a disabled class.... Normally you'd expect the parent to supersede all children. Alas I suppose I'll have to figure out a work around then.

Posted: Tue Apr 21, 2009 5:46 pm

We've had this discussion in the past before. But the #T+ and #T- commands have always ignored the class enable/disable setting and needs to stay that way for zMUD compatibility. So this isn't going to change.

Disabling the parent *does* cause the children to get disabled. But just not for the #T+ and #T- commands.

Novice Joined: 21 Mar 2009 Posts: 35

ahh.. good to know. Is there a plan to drop zMUD support? I find a that most of the scripts that I've seen for zMUD don't work with cMUD without a lot of alteration, if not total rewrite

Posted: Tue Apr 21, 2009 10:13 pm

No, I will never drop zMUD compatibility support. Some things work differently in CMUD, but honestly, "well written" scripts in zMUD require little or no changes. The problem with zMUD was that the parser was not very strict and it allowed you to do many things that were not really supported. Lots of bad syntax, etc. Those kind of things require lots of changes. But it depends upon the complexity of scripts.

As I said, I'm using my exact 6-year-old zMUD scripts for most of the MUDs that I play in CMUD. Yes, then need to be rewritten to be faster or to take advantage of new CMUD features...but they still work. The zScript testing script that I use to test the parser in CMUD before each release is a superset of the exact same testing script that I used for zMUD. So while I understand that you are needing to rewrite your own zMUD scripts, not everybody does. I want to make CMUD as easy to switch to as possible for zMUD users and every time I make a major change to CMUD I need to study it very carefully to see if the benefit is worth the change and the compatibility issues that it might cause.

Since most of CMUD requires the ID values of settings to be unique (it was the original purpose of ID settings), the change that you are suggesting just isn't in line with how the rest of CMUD handles IDs and could have a lot of un-intentioned side effects.