Re: 128bitvector

From: Tony Robbins (
Date: 03/21/01

Quoting Jason Beeland <jbeeland@BELLSOUTH.NET>:
> understated.  Correct me if i'm wrong (please), but you
> would also have to alter the way mobs/objs/etc were read
> in from their world files, as well as change how olc writes
> said files, and also change how pfiles are written out (if
> you are using ascii pfiles).  And that still doesn't
> address the state of the current world files. They would
> have to go through a conversion process.

Yes, yes, you're right.  Although, those things aren't
as big as they seem, either.

What I _meant_ to say was that with bitfields (more so
than bitvectors), you can hide the cosmetic changes
inside structs.h and utils.h.  Why?  Because if you're
J. Random CircleMUD-Coder, you're using the stock
and/or stock-like macros.  Bitfields lends itself
directly to being used in the same manner as the
current (single) bitvectors in stock.

As far as loading/saving, yes, there are changes.  But
no, they are not as cataclysmic as it seems!  It is not
difficult to modify the source code to read the files,
and check which format it's following.  Your zone
saving function (i.e., in Oasis) needs only to save in
the new format.  I did this a number of times in the
process of altering zone files on a previous
incarnation of my MUD.

So, that cuts out the conversion process, because
you'll do it, essentially, in the game, over time.
Also, since CircleMUD currently (I believe) saves
bitvectors as strings (1011 -> abd), that change to
bitfields is not tremendously terrible.

Anyway, what I was alluding to, was that if you look at
the 128 bitvectors patch on the CircleMUD site (and the
snippet it came from, by ________ Niese-Petersen),
you'll see that it requires changes throughout the
code, with every macro reference and flag alteration.
I'd rather only have to modify the save/load mechanism
and get the benefits of bitfields than be required to
alter everything in an elaborate kludge.

Bitfields aren't so bad.


   | FAQ: |
   | Archives: |

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