Re: [Idea?] AFF flags and expansion

From: Jason Yarber (JasonYarber@hotmail.com)
Date: 06/03/02


> I personally think it's harder to use an AFF2_, AFF3_ approach.
> Anywhere you check for AFF_ you have to check all the other AFFx_
> vectors as well.  Unless you know the flag you want is on a certain
> vector and you can reference that vector directly.  But then you lose
> transperency.  It's best (i.e. simplest, especially for newbies) to
> have a uniform method of dealing with arbitrary bits.

I will second that, however, I also state that if you use a self defining
method of
seperating your aff flags, you won't have any problems.  Take these for
instance:

define ROOM_ANTI_****  (1 << #)
define ROOM_ONLY_**** (1 << #)
define ROOM_NORM_**** (1 << #)

What's being done here is all similar flags are being grouped together.
This makes
it easier to use the multi bit-type approach.  Also, if you add in the 128
bit vector patch to
this approach, you'll be able to use a lot more flags.  There are millions
of ways that
you could possibly group the flags together, for instance any flags that
have to do
with what race a character is, goes into one group, and class flags into
another.
By using the above method, and the 128 bit patch(?) you could have a maximum
of
384 flags, and not have any problems with implementation.

> >However, my total project consists of only needing 53 different AFF
> >flags, and I thought it was probably an easier way to go.

To be honest, thinking that you will only need 53 aff flags is like saying
you'll only need
$28 to get you through the month.  Somewhere down the line, you may add more
races
or classes, at your players request, and will therefore need more flags to
accompany them.
I'd highly suggest implementing a method to allow the most flags you can
get, now, so you won't
have to do it later.

As for using the multi bit-type, I haven't started to implement it into my
CircleFullInstall.zip
project just yet.  However, I do intend upon doing it, as well as the 128
bit patch.  Here is a hint
of what you might have to do.  Notice, I'm just giving a general suggestion
of how to go about it, and
not actually giving you step by step instructions.  There may be more or
less that needs to be done as well.

First off, you'll want to divide up the current flags according to groups, I
suggest one of my earlier
suggestions for that.  You'll want to redo thier definitions in structs.h.

In utils.h, you'll want to recreate the macros accordingly.  As in, copy,
paste, and rename as needed.
Then, simply use grep, or find(for windows) and search for every instance of
each macro, and change them
to what they need to be.

In db.c you'll want to do the necessary coding to add the new bit fields to
their proper files.

After all that, your gonna have to edit all the world files by hand, and
change them accordingly.

Make sure you have all that done, then try compiling, and running your mud.

NOTICE: After doing all the code changes, your mud WILL NOT run untill all
the world files have
been edited properly.

That's just my 25¢ worth.

--
   +---------------------------------------------------------------+
   | FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
   | Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
   | Newbie List:  http://groups.yahoo.com/group/circle-newbies/   |
   +---------------------------------------------------------------+



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