[crossfire] Quest management system proposal

[Nicolas Weeger (Laposte)]

>   I'd rather not have the NPC conversation be in python.  IT has long been
> discusses that the NPC conversation needs to be improved, with things like
> conversation states, etc.  This is unrelated to quests in particular - just
> a general good thing to do.
>
>   IMO, having some basic scripting syntax for states in the
> message/endmessage would be a good thing - after all, map makers are people
> that would be using that, and at current time, there isn't a requirement
> that map makers also be programmers.  I suppose and answer could be 'just
> copy the npc script from elsewhere' to the less technical map makers, but
> I'm not sure that is a good answer.

The issue I see with this is that it adds Yet Another Scripting Language to 
Crossfire...
Right now we're using C, autoconf/autotools, LaTeX (documentation - is it 
uptodate, actually??), Perl, Python, NSIS (Windows installer).

Adding Crossfire's Scripting Language would add some complexity, including 
making sure we don't break that, add features mapmakers will want/need, and 
before we know we reimplemented an existing language :)

What could be done, though: let mapmakers write messages with an extended 
syntax, like you suggested, and have a Python plugin/script handle that 
internally (or handle it in server core, but that's less easier to switch i 
think).

>   This also makes sense that anything the NPC says can be heard to anyone
> near by (it isn't just at the player).  This is why I was thinking NPC's
> should have some limited state just for general conversations (the case
> this really covers is when you should be able to keep saying 'yes' to the
> npc to get more info, but the current mechanism doesn't allow that, so
> instead players have to start guessing what is the word to continue the
> conversation).
>
>   There certainly should be state information for the player itself related
> to npc conversations in some cases (especially quests).

Well, then I guess it'll depend on the NPC considered.

>   It seems like every year or so, the discussion of what should be in C and
> what should be in plugins shows up, and this is sort of one of those.  I
> suppose we really should come up with a standard and document it.
>
>   But some also goes to above - the people who will use quests are
> mapmakers. Should it be a requirement for mapmakers to know python/have
> scripting skills to use many of the handy features of crossfire/map maker?
>
>   If the answer there is yes, then no real issues.  If the answer is no,
> then we perhaps need to revisit if python is the best solution.

As I said earlier, I'm not that eager to add/create a new scripting 
language :)

>   That said, it may be reasonable to have some set of basic scripts that do
> basic actions (add exp, etc) - in a sense standard scripts that map makers
> can use without having to know scripting.  they just need to be well
> documented.

All methods are referenced in http://wiki.metalforge.net/doku.php/cfpython
True, it could use some examples and such.

OTOH, I'm sure a mapmaker not knowing how to write scripts and asking on the 
list or IRC would get some help.

>   One question completely unrelated to this - would it make sense for the
> scripts themselves to be located in the same directory as the maps itself?
>
>   For example, right now, all scripts are in python/....

Yes, it'd make sense if scripts are related to a map.
Having:
* mymap
* mymapscripts/*py
makes it easier to package the map.

Note that for "local" events (ie related to a player's action, as opposed to a 
global event like time, death, kill, login/logout), you can already put 
scripts in such a subdirectory, you just have to put in the full filename.


Nicolas