Daniel Koepke wrote: > > On Fri, 13 Dec 1996, JTRhone wrote: > > > > *grin* Stumped again! Fancy that...:) > > > Uhm...so I increased the room flags in structs.h from an int to a long, > > > now I can add more I think!:) I thought wrong...cuz apparently it > > > doesn't(it being the mud) doesn't like the new flags...doesn't recognize > > > > On some systems (most pc based I believe), longs are the same length as > > ints, 32 bits.... > A somewhat less than portable method would be gcc's "long long" which > will permit 64 flags on any supporting platforms. Also, there would > be bitfields, too, but that is a much larger project. A fully portable method would be to use an array of unsigned chars, and then define TOGGLE_BIT/SET_BIT/REMOVE_BIT to work with an arbitrary sized array. For example: #define SET_BIT(arr,n) (arr[(n)>>3] |= (1<<((n) & 7))) #define TOGGLE_BIT(arr,n) (arr[(n)>>3] ^= (1<<((n) & 7))) #define REMOVE_BIT(arr,n) (arr[(n)>>3] &= ~(1<<((n) & 7)) Note that this is just as efficient as operating on a single word, if arr and N are constants. However, I really have to ask if that's such a good idea. From what I have seen, the stock circle is extremely wasteful of these flags. For instance, if you want to make a "mage only" weapon, you must define it as !CLERIC !WARRIOR !THIEF. Add new classes later? Then you have to add anti-class flags for each new class (wasting more bits), *and* retroactively modify all your existing weapons. Using a conversion utility *won't work*, because there is no way for the utility to know that when you made an item !CLERIC, you really wanted it to be anti-<any divinely powered class> as opposed to <will work with anyone except clerics>. Adding bitfields carelessly is an easy way to end up with an inflexible database. -- Jack +-----------------------------------------------------------+ | Ensure that you have read the CircleMUD Mailing List FAQ: | | http://cspo.queensu.ca/~fletcher/Circle/list_faq.html | +-----------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/18/00 PST