.DT
add_command_conversion
$MUDNAME$ Creator Help
add_command_conversion
.SH Name
.SI 5
Taffyd's Guide to Converting from add_action()
.EI
.SH Syntax
.SI 5
It varies. See the text.
.EI
.SH Description
.SP 5 5
Quick and Easy(TM) add_action removal
Having seen the multitude of files that have got add_actions in them, I
thought that the following 'upgrade guide' might be of some use if people are
having troubles with it.
The first thing to do is to look for the add_action, usually in the init()
routine. It might look something like this (although usually priority is
ommitted):
.EP
add_action("do_lick", "lick", 100);
.SP 5 5
In order to convert this into an add_command, you need to have a look through
the do_lick function and see exactly how it processes the arguments.
Here's a "typical" add_action implementation:
.EP
int do_lick(string str) {
string victim, type;
object who;
if (sscanf(str, "%s %s", victim, type) != 2) {
notify_fail("Syntax: lick <person> <type>");
return 0;
}
who = find_living(victim);
/* Extra junk done to who. */
return 1;
}
.SP 5 5
There are two parameters here, one is a string that is converted into a
living, and the other one is just a string.
Thus this can simply be converted into an add_command with the following
line:
.EP
add_command("lick", "<indirect:distant-living'person'> <string'type'>",
(: do_lick($1[0], $4[1]) :));
.SP 5 5
The function pointer at the end of the add_command() is used to override the
normal function paramaters (object *indirect_obs, string dir_match, string
indir_match, mixed *args, string pattern), and makes a function much simpler.
Note that if you use the function pointer, you must have a function prototype
preceeding the pointer... at the top of the file is a good place.
Using add_command is great because it means that you don't have sscanf or
find_living etc to process the arguments, this is all done for you. It also
means that there is a standard method for handling actions, in case something
is drastically changed or removed in a later driver release. (ie... no
add_action :P)
The implementation for our new add_command could simply be as follows:
.EP
int do_lick(object who, string type) {
add_succeeded_mess("$N lick$s $I " + type + ".\n", ({ who }));
return 1;
} /* do_lick() */
.SP 5 5
add_succeeded_mess() is another advantage to using add_command(), as it allows
you to use handy little symbols such as $N and $D, and often means you can
combine 2 or 3 tell_room/tell_object's into one line.
Using add_command() means that your function can be used with the 'syntax'
command, meaning that you don't have to manually display a syntax message when
the command fails. add_failed_mess() superceeds notify_fail() for returning
failure messages, so it's probably a good idea to use this.
I've used the add_command simulefuns here, which greatly reduce typing. They
can only be used in non-living objects, if you are going to use add_command in
a living object then you need to write it out in full like:
.EP
this_player()->add_command("lick", this_object(), "<pattern>",
(: function :));
.SP 5 5
The same applies to add_succeeded_mess() and add_failed_mess().
.EP
.SH For more info:
.SP 5 5
I'm usually happy to answer questions regarding add_command (it excites me
:P)
Taffyd, is actually waiting for lunch time at work so he can actually log on.
.EP
.SH See Also
.SI 5
add_command, add_action
.EI
