Le Mercredi 13 Juin 2001 00:58, vous avez écrit : > > 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. > > 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. 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). 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. Chachkoff Y.