Fwd: Re: [CF-Devel] Crossfire Scripting language

[Mark Wedel]

>
     
      And true again. The problem with writing our own scripting language is
     
     >
     
      development time (as I said before). But if you are ready to write one, I'm
     
     >
     
      ready to help you.
     
     
 Development time is always hard to estimate, but my personal thought is that
writing our own should not be very hard, because it does not need to be a very
complicated language.

 What is basically needed in our script language:
1) If/else/endif constructs
2) Ability to set variables (probably a small subset)
3) Ability to check variables in the if statements.  A simplification of the
script could be that only variables can be checked in the if statements, and not
function calls or the like.  so in other words:

item=@find_item(cloak)
if ($item == 1 ) then
  @say("than you very much")
endif

 While

 if (@find_item(cloak)) then
...

 is not valid.

 ie, the grammer can be kept very simple.

 If we write our own script langague, I would expect most of the work to be done
in our callbacks (which are in native c) - in the case above, the @find_item and
@say, with the script being very simple language.

 If we write our own, I'm really not that concerned with having to thread the
scripting nearly to the extent I am if we use an external one, which may do more
of the manipulation with its native functions.  Or as said, my big worry is a
broken script that just loops for ever.  OTOH, I don't know the overhead of the
script language to C interface - it could be pretty high, such that lots of
callbacks to C do get costly.

 The real question is would such a simple script language be sufficient?  I
think for probably most all of what we do, it may be.  It seems to me most
script logic can be done via flowchart/if then else type things, and not be
really complicated in what it is doing.

 IMO, most of the work for the above one is probably not the script interperter,
but instead all the callbacks.