Re: [crossfire] scripts
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. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] scripts
Le Thursday 10 May 2007 13:41:08 Lalo Martins, vous avez écrit : 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. You missed the point here. It couldn't possibly make things complex for map-makers, since this would never be visible to them :-) map scripts stay exactly as they are. What I'm talking about is introducing a distinction between them and arch scripts. So it would make things complex for arch writers... which, IMO, it wouldn't, it would make things a bit simpler for them. I consider arch-makers to be the same kind of people as map-makers :). Granted, I should have used arch-maker there, which is what I really meant. What I don't like is that @ syntax - it is cryptic and not required, provided that archetype scripts get installed at the proper place upon archetype collection. I don't think introducing another specific notation would make things a bit simpler. As for the idea of shipping scripts in the arch package, instead of having to put them into the map package, my position is why not ?. I doubt that compiling scripts in a single archive would be a great idea, though. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] scripts
Alex Schultz wrote: Such running scripts from text in memory is very possible indeed :) In fact, we could (and should IMHO) go one step further: Run it from the bytecodes in memory. The python code already has faculties for caching the bytecode of python scripts in memory (caches up to 16 scripts as bytecode in memory) and this increases speed of running the same script over and over VERY dramatically (code for this derived from daimonin's changes in the python plugin before it moved to lua). So, why store text in memory as such to run, when one could store the bytecode which would be much much faster and use less memory :) Right - I was thinking that it may be possible to store some machine format. As someone said, the one disadvantage of these collected scripts is that you can't change them on the fly. However, I'd consider that a pretty minor issue - if you're developing a script, you could certainly store it is a plain file so you can run it over and over again until it works, and then move it to the arch where it gets collected. As far as the idea of collect copying the scripts over to the maps script idea, I think this is a bad idea for many reasons: - In a sense, it pollutes the maps directory as far as SVN goes - you now have a bunch of files under maps which are not part of SVN. As things go right now, you can use a svn checkout for your maps area, and it will remain pure. - The abilities/ownership of the collect process gets many. It probably isn't that uncommon that one uid is used to build the source and run collect, and another is actually used for the make install. In this model, the collection process would be unable to copy the scripts directly over into the maps area - instead, it would have to copy them to a temporary area, (lib/scripts/...), and then the install copies those over. But if we're going to do that, it probably makes sense to just copy those over into some non map area of the install directory (share/scripts/...) or something - This may make packaging (rpms) more of a problem - this is especially true if a map script becomes an arch script or vice versa - now you have conflicting files in the RPMs. If they are in completely separate directories, no issue. As far as pathnames, to me, the simplest thing is to have a basic pathname and there just be a search order - server looks first in maps/scripts/..., then in share/scripts/..., etc. That should be very easy to do - the only issue is if there are two scripts of the same name. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] scripts
Hello. 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'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: I agree there need to be a way to separate scripts for archetypes, instead of having'em in the maps directory. I would put them in a subdirectory under where archetypes / treasures / formulae are, so we keep some coherence. As for having some special syntax, hum. we can always do that first, and change later on :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'aléatoire !] pgpjRBnz3xhRi.pgp Description: PGP signature ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] scripts
On Sun, 06 May 2007 18:13:32 +0200, Nicolas Weeger wrote: I agree there need to be a way to separate scripts for archetypes, instead of having'em in the maps directory. I would put them in a subdirectory under where archetypes / treasures / formulae are, so we keep some coherence. Right... that's exactly what I suggested, isn't it? ;-) As for having some special syntax, hum. we can always do that first, and change later on :) Which one? 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/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] scripts
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'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. Thoughts? 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/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
