Register to post in forums, or Log in to your existing account
 

 Related 
Contents
Triggers
  #ACTION
  #ALARM
  #CONDITION
  #FIRE
  #MXPTRIG
  #NOINPUT
  #ONINPUT
  #RAISEEVENT
  #REGEX
  #SENDSB
  #SETPROMPT
  #TEMP
  #TRIGGER
  %alarm
  %state
  Create/Modify Settings
  Introduction to Triggers
  Multistate triggers
  Pattern Matching
  Trigger Tester
  Trigger Types
  Triggers
  Triggers
Command Reference
  #nnn
  #ABORT
  #ACTION
  #ADD
  #ADDITEM
  #ADDKEY
  #AFK
  #ALARM
  #ALIAS
  #ALL
  #BACKUP
  #BEEP
  #BREAK
  #BUTTON
  #C-
  #C+
  #CALL
  #CAPTURE
  #CASE
  #CHARACTER
  #CLASS
  #CLOSE
  #CLR
  #CMD
  #COLOR
  #COM
  #CONDITION
  #CONFIGURE
  #CONNECT
  #CONTINUE
  #CR
  #CW
  #DBCLOSE
  #DBDELETE
  #DBFIRST
  #DBGET
  #DBLOAD
  #DBNEXT
  #DBOFFLINE
  #DBONLINE
  #DBPREV
  #DBPUT
  #DBRESET
  #DBSAVE
  #DDE
  #DEBUG
  #DEBUGFILE
  #DEFAULT
  #DELCLASS
  #DELITEM
  #DELKEY
  #DELNITEM
  #DESCRIBE
  #DIRECTION
  #DISCONNECT
  #DOOR
  #ECHO
  #ECHOPROMPT
  #EDITOR
  #ERASE
  #EVALUATE
  #EVENT
  #EXECUTE
  #EXECWIN
  #EXIT
  #FILE
  #FIND
  #FIRE
  #FORALL
  #FREEZE
  #FTP
  #FUNCTION
  #GAG
  #GAGBLOCK
  #GAGLOG
  #GAGOFF
  #GAGON
  #GAGSPACE
  #GAUGE
  #H-
  #H+
  #HELP
  #HIGHLIGHT
  #HISTLOAD
  #HISTORY
  #HISTSAVE
  #HOST
  #IF
  #IGNORE
  #IMAGE
  #INPUT
  #KEY
  #KILLALL
  #LAUNCH
  #LMAP
  #LOAD
  #LOCAL
  #LOCATION
  #LOG
  #LOOK
  #LOOP
  #LOOPDB
  #LOOPVIEW
  #LUA
  #MAKEROOM
  #MAKEWINDOW
  #MAP
  #MAPQUERY
  #MARK
  #MATH
  #MEDIA
  #MENU
  #MERGE
  #MESSAGE
  #MODULE
  #MOVE
  #MSS
  #MXP
  #MXPTRIG
  #NAME
  #NEW
  #NEWVAR
  #NODEF
  #NODIR
  #NOINPUT
  #NOMAP
  #NOOP
  #NOSAVE
  #OK
  #ONINPUT
  #PATH
  #PATHHIGH
  #PAUSE
  #PCOL
  #PICK
  #PLAY
  #PLUGIN
  #PORTAL
  #PRINT
  #PROMPT
  #PSUB
  #PUEBLO
  #PW
  #QUERY
  #QUEUE
  #RAISEEVENT
  #READ
  #RECALL
  #RECORD
  #REGEX
  #RENAME
  #REPEAT
  #RESET
  #RESUME
  #RESULT
  #RETRACE
  #RETURN
  #SAVE
  #SAY
  #SAYADD
  #SAYPROMPT
  #SCRIPT
  #SCROLL
  #SECTION
  #SEND
  #SENDGMCP
  #SENDPROMPT
  #SENDRAW
  #SENDSB
  #SESSION
  #SET
  #SETPROMPT
  #SHOW
  #SHOWARR
  #SHOWDB
  #SHOWPROMPT
  #SHOWTABLE
  #SIGNAL
  #SLOW
  #SORT
  #SQLCLOSE
  #SQLDB
  #SS
  #STATE
  #STATUS
  #STEP
  #STOP
  #STWIN
  #STYLE
  #SUBSTITUTE
  #SUSPEND
  #SWITCH
  #T-
  #T?
  #T+
  #TAB
  #TAG
  #TELEPORT
  #TEMP
  #TEMPVAR
  #THREAD
  #TIMER
  #TRACK
  #TRIGGER
  #TSET
  #TYPE
  #TZERO
  #UNALIAS
  #UNBUTTON
  #UNCLASS
  #UNDIR
  #UNGAG
  #UNKEY
  #UNEVENT
  #UNLOAD
  #UNLOC
  #UNMENU
  #UNPATH
  #UNPORTAL
  #UNSTYLE
  #UNTAB
  #UNTIL
  #UNTRIGGER
  #UNVAR
  #UPDATE
  #URL
  #VARFUNC
  #VARIABLE
  #VERBATIM
  #VERSION
  #VIEW
  #WAIT
  #WAITFOR
  #WAITSIGNAL
  #WAITTHREAD
  #WALK
  #WHILE
  #WINDOW
  #WITHLOC
  #WIZLIST
  #WRAP
  #WRITE
  #WRITELOG
  #YESNO
