On Tue, 4 Nov 1997, Edward Glamkowski wrote:
->While a lot of people like OLC (not me, though :P ), if you
->add it to stock, then if someone does a lot of re-writing
->of code, especially database code (which some people on
->this list have), it means that much more work to re-do
->the OLC. On the other hand, if you add in OLC after you
->do all the rest of your work, it is less likely you will
->forget about something that needs to be altered to fit your
->changes.
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.
->I would vote that OLC should be maintained separately from
->the stock (as it is now). Plus, it is great coding
->experience =)
Note that I didn't mean, "features added/removed/changed," in stock
CircleMUD, but a--hypothetical--derivitive of Circle released
by...Bob...
->And poof-in saving.
->And equipment position saving (i.e. the autoeq patch)
I think Jeremy's (as-of-yet incomplete) e-text system was/is supposed
to incorperate alias saving, poof-in/out saving, etc.
->No, not everyone wants races, or would want races too
->different from the "standard" races.
We're not necessarily talking about everyone, however. We're talking
about a seperate line derived from CircleMUD. Thus, it'd be quite
acceptable to add features that not *everyone* wanted.
->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. I've just realized how
easy it is to remove titles in bpl12 (easier than it was in bpl11), so
I find my point on removing titles moot, now (they're just as easy to
remove as they are to add, now). 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.
Also, all of the class code will be encapsulated in a (replacement)
class.c file (the old one will be stripped down so severely that the
few remaining functions will find new homes in already existing
files). Classes are too tightly woven into the CircleMUD stock code,
IMHO, and that knitting needs to be either loosened up severely, or
completely removed (I took the latter).
->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...
Uhm, you mean change two lines of code in gain_exp() and
gain_exp_regardless() ?
while (GET_LEVEL(ch) < LVL_IMMORT &&
changed to
while (GET_LEVEL(ch) < LVL_IMMORT-1 &&
in both functions...
->No clans! I have only once added a clan system (to my
->CoW mud), and it didn't have any special meaning, code
->wise - i.e. it was a role-playing thing.
->I don't generally like clans, and don't play on muds where
->they exist (as in, officially hard-coded into the mud,
->although you can't stop social cliques from forming...).
->Clans bad.
->No clans.
A base clan system, based on external files and removable almost
solely by not compiling about two .c files (and removing some function
calls, of course, but not too many [I'm thinking taking things out of
the command list in interpreter.c and a few clan booting functions in
db.c).
->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.
->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...
->It has been tossed around, and the file conclusion is that
->it would take up waaaaaaaaaaaaaaaaay too much disk space :P
Yeah, sure it would...
daniel koepke / dkoepke@california.com
+------------------------------------------------------------+
| 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