[crossfire] scripts

[Mark Wedel]

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.

  Often times when a new arch is added, it is used in maps pretty quickly (after 
all, what is the point of new arches if you don't use them), so if you update 
the maps without the arches, problems arise.

> 
> 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:
> arch event_apply
> title Python
> slaying @python/items/smoking_pipe.py
> (@ rather than /); or we can just have the plugin look in both places.
> 
> Then arch-related scripts could be kept in the arch module where they 
> belong, or maybe in server, and be installed by server's "make install".

  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.

  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.