Zugg Software :: View topic

Newbie Joined: 25 Dec 2006 Posts: 4

Hello, everyone. I've been reading about CMUD and considering purchasing it and switching over from ZMUD. Obviously, performance and some cool new features are a strong selling point. Another is the addition of the #EVENT function that everyone is raving about!

I've read the help files regarding this function, and every thread that includes it, but I still don't understand its benefit. If anyone has a few minutes to spare, could you perhaps give me an example of what you could do with an #EVENT function that couldn't be accomplished by using a trigger to call aliases? I'm sure there's more to this that I'm not yet grasping. Thanks in advance for the help!

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

From what I read of them, they look to me like status bars for functions and aliases. Different bits of code in separate containers all with the same label.

Posted: Tue Dec 26, 2006 6:45 pm

You are right.. much of what you can do with them you can accomplish with triggers and aliases if you will never use packages etc. Beyond that when you start abstracting more, then you see their power.

For example suppose you have a really cool set up to play music and color text when you enter a fight. You could set up the triggers on your system simply enough. But what if you're friend sees it and wants it? yes you can customize it for him too.. but what if 100 other people on different MUDs want it. You can continue to customize or put it in a package that responds to a particular event called FIGHTING. Then everyone can use your package as long as they raise the event. it's contrived yes I know.

More abstractly it allows you to code packages of functionality that respond to certain events, whether it's leveling, dying, receiving a tell, killing a monster, completing a quest or whatever you wish without necessarily knowing the exact string test or condition that causes the event (since this can change depending on MUD, user, session and some cases character class or race.) The full power comes when you create or use packages designed for broader distribution.

I hope that helps.

Newbie Joined: 25 Dec 2006 Posts: 4

I appreciate your help, that cleared it up a bit. Let me see if I am understanding this properly.

I have several packages that I want to become active when I am attacked. So I can set up an event like "attacked" or something, and then set up triggers that raise that event if I am attacked. So the attacked event, when raised, will contain aliases that activate those packages? Or does each package contain that same event?

Posted: Tue Dec 26, 2006 7:32 pm

I think of events as aliases, but you can have more than one of them with the same name and ALL of them fire when you set them off (via #RaiseEvent or a default event). In my system, for example, there are MANY things that run off the prompt, with variables (@HealingOn and so on) that're running on every single prompt. This causes tons of slowdown.

By having my prompt trigger raise an OnPrompt event and having all those prompt scripts in events with that name, I can simply disable the class with the event inside when I'm not using it - this is much faster than running the scripts each time (and I can still control the order they fire in with priority numbers). It also means that you can have much more modular scripts - for example, if you're distributing a health potion sipper and a combat stance-setting script in separate packages that both need the prompt, they can both use the OnPrompt event and the user has no problems with multiple triggers on the same pattern.

Newbie Joined: 25 Dec 2006 Posts: 4

Thank you very much for the replies! Now that I finally understand them, I'd have to agree with everyone that they are quite powerful.

Steve

Beginner Joined: 23 Apr 2006 Posts: 11

hell YEAH these things are powerful! after reading this thread I went and added a #RAISE onPrompt to my (now only!) prompt trigger which I can now use to trigger things like turning off a class when the prompt shows up. For example I'm working a curing system for myself for Achaea, there's a skill called Diagnose which will show you everything you're afflicted with. The class folder with all the triggers for diagnose messages is always disabled until I use the command, at which point the class gets #T+'d until the prompt shows up again. Used to be I had a trigger inside that class folder which fired on the prompt but now I just use the onPrompt event to #T- the class Mr. Green

. My own thanks to all of you for explaining this great new command.

Wizard Joined: 17 Jun 2006 Posts: 1201

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

I've been converting a large set of scripts from my old zMUD text format to the new CMUD text format and I have to say that I'm liking the use of #EVENT to speed things up and make it so much more flexible. I still see a few side effects that need to be worked out before it's a fully working script engine, but I do like the ideas in CMUD and the cool things I'm now able to do that I couldn't with zMUD.

Part of the danger in converting old code to a new system, however, is trying to shoehorn things together and ending up with poorly pieced together bits of old code running in a new engine. The best way is to really sit down and think of the algorithms rather than the code and try to improve on your implementation of that algorithm. For example, instead of taking a string list of commands I wanted to execute and looping on a #FORALL, I find it simpler to use %expandlist(@list, ";") and then call #EXEC just once. (Something I probably could have done in zMUD, but just one thing I redid in thinking about all the conversion to CMUD.)

An event-specific example:
My old prompt trigger code in zMUD is all executed when the trigger fires. I have flags that are evaluated to see if a specific alias should be called to check on my curing and what-not, but that flag still has to be evaluated as true or false every single prompt. In my new CMUD code, instead of toggling the flag, I enable/disable the class folder with the OnPrompt event that checks that alias for curing (or what-not). This means that only the code that should be evaluated on the prompt will be and I don't need the unnecessary "should I do this?" checks any more.

Now, if only there were an easy way to programmatically set the priority values for all my triggers, events, etc...