> > 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.
You'd still want to distribute the source, of course, but I'm sure
you realize how many people out there just want to plug and chug... I
don't actually like suffering people who make code changes and cannot code
- this would be a way around it.
>
> > 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)
Yeah, I didn't think it'd be such a simple thing, or easily
possible without having a seperate virtual state machine, which really ...
we don't need.
> > 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 -
> >fine.
>
> 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.
Well, the sort of people that would use binary commands/spec proc
modules in the first place are not the sort of people that would go around
altering those functions responsible for loading said binary modules.
I think it's moot; you'd want to have the option to include the
source code with the module anyway. It'd be wierd not to.
> > 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.
It'd be nice too, to have plug-and-play areas, but frankly, that's
asking a bit much, unless we standardize some conceptions we have about
how intimately the world and an area are linked.
Things like setting mobs to a specific difficulty level, instead
of certain specific stats - a table specific to each mud would be
responsible for making the initial rude adjustments (ninja monkeys(1)
anyone?). Relaxing the requirements of world file readers or preparing
realistic default values, so you don't have to change the file format to
work in your heavily modified(2) mud. Gah. Perhaps even using a tagged
format that one could use an xml reader on, worse comes to worse.
PjD
1 - a ninja monkey is a random mob who's difficulty is 'approprate' to the
level of the character who encounters him. Usually their 'strength' is
equivilent to 60-80% of the PC.
2 - or should I say "heavily modified" and "with over 3 billion levels!".
Modifying the world file format at all is very likely to make it
incompatible with stock zones, regardless of your definition of 'heavy'.
--
+---------------------------------------------------------------+
| FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
| Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
| Newbie List: http://groups.yahoo.com/group/circle-newbies/ |
+---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 06/25/03 PDT