Related Links:
  Triggers
  New Commands
  #RAISEEVENT
  Events
  Shortcuts and Tricks
  Introduction to Events
  0: For the Novice
  %packages
#EVENT [[cmud_#EV]] 
EVENT

Syntax: #EV event_name {commands}
Related: #TRIGGER, #RAISEEVENT

An Event is similar to a trigger, but instead of firing when text from the MUD is received, it is fired internally by CMUD, or using the #RAISEEVENT command.

The pre-defined event names are:
OnConnect
fires when connecting to a session
parameters of WindowName HostName and ReconnectFlag are supplied
OnDisconnect
fires when disconnecting from a session
OnExit
fires when closing a session window
OnLoad
fires when a module/window is first loaded (added to v2.12)
OnRoomEnter
fires when entering a room
OnWalkEnd
fires at the end of a speedwalk
OnRoomWalk
fires when speedwalking through a room
OnRoomCreate
fires when a new room is created on the map
OnTickWarning
fires when a tick is about to happen
OnTick
fires when a tick happens

You can create your own events by just specifying your own unique EventName. The #RAISE command can pass arguments to your event, which are accessed via the %1..%99 variables just like with triggers. Named arguments can be used, the same as with Aliases.

RAISE example

#EVENT MyEvent {#SHOW MyEvent: %1}
#RAISE MyEvent "test"
Causes the MyEvent event to fire, which displays "MyEvent: test" to the screen.

 User comments 
Tech: Sun Aug 26, 2007 7:26 pm    

[Edit] Tying together some notes on events that Fang and I wrote with some examples.

The main strength of events is modularity. By creating an onPrompt event, you make it easier for other people (if you distribute your scripts) to create their own event handlers that use your event, or for you to use theirs. Instead of having to modify your trigger to add their commands in (and forcing them to have to make the change every time they update), they can just create their own onPrompt event and use that instead.

You can use this yourself if you use more than one package - events raised in one package will be "seen" from the other package, allowing you to bypass some scoping issues.

Modularity can also be very useful as a time-saving device. My prompt trigger looks like a (very long) list of #if statements that check to see if various systems are active before doing things related to that system. It's regular to see things like
Quote:

#if (@parrying) {}
#if (@autosip) {}
#if (@autoclot) {}
#if (@blocking) {}


and so on. Since this is firing on every prompt, this can get very slow indeed. Instead, I could create an event handler for each of these scripts (the parrying system would have its own handler, as would the sipping, clotting and blocking). Then instead of changing the @parrying variable, I can just enable and disable the event handler. Event handlers are ignored when they're disabled, which is faster than checking a variable every prompt.

And finally, if an event doesn't exist, it fails gracefully. Unlike aliases, where the text is sent to the MUD if the alias doesn't exist or is disabled, events do nothing. This can stop you accidentally sending commands in these situations.

Another example is that you can have a package that gives creates a 3-color health gauge based on the HP variable. Anyone can use this by simply raising an onPrompt (or onHPUpdate event, since you can get HP updates in places other than the prompt) and the package will work. While technically you can still do this triggers updating specific variables, using EVENT is much cleaner.

Yet another example is having an MXP driven status window when in you can click on one of several items and the StatusWindow will be updated accordingly. One approach would be to have the MXP send text, which would detected with an ONINPUT trigger. You can then GAG the text you sent and do the specific processing. A much cleaner and more effective approach would be the have the MXP link raise an event that is then processed. This way you avoid an extra trigger and the gagging of the event and can have other actions triggered from the event as well.
Viewer Comments [1 - Post your comments]

Jump to:  

© 2009 Zugg Software. Hosted by Wolfpaw.net