Carlton sent me a private piece of email asking more about this, but i figured that it was potentially of enough interest to share the basic logic with the entire list. > I was hoping you could point me in some direction to make those > modifications to my MUD. well, the overall description that i gave is essentially how it all works. to be a bit more detailed though: for mobiles and objects, we (VieMud) have a central struct that each object of the same type shares (literally, there's 1 loaded per object vnum, and 1 per mobile vnum). this struct has a variable that lists the maximum number of that thing available. If it is set to '-1', then that means unlimited. the maximum it can be set to (code-wise) is 99, but it's actually an unsigned integer (which means it can be set to ~64k). we used 99 since it was a pretty damned large number anyhow. so, this number is set for objects in the object file (just like the 'A' flag sets affects, we have an 'L' flag for limit). For mobiles, it's done in the zone file that they belong to. now, in the case of mobiles, when we attempt to load them, we just have a routine that looks for (and returns) the number of mobiles of a specific vnum in that zone (and we have another for the entire world -- not applicable in this particular case). if the number already loaded is >= limit, then we don't load them, and the command "fails". (note that the mobiles limit is actually per zone, and not per world -- the struct takes this into account with a linked list.) same idea for objects. in this case, we actually keep two numbers on the fly. the limit, and the number existing. on the initial bootup, we walk through all of the rent files one by one and count up each object that each person has. as a side note, this also lets us know what objects are popular, and which are not. so, now that we've counted all of the rent files, we need to know when new objects are loaded and when objects are removed from the game entirely. this is done in the purge_object() and read_object() routines. essentially, each time we purge an object, its count gets decremented by one, each time we read an object, its count gets incremented by one. now, we had to add a new flag to both of these calls, that tells it that this is a load from (or a save to) a rent file so that it doesn't increment (or decrement) in that case (since we've already counted it in the initial boot phase). Unfortunately, no matter how you do this, you _will_ have to make some changes to your areas, and you will have to make some changes to any new areas that you "poach" from elsewhere. that's not too difficult though, and you should be able to do that as a mud admin. in terms of scanning your rent files, we had to write a new routine that just walked through every single rent file (we keep ours as ascii files, but separate from the player files) in a directory. you'll (obviously) have to do the same. i can't really help you on that one in mud terms, since we rolled our own routines to interface with the directory scanning stuff that C has (mostly because we found that some operating systems that we used to run the mud on didn't support the standard calls). however, for all intents and purposes, we use a 'readdir()' call, and walk through each file in its structure, opening each one and dealing with them on a file by file basis. check out the documentation on that call for details on how it works. a couple of hints though -- avoid '.' and '..' (they're directories), and make sure that the file can be accessed with the 'stat()' function, and is a _regular_ file. that should be enough to set you on the right path without actually giving you code that you can't use. (note: VieMud isn't based on CircleMUD, but CircleMUD has some code in it from VieMud -- and man did that take some converting!) Ae. -- +---------------------------------------------------------------+ | 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/26/03 PDT