short takes 4 bytes of memory what a waste that is.
The reason she used character was listed she wanted a way to not changed the existing structure of the files. She also provided a solution which i think was a good thing she as contributing.
I for one will not attack someone who gives back.
Anyway her idea works.

Davion Kalhen writes:
I don't understand why the heck your going about doing it with a char variable. Thats just silly. It seems rather annoying to get. Rather, just use an int array, that holds 1 or zero. Use short if your concerned about space or something. But if you think about it, an int has the sizeof 4, short 2, char spot is 1. So short isn't much more efficent than using a char, if you want to use arrays. I use a form very similar to this in my near-custom base. Which I'll put up for you guys to hack at. Its no where near snippet form, as I could not tell you how to add this to ROM off hand, or have it replace the old system. This is bit.c extern const struct bit_type common_table[];

struct bit_type
{       char *name;
        char *PrntVal;
        short bit;
}; short bit_lookup(const struct bit_type *bit_table, short max_bit, const char *name )
{       short i;
        for(i = 0; i < max_bit ; i++ )
        {       if(LOWER(name[0]) == LOWER(bit_table[i].name[0])
                && !str_prefix(name, bit_table[i].name ) )
                        return i;
        }
        return -1;
}
short PrntVal_lookup(const struct bit_type *bit_table, short max_bit, const char *name )
{       short i;
        for(i=0;i<max_bit;i++ )
        {       if(!strcasecmp(name, bit_table[i].PrntVal ))
                        return i;
        }
        return -1;
}

char *bit_name(const struct bit_type *bit_table, short bit )
{       return bit_table[bit].name;
}
char *bit_PrntVal(const struct bit_type *bit_table, short bit )
{       return bit_table[bit].PrntVal;
} void load_flags(const struct bit_type *bit_table, FILE *fp, short max_short, short *bit_array )
{       short i, bit;
char *word;

        for(i = 0; i < max_short; i++ )
        {       word = fread_word(fp);
                if( ( bit = PrntVal_lookup(bit_table, max_short, word ) ) == -1 
)
{ logfp(LOG_BUG, "load_flags: invalid bit Prshort Value, \"%s\"\n", word );
                        fread_word(fp);
                        continue;
                }
                bit_array[bit] = fread_number(fp);
        }
return; } void save_flags(const struct bit_type *bit_table, FILE *fp, short max_short, short *bit_array )
{       short i;
        for( i = 0; i < max_short ; i++ )
                fprshortf(fp, "%s %d ", bit_PrntVal(bit_table, i), bit_array[i] 
);
        fprshortf(fp, "\n" );
        return;
}
void clear_bits(short *bArray, short max_bit )
{       short i;
        for( i = 0; i < max_bit ; i++ )
                UNSET_BIT(bArray, i );
        return;
}
const struct bit_type common_table [] =
{       { "Afk",              "Ak",         COMMON_AFK              },
        { NULL,                 NULL,           0                               
}
};
/* END OF BIT.C */ As you see to add more and more, you have to add it to a table, makes things in flat files easier to read. That one is just an example of what you do (Of course, as you get more COMMON_FLAGS for players, you just add to the table. These are the set_bit and all that. You define them in merc.h or whatever you main header is.
#define IS_SET(bArry, bit)      ( ( (bArry[(bit)]) ) )
#define SET_BIT(bArry, bit)             ( ( (bArry[(bit)]) = true ) )
#define UNSET_BIT(bArry, bit )  ( ( (bArry[(bit)]) = false ) )
#define TOGGLE_BIT(bArry, bit ) ( ( (bArry[(bit)]) ? UNSET_BIT((bArry), (bit)) : SET_BIT((bArry), (bit) ) ) )

Now of course, this comes no where near as effecient as stock ROM's standard bit code (using about 4 bytes of info per set of flags, where as this one uses 2 bytes per flag. But when you think about how huge strings can be (If your MSL is 20k too, then.. ya ;) ) I think its really a much needed sacrifice for the amount of flags you get. Of course, if you wanted to devise a multi dementional array, one that stored the set, and the other that stored the bit info, that'd be interesting to see, and probably -very- efficent. Anyways, I hope I didn't forget anything, have fun with this, and for credit *shrug* say my name really loudly and spin around 3 times :) Happy New Years people of the list. Get lubed, screwed and tatood! Davion Ps. Sorry for sending it twice, Mike Barton, but I forgot to send to the list, as aposed to reply to you :)

From: Mike Barton <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [email protected]
Subject: Re: from taka RE: buts and unlimited bit systems
Date: Tue, 30 Dec 2003 14:41:56 -0600
> Ok bit based flags i left the standard long flags and when i ran out of
> room made a flag system like this.
> char aff2[some_number] // obviously the some_number needs a value i am upto
> 12 each byte has 8 bits so eight flags per character or 96 bits minus 1
> since 0 is my terminator bit.
> Here is the concept.
> To add bits i add one to the array. By using the NULL terminator as 0 i do > not have to store all the bits in each place they are used. I only store > those i want turned on. I have examples below. How is this better than the existing unlimited bits systems?

--
ROM mailing list
[email protected]
http://www.rom.org/cgi-bin/mailman/listinfo/rom

_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.m sn.com%2f%3fpage%3dmisc%2fspecialoffers%26pgmarket%3den-ca

--
ROM mailing list
[email protected]
http://www.rom.org/cgi-bin/mailman/listinfo/rom


Reply via email to