[crossfire] scripts

[Lalo Martins]

On Wed, 09 May 2007 23:34:07 -0700, Mark Wedel wrote:
> 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.
> 
>   Note that this is often the case, and unrelated to scripts.

No, but you need to keep them somewhat in sync.  With the current state 
of affairs, you need to keep them *strictly* in sync: update one, update 
the other.  If arch scripts were separate, you could always update arches 
and not maps, and you could sometimes, not often, update maps and not 
arches.

>   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.
> 
>   I'd think in that case, the slaying is simpler - just something like
>   'slaying
> smoking_pipe.py' - since the script is in memory, there is effectively
> no need for a pathname.
> 
>   One advantage of this collection approach is that the scripts
>   themselves sit
> with the arches (same idea behind the treasurelists) - the script would
> be in the same directory as the object itself.

I like this idea!

It is possible, yes, but not very practical to do.  Easier however (and 
arguably cooler), we can run scripts from a zip file!

(Disclaimer: I haven't ever looked at how the plugin loads scripts.  I'm 
making assumptions based on what I know of Python's internals.  Ergo, I 
may be wrong.)

best,
                                               Lalo Martins
-- 
      So many of our dreams at first seem impossible,
       then they seem improbable, and then, when we
       summon the will, they soon become inevitable.
                           -----
personal:                    http://lalo.hystericalraisins.net/
technical:                    http://www.hystericalraisins.net/
GNU: never give up freedom                 http://www.gnu.org/