[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