Re: Suggestions for new derivitive (not "patch levels"by anymeans)

From: Edward Glamkowski (EGlamkowski@MATHEMATICA-MPR.COM)
Date: 11/04/97

>Personally, my view on OLC is that the underlying functions for the
>system should be completely independant of the interface.  I was
>thinking of writing the base functions to perform string setting, etc.
>but not the interface for such a thing.

that would be neat :)
I think I could go for that.  I could probably have other
uses besides.
>->And then I did another MUD based on Council of Wyrms,
>->where the PC's were dragons.  I don't think I'd want to
>->do that one again using an existing stock race code, and
>->it would be extremely annoying to remove any such existing
>It depends, truthfully, upon how it is coded.

Fair enough, but it would take a lot of good planning and
smart coding to have races be a sort of compile-time
option, although it would be really neat :)
Assuming, of course, you are not content to just put a:

#ifdef USE_RACES
  [race specific code]

everywhere race code should go.  It would work, but would
be messy and clutter up the code.  I suspect there is a
better way, but don't have time to think about it at the

>On the other hand, I've been working
>on extracting classes into being external from the code; this should
>make it possible to add/remove classes, or even run a classless run
>without doing much more than maintaining a few xxxx.class files.

If you can successfully do this, than the races thing will
probably be similar.

>->This would be neat.  Also don't let players automatically
>->advance to 31 with enough experience (or has this already
>->been taken out?).  Death Gate's code does this, but I
>->suspect it is a lot of work...

Um, I didn't really write that, did I?
I knew it was simple.  In fact, the above doesn't even
make sense, because DGC doesn't have immortal levels in
the traditional sense.
I have no clue what I intended to say :P
>->In any event, everybody has a different idea on what makes
>->for a good clan system.
>Well, obviously, just because something is part of the (hypothetical)
>release of the derivitive, doesn't mean someone can't change it.

The point was that if we have different ideas on what is
a "good" clan system, they might require very different
types of coding, depending on what exactly we want to
But then, this is BobMUD, not CircleMUD, so I guess this
is not something to make a big deal out of ;)
In any event, I suspect many people would be happy with
any form of pre-existing clan code.
>->If they are in the code, you don't necessarily have to
>->use them, and they don't hurt anything by being there
>->The only problem with this is that you wouldn't want to
>->add it to the stock unless it was completely debugged...
>I wouldn't touch mobprogs with a 10 foot pole.  The idea is to improve
>(in the opinion of some people) Circle, not to reduce it to an
>inefficient mass of string compares...

Check out Eric Green's mob scripting stuff - it's written
a lot better and safer than mobprogs.

     | Ensure that you have read the CircleMUD Mailing List FAQ:  |
     | |

This archive was generated by hypermail 2b30 : 12/08/00 PST