Le Lundi 23 Avril 2001 00:07, vous avez écrit : > I agree that we don't need a full fledged scripting language. The real problem is: do we have time to spend to create a new scripting language from zero ? Indeed, we don't need advanced scripting infrastructure, but that's not the point. Writing an interpreter from zero is a very time-consuming task, and I think extending an existing language is easier (it took me only two weeks to get basic crossfire functions working on Guile, and I am not a professionnal coder). > 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. That's a real problem no yet deeply studied. The hard point is that crossfire is not a multi-threaded program. with my current script implementation, a script must end to let the game continue, and there is no lock prevention: if a script takes one hour to terminate, the game will be frozen for all that time ! With the current crossfire architecture, I can see two "simple" solutions: 1 - Refusing badly-written scripts, which means scripted map would have to be extensively tested; impose a maximal script execution time to map-makers. 2 - Implementing some kind of "script server" running in a separate thread, and thus not able to lock crossfire for long periods of time. Following me, 1 is sufficient for now - My own tests showed that you can do quite a lot of things with a script in only a small quantum of time. And intensive map testing is often already done when a new map is submitted. > 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. I now consider the above list as my "official" todo list, so if someone thinks npcs should do other things, please tell me. What's currently done for events: 1 - listen/talk: fully implemented. 2 - give/take: implemented, although I'm working on complementary functions. 3 - become friendly/aggressive: implemented. 4 - cast spells on player: fully implemented. 5 - moving: implemented. Basic functions for npc move are present, but I still didn't used them for extensive npc movements. 6 - apply/unapply: work in progress. 7 - npc specials: nothing done yet. I'll also put this week a modified release of crossfire-0.98.0 with scripting support. An old version (0.97.0) is still available on: http://www.chachkoff.f2s.com/crossfire/crossscript.tb2 (tar-bz2) http://www.chachkoff.f2s.com/crossfire/crossscript-maps.tb2 (tar-bz2) Commander Gros Ad Dwarvam Aeternam !