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

[Mark Wedel]

gros wrote:
<Re message colors>
>
     
     
     >
     
      I included it because of some players/map makers suggests. I didn't knew
     
     >
     
      there was a project about new message formatting system.
     
     
 It got put out on a possible future projects.  Nothing has happened yet on
this.  In fact, it should actually be a fairly easy (no brainpower) change to
make, but make take a little time to find all the referances.

 The cvs client supports an option for splitting the information pane into two
panes - right now, one gets colored text, the other the black/white text.  the
option is -splitinfo - gtk client only).  If you play with that, you will in
fact notice there are lots of messages that are currently printed in black which
probably should be more noticable.  The color text code was never really
integrated to much an extent in the code, so by default most everything is still
black.

>
     
      Only 127 simultaneous scripts are allowed right now, so 'thousands of scripts
     
     >
     
      potentially active' is not going to happen. I also admit that I didn't had
     
     >
     
      multithreaded scripts in mind when I first thought about using the pthread
     
     >
     
      lib - I was thinking about solving some problems with spellcasting (A player
     
     >
     
      can sometimes be locked for several seconds before being able to react to
     
     >
     
      spells cast on him). I also think the multithreading of scripts could cause
     
     >
     
      some problems; that's why I didn't included any code related to that. I'm
     
     >
     
      doing lots of tests to see if it is truly useful/efficient.
     
     
 So what then happens when your at that 127 limit and some other script comes
about?  Does it just not run?

 From your previous message, it sounds like a lot of objects might have scripts
attached to them, so getting to 127 scripts could happen prety quickly on a busy
server.  Ideally, the solution should probably be allowed to scale to whatever
number the system is capable of (in terms of cpu and/or memory).  There is of
course still some practical limit in all cases.