noun The specification of how to interpret a command in
MUDDL. MUDDL actions
are the equivalent of MUDDLE functions,
save that all actions are directly usable by players whereas
functions are executed indirectly through vocabulary ties. The
only actions that can't be used directly are demon actions,
which are meant to be time-delays but are often chained to the
end of actions so a command can do more.
MUDDL's action
definitions are impressively hairy, consisting of a number of
templates which commands are matched against in turn until one
catches. The basic template format is:
<vb> <sp>? <obj> <ins> <fn> <par> <success> <fail> <global>? <demon>?
<vb> is the verb, optionally followed by the name of a
special function <sp> which is to be handled first when a
template matches a command. Anything complex has to be coded as
a <sp>, eg. '.get', '.drop', '.quit'. Following on is an object
<obj> (or 'null' if the <vb> is intransitive) then another
object <ins> (or 'null'). Next is a normal function <fn>, which
does more simple things than <sp> and can be used to change the
way objects look or appear. Such functions act either on <par>
or on <obj> and/or <ins>; some <fn>s are doubled up for extra
functionality, so whereas 'inc null' means 'increment the
property of the <obj>', 'destroyinc second' means 'destroy the
<obj> and increment the property of the <ins>'. <fn>s return
either success or failure, and the text bearing the appropriate
number is printed. If <global> is present, that text is sent to
all players. If <demon> is present, that
demon is invoked.
The above is just the standard model of an action - some
templates have eg. null <obj> but named <ins>, or room names as
<success>, or numeric parameters to <fn> as <success> and the
real value of <success> in <fail>! Whether an object or class
name is used is also meaningful in strange ways. The best way
to figure out how to add a new command is to look up the MUDDL
for something similar and use an adaptation of that. The binder
is implemented as a part of the command lookup process, so
there is flexibility in what can be bound to what, but the
nature of the binding is restricted to certain stylised forms
(objects that are here, objects that are carried, objects that
are either; global searches for objects are handled in the code
of the <sp>s). Some <fn>s can affect binding, and even
determine the matching of templates against commands.
For comparison with MUDDLE, here are the relatively
straightforward definitions of the actions that implement the
'fix brand in sundial' command:
fix torch time ifprop sundial 0 386
fix torch time ifprop null 0 387
fix torch time destroydec sundial 388 0
The first of these lines says that if the sundial is in
state 0 (it starts in state 1, by the way) then print message
386 ("It's already got a brand in it, birdbrain."). The second
line says that if the brand is in state 0 (its 'aflame'
property), print message 387 ("You can't put a lit brand in
there or you'll burn your hand!"). If the third line is
reached, it means neither of the two previous lines applied, so
the brand should immediately be destroyed, and the state of the
sundial should be decremented (which will move it from 1 to 0,
ie. the first line would catch it next time). Message 388 is
then printed ("The brand fixes solidly into the sundial, in
fact so solidly that you won't be able to take it out. It looks
like the sundial will work now."), and the action is complete.
Note that in MUDDL, 'fix' is a different command to 'drop',
whereas MUDDLE has the oomph to combine them. See function.