> Whether or not DG scripts should be part of the stock distribution
> is up to the circle developers, but I think - as current developer
> of dg scripts - that if it's included, it should be optional.
>
> The list above (and I believe a previous post to the list) seem
> to suggest that the olc system will be made modular, especially
> concerning scripting languages. I believe this is the way to go.
> Even more so, when we see mails like yours, speaking fondly for
> embedded 'outside' scripting languages like perl, python, lua, etc.
>
> As long as people might want to use another scripting language,
> I believe that's reason enough for not forcing anyone to use
> dg scripts. Let us who like it enjoy it, though :)
Well, I dont know much about embedding perl and different scripting languages
and I agree that perl looks Greek. (since I havent studied it much yet).
But it seems that any scripting tool is going to have function calls at the
same place regardless. For example, the bribe trigger and the give or take
triggers. So why not add these function calls in the appropriate places to the
stock mud and allow the particular script engine to implement the function as
they wish. For the bribe trigger, for example, I suppose you would need the
object given(or money), the receiver, and the giver as arguments in any
language... Kinda like inheritance/overriding, but perhaps with defines.
As for the meat of the particular script (if direction, say blah, end)... Any
script editor is going to need to write that info to a file, so that could be
modularized.(the editor probably doesn't check the syntax)
When the particular script is assigned to a mob/zone/object, etc, it would be
nice to allow multiple scripts for each "object" (mob,object,room, etc) as
opposed to spec procs where it only allows one function. It seems also that
this assigning process could be modularized for most script systems.
For Example in Dg Scripts in a mob file you add:
T <trig number>
somewhere in the mob's file info, but multiple times if you want more than one
script attached.
The mySQL/XML stuff sounds nice in theory, but only if it doesn't require
adding a lot of non-standard packages and/or memory requirements/disk space.
R.M.
--
+---------------------------------------------------------------+
| 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/ |
+---------------------------------------------------------------+