I agree that we don't need a full fledged scripting language. To me, the big question (which I don't know the answer for) is how hard will it be to integate one of these other scripting languages into crossfire. You could very well get into some for of tradeoff, like: roll our own basic scripting language, which is really well integrated with crossfire (as it would use things like @apply and what not, so our interperter would know to directly call the appropriate function with appropriate args, which basically means we need to write the interperter, but not the item actions) vs: We use some other interperter, but have to add glue so it can use the internal crossfire objects (ie, apply, pickup, drop stuff). This may not be too bad if it can use an abstract interface, ie using a call that takes a generic string command like a player may use. There are of course advantages and disadvantages to both beyond just the above. If we use someone elses, it means that there is a very powerful language (but what exactly it can do will largely depend on how well it can access crossfire objects. For example, if the script can't access the map, knowing to do the right thing about earthwalls won't help if it can't find the earthwalls). There is also the problem of someone potentially creating a very complicated script which is needed (ie, key npc) but difficult for anyone else to ever modify (and for a new map maker, who decides to look at said npc to see how to do things, may get overly discouraged by the complexity). I also have some worry about the scripting language performance (just in terms of how much cpu time we will be spending executing scripts), but more worrysome is issues like the script getting in some infinite loop. Granted, that means the script is broken, but that basically means every scripted npc has to be evaluated to make sure they don't do anything bad - this makes adding new maps a little harder. The advantage of using our own is that the script language could certainly lack looping features, so other than it getting called really often, it can't really harm the server. To get back to the original question, and something that may be at least partially related here, one thing that may help determine what abilities the scripting language needs is some idea of what people want npc's to be able to do. Now less keep the ideas realistic here - while theoretically possible to write an npc scripting language so npc's could adventure on their own, I wouldn't expect that to happen. While it may be nice for enemy monsters to have scripts for tactics, that may not only get tricky (as script would need to be a lot more complicated), but it may make just as much sense to improve hte monster movement code to look forr some events. So to me, the short list of things it might be nice for npcs to do: 1) listen/talk to player. 2) give/take items from player. 3) become friendly/agressive towards player. 4) cast spells on player. 5) be able to move to specific coordinates within the same map (in this way you could create a script such that the npc wanders around). Currently, only players use exits, but conceivably, we could allow npc's to use exits, so the npc could traverse maps by going to the correct exit on one map and applying it. 6) apply and unapply items. 7) Perhaps some specials not allowed to player, like teleport to other map or specific coordinates on same map (in this way, for example, you could have a dragon guarding a pass, and given the right events, he 'flys' away and lets the party pass.