[crossfire] The future of Crossfire

[Nicolas Weeger]

>   Fair enough.  It is sometimes hard to find the correct information, or if
> there is even correct information.  It may be a question if there is a
> better way to organize the wiki - I don't know if there is - unless one is
> to read everything on the wiki, it can get confusing fairly quickly - you
> see same/similar topics under different sub pages, and in same cases, they
> go to the same page, in other cases, they go to different topis, so it can
> make it difficult to know if you've actually read all the relevant
> informatin.

Then feel free to ask on the list :)
People will answer if they wrote about the subject on the wiki :)

>   I am saying that there should be sample scripts for some of the more
> frequently used/desired type of NPCS, or scripts in general.  sure, if I'm
> asking for something fairly obscure or something that will be used once, I
> should expect that I'll need to write my own script.
>
> But if all I want is an NPC that takes and item and gives an exp reward,
> that should be standard enough that I shouldn't need to write that from
> scratch.

Yes. But no one so was used the plugins/scripting support at all.
Now we are starting to see a few things, and as I said I'm ready to develop if 
people need help - but the mere fact no one asked also means there was no 
need.
So call to all map makers: imagine things! Dream of fun things! You'll get 
help for scripting if you need it.

> 1) I think sometimes we become overly cautious about making changes that
> may have bad effects or create other things that need fixing - the problem
> is that this tends to paralyze us into not making any change at all, which
> doesn't help us go forward.

Maybe, but game balance can be hard to maintain. Having a 2.0 branch is the 
right opportunity for this kind of things. So let's break havoc! :)

>    My point above is that if I write a script that moves an NPC, I
> basically want something like:
>
>   move_to(x,y);
>   apply_exit();
>   move_to(x1, y1);
>   move_to(x2, y2);
>   move_to(x3, y3);
>   apply_exit();
>   move_to(.., ..)
>
>   Where each action doesn't get processed until it does the previous one
> (we don't start move to x2,y2 until we reach x1, y1, etc.
>
>   In addition, that move logic should probably have some options, like
> avoid obstacles (if something is in the way, will change course), will pick
> up things while it moves, will (or won't) attack enemy creatures as it
> moves, etc.

No, you should say:
move_to(exit_x, exit_y)
apply_exit()
move_to(other_exit_x, other_exit_y)

Note that you can already - in Python import CFMove and use 
get_object_to(object, x, y) ; in C use the cf_object_move() wrapper.

>   How exactly all that logic is done, I don't really care much - if it is
> with python libraries, fine.  If there is C code to help, fine.  One
> concern on something like this, especially if there are a lot of NPCs
> about, is actual performance - if all done in python code, I'd have to
> imagine there'd be a fair amount of extra overhead as it examines the
> objets on all the surrounding spacing, as it looks for alternative paths,

We'll deal with performance issue when we encounter it :)
Let's first write content :)
We can always rewrite parts in C later, tweak stuff, whatever - many 
possibilities, which we'll use when the need arises.

Nicolas
-- 
http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref 
de l'aléatoire !]