Re: Go keyword

From: Daniel A. Koepke (
Date: 06/05/99

On Sat, 5 Jun 1999, Drew Johnston wrote:

> Hey. Im havin some trouble with a new cool command im tryin to write. It is a
> go command so when a player is in a room and say there is an alley mentioned
> in the room description, the player can type "go alley" and the command will
> take him to the alley.

I would actually recommend just extending exit functionality to permit
this, since there's a great deal more to it than just copying the
setup_dir() function.  For instance, what if you want doors (gates, etc.)
so that one cannot 'go' into an alley?  Thus, make some dummy exit values
numbered after DOWN, like EXTDIR1, ..., EXTDIRn where 'n' is the maximum
number of 'go' exits per one room that you want.  These directions are
special because there is no associated command with them.  You'll need
some special handling in a few other places once you bump of NUM_OF_DIRS,
but that's relatively trivial, if somewhat tedious.

> the setup_go function is basically the same as the setup_dir, except
> instead of all the variables from the world file being stored in the
> room_direction_data structure, I made a new room_go_data structure
> with basically the same content (just changin the variable names) and
> stored them there.

Two things here.  First, if the structures have the same variable types,
then there is no reason to have another structure at all.  Structures,
unlike classes, are never bound to any functionality.  That is, just
because room_direction_data was created for directional exits and is used
for that reason, doesn't mean that you can't use it for keyword exits.  So
long as it has the necessary data members, you can use it for whatever you

Second, you have perhaps omitted one of the most important steps.
Directional exits are "fixed" after they are loaded.  That is, CircleMUD
scans through all the exits and changes them to real numbers.  This is
worth doing at start-up because, while it adds load time, it'd be
inefficient to store the virtual number and do lookups on demand.  If you
do not take my suggestion and just extend directional exit functionality,
then you'll either have to do on demand real number lookups or renumber
the keyword exits on boot.  See renum_world() in db.c.

> int find_go_num_of_arg(arg)

You have to provide a type for your argument, otherwise the compiler will
default to int.  This isn't JavaScript.  If you can't figure it out (and
you should be able to), you want a char pointer ("char *").

>   [snip]
> }

Ugh.  Loops are your friend.  Unrolling loops isn't necessary in this case
and generally handled at compile-time these days.

> int perform_go(struct char_data *ch, int go_num, int need_specials_check)
> {
>   room_rnum was_in;
>   struct follow_type *k, *next;
>   if(!*arg) {
>     send_to_char("Where do you want to go?", ch);
>     return(FALSE);
>   }
>   if (find_go_num_of_arg(*arg) == NOWHERE) {

No, no, no.  Unless you're planning on passing one character (which
would mean that your entire find_go_num_of_arg() function is completely
wrong), you want to get rid of the unary operator directly preceeding

>   }
>   else if (ch == NULL || gnum < 0 || gnum >= NUM_OF_GO || FIGHTING(ch))

gnum?  Where'd that come from?  You probably want to put "int gnum;" up at
the top and then assign it a value when you call find_go_num_of_arg() up
above like:

  if ((gnum = find_go_num_of_arg(arg)) == NOWHERE) {

>     return (0);

Wise man say if you return TRUE for true, you return FALSE for false.
Consistency is not always necessary (e.g., this case), but it's always[1]
a good idea.

>     char_to_room(ch, world[was_in].dir_option[dir]->to_room);

Here is where the fact that you haven't renumbered the to_room values
comes into play.  And wait, you probably don't want dir_option[],
either.  That's the directional exit one, not the one you created.


     | Ensure that you have read the CircleMUD Mailing List FAQ:  |
     |  |

This archive was generated by hypermail 2b30 : 12/15/00 PST