On Mon, 18 Aug 1997, Ron Cole wrote:
> >I don't quite follow. You want docs on adding new prototypes to the
> >indices? I remember a while back there were a lot of ideas discussed
> >which you can probably find in the archives.
>
> That was it, I know I saw some of it before I became a coder on a live mud, but
> I don't recall it as being a comprehensive guide to all the problems involved.
Well we never intended to write a how-to :P THe main points discussed as
I remember were that you could save some memory by using realloc to
increase the prototype and index array size, and reallocating multiple new
slots each time you need more would save time during building sprees.
As for changing from my method of adding all new protos to the end of the
array to keeping them in sequential order, that's a tradeoff of extra time
spent in vnum searches vs extra time spend adjusting the arrays every time
a new prototype is added.
So generally speaking, there's no comprehensive answer. You have to
decide where you need to save time and/or memory, which depends on your
mud. If you've got lots of players, you probably want to minimize lag.
If you've got lots of builders and no players, maybe lag isn't important
but memory usage is.
Your best bet is to decide what your priorities are first. The technical
side of it is very easy with an understanding of realloc and memcpy.
> If I get around to really trying to make our OLC stable, I'll prolly just toss
> out the arrays in favor of a linked list, and get rid of all the problems.
Both methods have their problems. Converting the arrays to simple linked
lists makes binary searches impossible, which increases search time quite
a bit. Hashing the arrays can make up for that, but is it worth the
trouble of converting all the existing code?
One of the things I've done to speed up the existing code was to add a
last_found variable in real_room, real_object, and real_mob that holds the
last found rnum as a one-shot cache. It greatly speeds up worst-case zone
resets.
> Perhaps you might consider making Obuild co-exist better with Oasis. I recall
> seeing a few people here do it manually. If the current project to fix Oasis
> works out, then those who can't decide on a preferred interface, won't have
> to... :-)
The code involved in making them exist isn't much, as far as I know. I
think the only problem is the difference in security, since obuild stores
builder permissions in the zone file, and oasis would overwrite the
permission information. The big drawbacks to combining the two are that
the resulting olc code is huge, and it means double the code each time you
add something to the structures.
What I'm trying to achieve is a new system of olc that addresses the
shortcomings of oasis and obuild, both from the builder's point of view
and the coder's. A lot of the things I'm planning could easily be added
to oasis, but I'm inclined to improve my own olc rather than get involved
in someone else's :) Maybe George will work on that end if we can
distract him from his buffers ;)
Sam
+------------------------------------------------------------+
| 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