Re: Adding Keywords

From: Brian (borlick@MINES.EDU)
Date: 12/22/02

Phil wrote:
> I'm using Circle 3.1, and I'd like to be able to use keywords with
> players. What file(s) should I start looking into to accomplish this?
> - Phil

        All name matching ultimately happens in the function isname() in
handler.c.  isname(), in turn, is called by all of the get_char_* and
get_obj_* functions which all scan ch->  ch-> in
turn is the value used in the GET_PC_NAME() macro in utils.h.  Further,
that macro is used in GET_NAME() in utils.h.  Since GET_NAME() is used
throughout the code in various ways, and is rarely directly
referenced, you'd probably be best served by rewriting GET_NAME(), and
then reviewing every place in the code that GET_NAME() is used to see if
it remains appropriate.
        Presently is used to contain the single 'keyword'
for a PC -- her actual name.  For an NPC, contains the list
of space-separated keywords.  For a PC, player.short_descr is always set
to NULL, but oddly it is still freed if non-NULL in free_char().
For an NPC, player.short_descr contains the real name such as 'a small
dog' or 'Anshar'.
        So what you'll likely want to do is change your GET_NAME() or
change several of the calls to GET_NAME() to reference the PC's
short_descr.  The easiest fashion would likely be to make
be the same for PCs and NPCs: a space-separated list of keywords.  Then
short_descr would be the proper name which would be used for such things
as object file name lookup, title when writing on the boards, name when
sending mail, and so on.  Manually checking each call to GET_NAME()
obviously be the hardest part of this.  Finally, assuming the additional
keywords are derived from the character's permanent stats, such as race
sex, all you should have to modify from there are init_char() and
store_to_char() to initialize short_descr appropriately with a strdup().
(Since PCs' short_descr is already freed properly, that should do it.)
        If your keywords are determined in a more dynamic fashion, you
now have an issue, especially with binary pfiles.  With binary files,
you will be breaking pfile compatibility which requires either writing a
conversion utility or having a pwipe.  Binary files also mean that you
need to have a max number of keywords so that you can have a constant
sized buffer in the player file to store the short_descr.  This means
adding a small bit of code to char_to_store() and store_to_char().  With
ASCII pfiles, all you would still have to add the reading and writing of
this new short_descr, similar to char_to_store() and store_to_char()
modifications needed for binary files.

        Did I leave anything out?  I hope not.

   | FAQ: |
   | Archives: |
   | Newbie List:   |

This archive was generated by hypermail 2b30 : 06/25/03 PDT