Crossfire Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CF: Scripting Language


The way a scripting language such as tcl/perl would interface with
CF server would be have the relevant CF variables/structs available
to the scripts (sort of similar to how enviromental variables are
known and modifiable by the scripting language).  Also, CF could
make various routines (such as add or delete item) accessible as
script functions.  Perl and TCL both provide tools to make it easier
to allow calling some external function or reference external data
(where, in both cases, external means external to the language).

So an embedded script could do most anything.  Further capabilities
would be a matter of making more of CF accessible as script functions.
The trouble with doing your own scripting language to add functionality
comes as you try to get more complex and realize the annoyances of all
the details of a real language.  It is relatively easy to do your own
scripting language to add minor functionality, but then as you want to do
more then you spend more time working on the parser and not so much time
making CF data/functions accessible.  The great advantage of embedding a
real existing language is that you now have (and know you have) a
complete language.  So while the initial embedding stage takes more
effort (since you must learn enough about the language to learn how to
embed it), it does mean all future efforts are purely on making CF
data/functions accessible and you will never again deal with the
parser.

It think it is rather silly to argue against adding a feature since
some newbie might have trouble making it.  I know Perl/tcl both have
configure scripts which will build on most anything and certainly are
easier to build than CF.  If you can't make one of the common scripting
languages then there is no way you will be able to make CF.  I think
people get caught having trouble making with XPM since there is nothing
when downloading CF that hits people on the head saying "make and install
xpm first".  Even I once made CF without XPM and then had to go back and
figure out why.

Hopefully, that passes the "don't quote commercials" test.

							sdw

------------------------------------------------------------

The one known as Riba wrote:
> 
> On Fri, 25 Sep 1998 tvangod@ecst.csuchico.edu wrote:
>> I think tcl is a good candidate for being embedded in Crossfire as the
>> scripting language. It is an extremely straight forward language,
>> easily embedded in c, c++, and java executables, and it is easily
>> extensible.
> 
> I don't like the idea of adding more 'external code' to CF.  If newbies
> have trouble installing the xpm-lib think of having to install tcl...
> If there's tcl-source that you can cut'n'paste into your own programs,
> forget that comment.  
> 
> The scripting language should be _in_ the CF so it can access all data
> structures directly.
> 
> In addition to make the scripting language every creature should be
> attached with an additional structure that contains variables for the
> creatures script.  (That is if we don't want to use one interpreter per
> creature, in which case the variables could be held in the interpreter)
> 
> Doesn't CF already have an extensive parser in it?  It parses all those
> text-based maps and archetypes all the time?  I think the extensions
> should be made by adding functionality there.  Extending msg-field like
> Raphael suggested would be a simple approach.
> 
> Since there have been several mentions of those funny script languages
> like perl/tcl/python/scheme/whatever.  I'd really like a summary on why
> and how should they be used.  Please don't just quote commercials...
> 
> 	- Riba

------------------------------------------------------------