[crossfire] scripts

Yann Chachkoff yann.chachkoff at myrealbox.com
Thu May 10 02:18:09 CDT 2007


Le Thursday 10 May 2007 08:34:07 Mark Wedel, vous avez écrit :
> Lalo Martins wrote:
> > One thing that has been bothering me recently, is that increasingly, most
> > scripts are tied to arches, yet they reside inside maps, which means an
> > admin needs to keep arches and maps strictly in sync.
>
I don't think "keeping both in sync" is a problem - if I create a new map and 
use a new archetype in it, I'll have to sync both regardless is scripts are 
involved or not.

Now, it could be more convenient for the archetype-maker to have the scripts 
in the arch package itself; the collect script could copy those into the 
appropriate places in the maps/python subdirectory (or elsewhere) when 
needed.

> > I'd like to propose the tiniest addition to the complexity of the python
> > plugin, so that we'd have a structure like this on a server:
> >
> > lib/
> >   python/
> >     (arch scripts)
> >   maps/
> >     (maps)
> >     python/
> >       (map scripts)
> >
> > So we can introduce a notation to mark a script as an arch script, eg:
mmm... I don't understand what the advantage of this would be - I think it 
makes things rather complex for map-makers, with no obvious benefit.

>   Is it possible to run scripts from text that is in memory?  If so, then
> an approach similar to the treasures - collect them into a file, read them
> into memory, and when needed, run the script from that information in
> memory.
>
Yes, it is possible - the problem in that case is that as the number of 
scripts increases, this may become a noticeable waste of memory.
Also, not that the current system allows one to test scripts "on the fly", 
without having to restart the server each time - memory loading would not 
provide the same possibility.

>   If this idea isn't feasible, the next approach would be to have a
> 'scripts' directory, and the collect process just takes the scripts and
> copies them over there, and then install copies all the scripts elsewhere.
>
I tend to think this is a better approach.



More information about the crossfire mailing list