[CF-Devel] Crossfire Scripting Extension, version 1.0.0b11

[Mark Wedel]

On Wed, 13 Jun 2001, gros wrote:

>
     
      That's not a real problem if there's no multithreading support. When scripted
     
     >
     
      object A gets its 'quantum time', its script gets executed if necessary. When
     
     >
     
      the whole script has ended, crossfire switches to object B, then object C,
     
     >
     
      ... Two objects can never move at the same time in the current implementation
     
     >
     
      of crossfire. The only case now where you can have multiple scripts running
     
     >
     
      at the same time is when a script triggers another script event (for example,
     
     >
     
      the BroadSword of Scripting has an attack script and can trigger a
     
     >
     
      script_death event when killing a scripted monster). So, the 127 limit means
     
     >
     
      that you can only have a 'chain of scripts' 127 scripts long (which sounds
     
     >
     
      very unlikely to happen).
     
     
 Ok.  It is basically a stack depth of 127, which should be sufficient.
But what does happen if it is reached?  does the last one just not execute?

 I could see some error, or a situation where the like script A says
something which script B hears and says something in return, which script
A hears and says something in return, and at some point, one of the scripts
says something that starts it all over again.


>
     
      Now for the multithread problem: it is indeed true that following my own
     
     >
     
      tests, it does not seem to be needed. That's why I removed any references to
     
     >
     
      it from my CVS patch. I still don't know if I'll continue to work on it or
     
     >
     
      not.
     
     
 If multithreading comes about, I think it will be at a higher level
than scripts.

 IMO, if multithreading is done for the server, it would probably
be done at the map level (each map has its own thread).  The separation
at that point would result in the fewest mutexes needed I think, and
probably work the best even for single cpu systems (won't have too many
threads going about, but does let the performance of one bad map only
affect the players on that map, and not the entire server).  It also means
map loading/saving can be done in its own thread, so that those actions
don't affect performance for players (except for the player who has
just transferred to the map that needs to be loaded).

 This currently is a fairly low priority project - there are a lot of
other things should be done first.  Threads don't help out much if the
code handles some things poorly (like many spell effects).