[MUD-Dev] Extensibility

[Christopher {siege} OBrien]

On Tue, 2002-05-07 at 06:48, Ben Chambers wrote:
> From: "Ben Chambers" <bjchamb at bellsouth.net>
 
>> Is it possible to use the ability of Java to dynamically load
>> classes to make it easier to add new features to your MUD without
>> recompiling?  I was thinking that instead of having code snippet
>> archives it would be cool if there was some source of expandable
>> Java classes.  You know, if you want this new feature, simply
>> download this .class file and load it into the server using the
>> graphical front end.  Then simply reboot the server (this might
>> not be necessary) and without recompiling or anything you have
>> updated your server.

>> I don't know if this were possible, but if it is I would probably
>> attempt to implement it in my MUD which I am about to start
>> writing any day now :)
 
> Now that I've been looking at this I have an idea.  What if you
> created a hash table of classes that you had loaded from disk.
> These would be your built in functions, which the scripting
> language could then use to create more complex commands.  For
> example you could have a Tell command that uses the interface of a
> Command and is inserted into the hashtable under "tell".  Whenever
> I see the function "tell" called from a script, it looks to the
> hash table to see if it is has one, otherwise it outputs some
> message telling the user that that is impossible, as "tell" is an
> unknown command.

Greetings list.

You've described in part the original fundamentals that led to the
design of my command manager.

The first implementation wasn't so hot (alpha4), the second
implementation (alpha5) made a bit more sense, with commands broken
up into sets and some neat options on how to match commands by
name. The latest revision (re-implementation with class names that
actually make sense) is in the works with the rest of alpha6.

Basically the command execution as a whole works like this:

The command manager contains a number of command lists. Command
lists contain grouped commands. The command manager also contains a
default interpreter (used to parse a string into command name and
arguments).  When a command is called, what generally happens is the
string is parsed (by an interpreter) into a command name and
args. Then, depending on settings of the manager, the commands are
iterated through. when a command is found which matches the criteria
(it allows use by the actor and matches the calling name), the
command is executed, given the actor and the arguments as
parameters.

Plugins may, when initialized, add command lists to the command
manager.  When that plugin is terminated it should remove those
lists. There are *no* commands native to the core code... they must
all be added via a plugin. Different plugins provide different
commands-- for instance, an administrative plugin provides a command
to init, terminate plugins ;)

If you can stumble through that mess of an explanation, I applaud
you.  But it works well, really! There's some interesting code
(well, I think so) in the methods to look up a command... you can
configure commands to be strictly matched, or partially matched
(though an exact match has priority over a near match, even across
multiple command lists), and also to optionally ignore String case.

The javadoc can be had from (and go up a dir or so for src on older
versions).

  http://www.jamud.com/pub/jamud-alpha5/docs/api/
  http://www.jamud.com/pub/current/dist/docs/api/

The current revision (alpha6) src isn't publicly available yet, even
for review other than the javadoc. gimme time though :)

-siege (Chris)

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev