Re: ascii pfiles ideas

From: Sammy (
Date: 01/16/01

On Mon, 15 Jan 2001 11:00:10 -0800, Brandon Bennett wrote:

>Here are some ideas for the update on Sammys Ascii Playerfiles:
> * Move the load_char() save_char() to pfdb.c or pfiles.c
>        This way you don't have to poke though all of db.c just to
>        add a varible to your pfiles

I think this is a good idea.  It would also make handpatching much
more straightforward.

Does anyone have any objections to this?

> * Give each player it's own directory
>        This may be overkill but we can add player objects and player
>        aliases to the same directory.  To delete a play would be as
>        simple as system(rmdir) (I know there is a better way so don't
>        whine about that)

I think some time in the future I'll move aliases back into the pfiles
as they were in 2.0b.  That would save a lot of inodes and make
maintenence a little eaiser.

If it's easier player deletion you want, that is already take care of
in the next release.  You can have it now if you replace your
remove_player() function in db.c with this one:

void remove_player(int pfilepos)
  char file_name[128];

  unlink(file_name); /* remove pfile */

  if((get_filename(player_table[pfilepos].name, file_name,
        unlink(file_name); /* remove rent file */

  if((get_filename(player_table[pfilepos].name, file_name,
        unlink(file_name); /* remove alias file */

  destroy_mail(player_table[pfilepos].id); /* remove player's mail */

  /* this will remove cool stuff in the future */
  /*if((get_filename(player_table[pfilepos].name, file_name,
        unlink(file_name);*/ /* remove alias file */

  /* Unlink any other player-owned files here if you have them  */

  sprintf(buf, "PCLEAN: %s Lev: %d Last: %s",
        player_table[pfilepos].name, player_table[pfilepos].level,
  player_table[pfilepos].name[0] = '\0';

>        Also You can add wizfiles for immortal specific varibles that
>        need to be saved.  Or a olc pref's file in the same directory
>        The olc pref file could contain zone permissions.

I'm not sure I understand why you would want to move data out of the
pfiles and into seperate files.  If you have immortal-only data, you
don't need to put it in mortal pfiles.  As an example of this,
currently save_char() and load_char() assume all immortals have 100%
in all skills, -1 thirst/hunger/drunk, and 25's in the basic six
attributes.  If you have immortal-only data, you can apply the same
principle in reverse.

> * Redo player structs
>        If you are going to do it right totaly redo the player structs in
>        structs.h.  Even without ascii pfiles this could get a good reworkin.
>        I belive there was a snippit on redoing the structs in structs.h

I'll probably leave that part up to Jeremy and George.  While I agree
that this should be done,  they may have a better idea of how it
should be reorganized.

What I will do, though, is to go through my code and make sure I've
used the GET_* macros as much as possible.  That way the structures
can be changed all you want without having to modify any of the ascii
pfile code.

> * Add a modifed XAP objects to the patch
>        Yet again overkill?  Probally.  I have done this before you remove all
>        the if (!xap) shit and just do the normal xap saving scheme. Also remove
>        all the toggle and conversion fuctions.  This cleans up XAP objects quite
>        well indeed.

I've only briefly looked at xapobjs a long time ago when I was
considering trying to release my version of ascii object files.  I
seem to remember deciding that I liked his version better.  Ditto for
ascii board files.  I've never actually used either, though.  I think
if circle is going in the direction of ascii data files, then we might
as well go whole hog.

>As far as documentation just keep it stupid because their is a large group
>using or wanting to use the ascii pfile patch.  What do you expect, It's
>trendy :P.

I'm going for a mixture of simple and detailed in the future.  The
quick-start guides will be as short and simple as I can make them,
while the real documentaion will be a very large user's guide I'm
working on.  I'll provide an outline sometime soon.

>And good work so far with all your patches sam.

Thanks for the suggestions,

   | FAQ: |
   | Archives: |

This archive was generated by hypermail 2b30 : 12/03/01 PST