Zugg Software :: View topic

Apprentice Joined: 06 Apr 2004 Posts: 173

I have a question about #EVENTs in cmud. are these processed EXACLTY like aliases?
or is there any waiting.

For example:
Suppose that text comes in from the MUD.
suppose 4 triggers fire, from the same line of text, and all raise the same event.
will the event be called 4 times, or will it only be called once.

What I would like... is an event that would wait till a text brick was completely recieved from the mud before firing.
or maybe have a #RAISE option that makes it have a lazy execution

Here are some possibilities?

(1) fires when the last of a current text brick is received, OR
(2) fires at the end of one full cycle thru the trigger processing loop, etc.
(3) fires immediately (like an alias would)
(4) fires when the current trigger exits.

At any rate, I'm guessing that it's currently set up like (3) but If that could be clarified, it'd be great.

Apprentice Joined: 06 Apr 2004 Posts: 173

Here is another example:
You have received balance on all limbs. <--------fires an onbalance
H:34256 M:34 E:434 W:455 B:100% [eb] <-------fires an onbalance, and a onequilibrium

this is all within the same text brick from the mud, but each line is in a seperate trigger loop, so it would process the first line, raise an event, then process the second line and raise the same event twice?

If this is the case, I'm guessing theres no clear advantage to using #EVENT over using #ALIAS?
[ASSUMING that onbalance fires twice]

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

Events are like aliases in that they fire when they are called, but unlike aliases in a few other ways.

If you have two classes that you use to preform separate tasks but those tasks both fire on the same trigger, for example, without events you must either create two identical triggers one in each class, one trigger outside both classes, or use the trigger from within one of the classes and place the actions you wish to occur on that trigger firing in the respective trigger.

WITH events you can have an external class somewhere that has triggers within it that raises Events when that trigger is fired. Now you do not have to always go back and add the alias or the extra code to the proper trigger. You can instead raise the event and have an event in your respective classes. The event for each class now has different code within it that ONLY pertains to that class. If you disable that class, or delete it, then you do not lose code you needed for something else.

A good example for this is the prompt. I trigger a lot of things on the prompt and I used to have prompt triggers all over the place. Sometimes I would have a prompt trigger that had code from many different classes within it as well. Now I raise a prompt event and my various classes do not need prompt triggers.

Another way events are different than aliases is that you have to #raise an event and you can call an alias even by accident. Have you ever accidentally typed an alias that you had forgotten about?
If I am writing a bit of code that I never expect to call manually by typing it in at the command line I write an event instead.

I'm sure I have forgotten a thing or two but this is a start.

Posted: Thu May 10, 2007 4:16 am

Another benefit is coding for distributable packages.

Say I wrote a packages that does something based on the Balance Regained Event, but with some gee whiz features with my package. Say I had a package that does a full body display. i won't have to code to your specific triggers or codes I can just code to the EVENT.

Another advantage is coding to specific System events.

One way I use it is for when I get ambushed I raise the event. I could then have other packages trigger off of that same event.