Events are quite similar to aliases. At the simplest level, events need a name and a script, just like aliases. Unlike aliases, events aren't triggered by typing their name on the command line or as a command in a script.
Events are raised with the #RAISEEVENT command. CMUD also includes some Predefined Events that it will raise when certain things occur.
Events Settings Editor
<image pending>
Events can be viewed by clicking the Settings button on the main toolbar and then clicking the Show Events filter button on the far left of the Package Editor. To edit an event, just click its name and the details will be displayed in the right half of the window. To create a new event, click the New button at the top of the Editor and choose New Event.
The Editing Events topic has more info on using the Package editor to edit events.
The #EVENT command
You can also use the #EVENT to define an event from the CMUD command line. The syntax is similar to TINTIN scripting commands:
#EVENT name {commands}
defines a new event. Events can have arguments just like aliases can, and they're accessed in exactly the same way:
#EVENT OnKill {kill %1}
Events can also have named arguments:
#EVENT OnKill($target) {kill $target}
%params and %-1-%-99 can also be used just like they can be in aliases.
The #RAISE command
You can use custom events to improve the working of your scripts. Events raised with the #RAISE command can be given parameters:
#RAISE OnKill lion
raises the event defined above and causes the script to send kill lion to the MUD. You can also use the #RAISE command to raise any of the predefined events in CMUD, though you should obviously be careful when doing so.
Some ideas for using events
Events are useful in a number of situations.
- For sequences of commands that you want to use many times in your scripts but don't want to type out every time. It was common in zMUD to use aliases for this kind of shortcut, but this is inconvenient when you might accidentally type an alias on the command line. Events can't be accidentally activated in this way.
- For communicating across packages. While aliases should have unique names, events aren't so limited. Instead of having many prompt triggers in different packages that all do different things, you could have a single prompt trigger that raises an OnPrompt event and many events in different packages that're named OnPrompt. This is not only much faster than having many triggers, but is also much easier to edit if you change your prompt or something.
- For improving the use of "modular" scripts. Oftentimes people have many different scripts within the same trigger - prompt triggers are usually a good example. People can have many, many scripts running on prompts such as auto-curing, managing skills, and many more. In zMUD it was common to have a variable such as @AutoCure that had one value when curing was enabled and another when curing was disabled. The prompt trigger would then check each variable using #if and execute the script accordingly. This can be improved in CMUD by raising an OnPrompt event and then enabling or disabling the event objects themselves. By eliminating all the #if commands and variable references, the script should be faster.
Introduction to Aliases