Re: CircleMUD's Future (was: Re: Player's position)

From: Daniel A. Koepke (
Date: 01/21/00

On Fri, 21 Jan 2000, Chris Gilbert wrote:

> One thing I'm presently looking up is to take the editors and work out
> a generic class that all the editors derive from.  By the use of
> virtual functions

...or function pointers in a non-C++ frame-work...

> the addition of a new editor could be greatly eased.  you just add in
> the new editor, no hacking of interpreter.c oasis.c etc, you just add
> the editor c file and add the info to a struct somewhere.

I've done something _like_ this outside of the CircleMUD framework.  It's
not very cleanly implemented in my qServer ("q" standing for "quick",
which is a judgement of the amount of time spent writing it, not its
actual speed) and ANSI C -- I guess gcc 2.95 is further along with C99
support, but until I upgrade from egcs 2.91.66, I'll just use good ol'
ANSI C -- but it works.  Basically, it's a series of input shells that get
assigned to the user.  The shells can be dynamically linked or static
code compiled directly into it.  There are four shell functions,

    void xxx_init (connection_t *cn);
    void xxx_prompt (connection_t *cn);
    void xxx_shell (connection_t *cn, const char *input);
    void xxx_deinit (connection_t *cn);

The connection_t object has a 'shellData' void pointer on it for
shell-specific data if the specific shell needs it.  A static-linked shell
is registered in the shStaticsRegister() function; dynamic-linked shells

    dllType_t myType = DLL_SHELL;
    char *myName = "foobar";

    void myInit (connection_t *);
    void myPrompt (connection_t *);
    void myShell (connection_t *, const char *);
    void myDeinit (connection_t *);

and is registered with the shell when it's loaded up and myType is

> I'm even thinking of working out a way to load in shared objects that
> contain new commands, these can be added and removed on the fly :)

I've also done this (as can be seen, above, since the framework provides
it), demoed to a handful of people along with auto-recognition of terminal
types.  Again, not in a CircleMUD framework, but easy enough to
adapt.  I've been going through and looking at a lot of my old code; I
might even have a CircleMUD version of it from a year or so ago.

> I'd think most ppl would prefer C++, these days the compilers are
> getting better, g++ 2.95.2 is pretty good (it can manage to compile
> Unreal Tournement up)

I rather like ANSI C and, even more so, C99.  Mind you, I've never been a
big fan of C++, I think there's quite a bit wrong with the language which
are better handled in other object oriented languages.  It's really a
matter of design and maybe purpose.  I dislike the static nature of C++
for object oriented programming, something which languages like Objective
C address in a semi-elegant manner.  I don't think static, very strong
typing, which is what C++ is moving more and more towards, is particularly
suitable to the dynamic nature of most objects.  C++'s strong typing is
what has given us "templates", which are syntically ugly and _increase_
complexity in programs.  I think languages which provide generic list and
vector semantics, such as Python, Perl, and Lisp are much better.  At the
same time, I refuse to give any praise to Perl for it being a write-only
language ill-suited for most of the tasks its used for (it's great for
some things, but I'll never understand why someone would want to write
much of anything in it); and functional languages like Lisp and Scheme are
annoying because (a) all those () and backquotes are confusing, and (b)
RPN ... blegh.  Python...hmm...I might just like it.  Of course, I must
admit a bias for any language with clean syntax and dynamic binding.
Which is part of the reason why I think Objective-C is peachy (but not
great, since it uses C's syntax and I don't think it works, here).

> One of the nicest things I've done is get rid of rnums, I use an index
> class and overide the [] operator.  It's so much nicer :)  (those
> wondering I took the idea and code from the source of death gates mud)

Global namespaces are very, very stupid and cause many, many problems.
This is obvious: just look at all the problems we have with generic_find()
and get_obj_vis() and the necessity of dot notation for imm commands, etc.
Ugly, ugly, ugly.  If we can agree on that, then I think we're one step
closer to the conclusion that a global ID space for *INHERENTLY*
structured data is just as thoroughly idiotic.  Consider that items,
rooms, and mobiles are, by their nature, organized into zones and yet we
use a global name- and ID- space for them, with a design kludge in the
IDspace for organizational purposes (that is, (entity->zoneNumber * 100)
is the first vnum for entities in that zone).  This is ugly and silly.

> My aim is to tidy up a lot of the code, and then release it out to see
> what ppl think of it, but that'll probably be a few months off on my
> own. (and at the moment it's a mess of ideas)

Shrug.  Release now, even if it doesn't work.  You might actually get
help in reworking the really ugly parts.  As soon I actually have
something to show, I'll release it.  But I don't think anyone is
interested in a bunch of echo servers implemented with different IO event
models and threading -- even if they say they really, really are, I won't
believe 'em. ;)


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

This archive was generated by hypermail 2b30 : 04/10/01 PDT