>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
>->code.
>
>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]
#endif
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
moment.
>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?
*boggle*
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
accomplish.
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
>->unused.
>->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: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/08/00 PST