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

[H. S. Teoh]

On Mon, Apr 23, 2001 at 07:58:10AM -0400, gros wrote:
[snip]
>
     
      That's a real problem no yet deeply studied. The hard point is that crossfire
     
     >
     
      is not a multi-threaded program. with my current script implementation, a
     
     >
     
      script must end to let the game continue, and there is no lock prevention: if
     
     >
     
      a script takes one hour to terminate, the game will be frozen for all that
     
     >
     
      time ! With the current crossfire architecture, I can see two "simple"
     
     >
     
      solutions:
     
     
Actually, this is a very good argument for writing our own script
interpreter. This way, we can actually "multithread" scripts -- so a
script that takes a long time can actually be broken up across several
server ticks. Doing it that way might also make it possible to write
scripts that an NPC continually executes (eg. an NPC elf can be
continually practising his archery skills by shooting arrows at a target).

>
     
      1 - Refusing badly-written scripts, which means scripted map would have to be
     
     >
     
      extensively tested; impose a maximal script execution time to map-makers.
     
     
The problem with this is, if we use Guile or Python or whatever else, it's
very difficult (if not impossible) to determine the script's execution
time. Given a script of sufficient complexity, it may be very difficult
even for human examination; auto-verification is out the window.

>
     
      2 - Implementing some kind of "script server" running in a separate thread,
     
     >
     
      and thus not able to lock crossfire for long periods of time.
     
     [snip]

This sounds plausible, although synchronization might become quite a big
issue -- for example, you might get very different results if the server
machine for some reason runs the CF server more often than the script
server -- the scripts could then get out of sync with the server. And it
might produce very different outcomes depending on which machine/OS you
run it on, esp. if scripts rely on timing.

One thing I like about writing our own scripting language is that the
scripts can be run in lockstep with the server, so that timing is always
100% accurate.


T

-- 
You've gotten under my skin. That you got there speaks ill of me. That you
like it there speaks ill of you. -- Speek, K5