Re: Max # in game

From: Alex (
Date: 05/28/03

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


   | FAQ: |
   | Archives: |
   | Newbie List:   |

This archive was generated by hypermail 2b30 : 06/26/03 PDT