[CF-Devel] Crossfire Scripting language

[Mark Wedel]

gros wrote:

>
     
      Suggestion - could anyone try to make a complete list of needed scripting
     
     >
     
      abilities ?
     
     
 you only sent the reply to me, not the entire list.  So I recopy most of the
message here.

>
     
     
     >
     
      >
     
     >
     
      >  given this, I have a feeling checking status of most of these will make up
     
     >
     
      > the bulk of the program.
     
     >
     
     
     >
     
      Agree, but do not forget event handling is also an important part.
     
     >
     
      Some examples:
     
     >
     
              drop
     
     
 give/take I would think would do this.

>
     
              apply/unapply
     
     
 unsure how often this may happen in terms of armor/weapons.  But having those
is probably not a bad idea.

>
     
              attack
     
     
 more likely, some way to change the status of npc's (peaceful, neutral,
aggressive, pet, etc).  Similar to what some skills do.  

>
     
              speak
     
     
 I thought I included that.

>
     
     
     >
     
      Suggestion - could anyone try to make a complete list of interesting events ?
     
     
 This is always hard to do - new features may come out, or someone may think of
a new use for an npc.  one way to achieve expandibility is to have npc's execute
actual commands (who, apply, use_skill, etc).  Now most of those functions
specifically look to see if a player is doing that command, and if not, doesn't
do anything.  But allowing the script to execute commands like that would
basically mean the npc can do most anything a player could do.


>
     
      We could use existing Crossfire objects to store script variables, or to pass
     
     >
     
      variables between different scripts. I used the invisible force object in my
     
     >
     
      scripting implementation to do just that. For example, I created a sword with
     
     >
     
      the following script:
     
     >
     
     
     >
     
       ;;Test Nr 8 - A weapon script_use test
     
     >
     
     
     >
     
      ;;Get the name of the attacked monster:
     
     >
     
       (define fobname (get-name (who-is-other)));
     
     >
     
      ;;Search an invisible inside the sword with that monster name:
     
     >
     
       (define fob (check-invisible-object-inside fobname (who-am-I)));
     
     >
     
       (if (zero? fob)
     
     >
     
              (crossfire-message "Your sword suddenly emits bright light !")
     
     >
     
       );
     
     >
     
       (if (zero? fob)
     
     >
     
              (create-invisible-object-inside fobname (who-am-I))
     
     >
     
       );
     
     >
     
       (if (zero? fob)
     
     >
     
              (kill-object (who-is-activator) (who-is-other) 1)
     
     >
     
       );
     
     >
     
       (if (zero? fob)
     
     >
     
              (crossfire-message "The light disappears !")
     
     >
     
       );
     
     >
     
     
     >
     
      When attacking a monster, the sword first check if such a monster as already
     
     >
     
      been encountered. If no, it immediately kills it and an invisible force
     
     >
     
      object with the name of the killed monster is put inside the sword. If yes,
     
     >
     
      it behaves like a normal sword. The list of killed monster types is so saved
     
     >
     
      within the sword.
     
     >
     
      To save variables between map savings, why not using the mechanism applied
     
     >
     
      for the Adventurer's Guild to save objects dropped on the floor ?
     
     
 That mechanism still uses normal crossfire objects.  The problem is if your
holding variables in your script or passing them between scripts, they are
external to how crossfire sees them, and so will not be saved.  The point is
that variables used within the script somehow have to be linked back to
crossfire objects, or some external implementation to save these variables would
be needed.


>
     
      If a common language is used, this may not be a problem. Python and others
     
     >
     
      are widespread if not installed by default on many UNIX-Systems.
     
     
 This is a very dangerous misconception.  Just because its widely used hardly
means its installed default on many unix systems.

 I personally find it really annoying when I go to try and install something
cool and find out I have a dozen dependancies I need to install first (or some
of those may have other ones). 



>
     
      Never forget that people who want to make maps may not be crossfire
     
     >
     
      developers, so they could know nothing about Perl. I think the scripting
     
     >
     
      language must be easy to learn so anyone able to use crossedit could also be
     
     >
     
      able to understand it. That's one of the reasons I didn't choose Perl when
     
     >
     
      writing script extensions, because it was seen as too complicated by many
     
     >
     
      people. I didn't knew anything about Scheme/Guile but it only took me a day
     
     >
     
      to understand it, so I think it is not a bad choice.
     
     
 Note if they are not developers, any language can potentially be difficult to
learn.  As said, I don't expect the scripts to be going much beyond if something
else something else type scripts, which I would hope most people would be able
to understand.

 If anything, a scripting helper in the editor could be added.  Many commercial
games do that.  I also would noto expect the first time map maker to go and make
some really complicated NPC script.  So you could very well have a simple primer
(do this/that to get something done), and of course the advanced developers may
be able to use some more advanced features.

 Easy to learn is only one consideration - to me, one that is just as big is
readability of the scripts by others, since almost certainly someone will need
to do something with it later on.  And scheme has never gone into that category
in my mind.