Re: Even more dynamic spec procs?

From: Mike Stilson (
Date: 09/10/02

On Sun, Sep 08, 2002 at 01:36:07AM -0500, Patrick Dughi wrote:
>        I remember a while back when someone submitted a patch to allow
>dynamic setting of spec procs via OLC controls, which was fairly useful,
>in fact.  Perhaps it'd be a nice time to add an update to that, and use
>dll's/shared object files to allow for a pluggable module system?

Actually there's also a snippet (something like dynupdate if memory
serves me) to allow dynamically adding cmds to the mud, too.  It's a
seriously invasive patch which I couldn't use when I stumbled across it,
so I implemented it in a different way (basically just adding another
cmd list, and figuring everything out in command_interpreter() so I
didn't have to change variables everywhere else.

What I did with the idea you're talking about was to make a library of
spec procs that I had checked for crash-worthiness, then parse the
output of ar to give a list of useable spec_procs.  Just being careful
about the names made it simple to parse them neatly (as you mention,
with a standard naming convention... ie naming it "_mob_thief" or
"_obj_teleport" (you get the idea)).

>        Actually, spec procs were the first thing I thought of, but then I
>realized that other things; skills, spells, etc, all could be distributed
>in binary modules in the same fashion as world files.

Ew.  Me no see source, me no use.

>command/skill/spell and give it a wide distribution; all you'd have to do
>is pop a file in a directory, and perhaps run an update command from the
>mud (or send a signal, or have it simply check for new/deleted entries on
>a timed pulse).

stat the file, store it in a static buffer, parse it.  when that
function's called again, stat it again, if different re-parse.  A simple
little shell script can handle adding entries to libspecproc whenever
you want to.  Commands, I hacked in yet another option to reload.  (Did
them at two separate times, figured I try both ways out, both work

>        What'd I'm curious about though, is there any sort of saftey net
>associated with so's/DLL's?  The only reason I'd be scared to add things
>in this modular form would be that someone else wrote them, so if they
>fail, I want to have my mud keep going.

Talking about running the dlopen'ed routines in some protected memory
block?  MAYBE with some bizarre coding, trapping segv, figuring out that
it was in that routine, unloading it (which might not be possible) and
somehow marking it to not be reloadable?  (Kinda like insmod in some way
or other, but trying to emulate that is a whole different story from
dlopen'ing them)

>        Really though, that's a minor concern.  As long as the source code
>accompanied it, which it might have to, inorder to be relinked against the
>header files if you made interesting changes, you'd be - eventually -

I don't really see a way it could be handed out binary-only, since you
can't count on people not modifying the way they're called.

>        Anyway, just mostly opening up the topic to discussion.  Until I
>finish, oh, a mountain of projects for work, which haven't decreased in
>number or need for the last, oh, 18 months or so, I don't have the time to
>actually _do_ it, but I do have the time to talk about it.

It is a cool idea.  Surprisingly easy to put in.  I've often thought of
making the mud LOTS more modular... actually, patterning it after the
kernel to allow dynamically loading, auto-unloading of some unused
modules (think of something like "dload quest" and it finds the "quest"
entry in a module list, checks dependencies, loads up any other modules
it requires.  Quest goes on.  Quest ends.  It's all removed
automatically after some period of unused time.


   | FAQ: |
   | Archives: |
   | Newbie List:   |

This archive was generated by hypermail 2b30 : 06/25/03 PDT