> > Has anyone set it up so eq limits check the player obj files in
> > addition to just what's in the game at the moment of the eq load?
>
> I was thinking about that and decided that scaning all player object
files
> when loading an item is too slow. Especially if you have 1+ mb
playerbase.
>
> I found better solution:
> Create an array "byte objects[total_objs_in_game]". On each succesful
> obj_load increment corresponding entry in array. When obj decayed or
> destroyed, decrement it. And add checks for current item amount in places
> where items should load.
> And of course save this array to disk when need to.
> If your MUD have 200 zones (items from 0 to 20000) the obj array will
> take only 20kb of memory. And no slowdowns during gameplay.
> Just load it once when MUD is started.
>
> I'm going to implement item limitation the way I described above in my
> MUD in a few days, currently I'm working on bugs in slot spell
> system. :)
----------
Just browsing through the e-mail here, and I think I have an even better
solution...
Now...., stored by the MUD are 2 arrays..., one of all the objects that are
currently loaded, and one of all the object prototypes, correct?
Now couldn't one just add another int to the array of prototypes (or the
index array, one of those too) and increment it? You could have
read_object() which makes objects from the prototypes increment, and check
the number so far..., all the checks you were planning before..., pretty
much the same, but without creating a new array.
------------------------------------------------------
Rob Baumstark: shirak@connect.ab.ca
cst0656@nait.ab.ca
Forsaken Realms: telnet://drewl.v-wave.com:4000
------------------------------------------------------
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/08/00 PST