> 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