Fwd: Re: [CF-Devel] Crossfire Scripting language
gros
gros at magellan.fpms.ac.be
Mon Apr 23 06:58:10 CDT 2001
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 !
More information about the crossfire
mailing list