Peter Mardahl wrote: > > The consensus is that a scripting language of some sort for > crossfire would be very nice. Beyond that, nothing's been > decided. Furthermore, no one has volunteered to spearhead > this project, so in practice, it has gone nowhere. correct. There are lots of things on the TODO list or that have otherwise been discussed which is just waiting for someone to do them (or for one of the current developers time to free up). My personal thought is that the language for the scripting isn't very important - I don't see the actual scripts being really complicated. What is going to be the big issue is how the scripts can interact with the server code itself. For example, I see the following abilities of the scripting language to be relevant: take some object give some object cast a spell move to some location say something. listen for something watch for something given this, I have a feeling checking status of most of these will make up the bulk of the program. Beyond that, I would see a pretty simple if then/else if type structure. ie: heal = listen_for_something("heal me"); money = take_some_object("500 money") if (heal) { if (money) { say("I hope you feel better)" cast_a_spell("healing") } else { say("Healing will cost 500 silver"); } } else { say("How can I help you?") } Now the above does get into nesting and checking, but is not so complicated that we probably need features of most languages (ie, I doubt we will need arrays, hashes, or many other things). As I was thinking about this today, I realized the other issue is how to store these values accross map saves. you may have something like: if (listen_for_something("password")) { if (given_away_object) { say("Sorry - I don't have that anymore") } else { say("Use this for the betterment of good"); give_some_object("artifact"); given_away_object=1; } } now artifact would start in the npc's inventory, so once he's given it away, he can't give it away again until the map resets. However, between the time the map saves and it resets, if another player visits, we probably still what given_away_object to have the right value, so we get teh first message (I don't have it), instead of the second (use this ...), as the player won't be able to get the object. so given_away_object has to be stored someplace. My idea would be to use just a generic object, with perhaps a type like 'npc_var_holder'. the set and check for variables would use that object. Variable names would have to match the names in the structure, but using such an approach means the state can accurately get saved, and gives a lot of variables to play with (including some strings and floats for example). So in my last example, you could even set some field to the character the object was given to, and adjust the given_Away_object case to be like 'I've given that to $name' or the like. So in short summary: I don't think the language itself will make a big difference - what will really make the difference is how easy it can interact with the C code. My personal preferance would be perl for the following reasons: 1) Perl is already required by crossfire, so if we need to link in any perl libraries, they are already installed. This may not be the case for python or other scripting languages (this is not a big deal if the scipting language has all the parts it needs with crossfire) 2) Going with #1, there may be more perl knowledge with people dealing with crossfire. Ie, to develop, you would only need to know C and perl, which means that more people could potentially fix/help in scripting issues (say a broken npc), compared to using some other language which then means the developers need to know 3 or more languages (but this may noot be a big deal, as the scripting language may not get complicated enough).