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 fine). > 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 - >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. > 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. -me -- +---------------------------------------------------------------+ | 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