[crossfire] Quest management system proposal

[Mark Wedel]

  I don't really have time to go into all the details, but have some quick thoughts:

Having the server of a plugin 'patch' objects loaded from the map itself seems 
to me to be a pretty horrible hack.  I know from a debugging side of thing, 
having a bug with an object in some odd state, and not even being sure how it 
got that way is a pain.  This also seems to be pretty problematic in terms of 
specific objects on specific maps (the NPC that gives out the quest info, for 
example).

  but I do then wonder if some hybrid approach could work better.  For objects 
that need to be modified, have them modified in the map.  But that doesn't 
prevent the use of a quest file like:

bunch of question info
#
# npc A,B on map ... will say "blah blah" to the player, and will update
# the quest state
#
..
..

  So that one file will show all the details of the quest info without needing 
to try and patch the objects.

  I personally don't think the ability to turn on/off quests should really be a 
design concern right now - or if so, this is a bigger project in terms of map 
options - there is no convenient way to change passwords, disable some set of 
maps, etc right now.  My thought is that if we want to do that, we should 
perhaps look into some macro processing language - as an example, with C 
preprocessor, you'd do something like:

#ifdef QUEST_ENABLE
..
#endif

  (not saying CPP should be used, but there are numerous macro processing 
languages that would probably do the job)

  In terms of script language, I think that is almost a different discussion - 
if python isn't sufficient or overly bloated, and we should move to something 
else, we should do that, but I don't think that should be an immediate design 
concern either.

  I forsee that if lua (or other language) is added as a quest specific script 
language, it wouldn't be long before it probably would turn into a full blown 
scripting language.

  I do think that we should find one (or worse case, a very select few) 
scripting language and stick with it - having a bunch of different script 
languages is just going to make things harder to maintain (now have several 
plugins codewise to support, and also harder from a script writer point of view 
- if all the scripts are in the same language, I can look at any of them to see 
how to do something, etc.  If they are in a mix of different languages, that 
makes things more difficult.

  while I'm not that familiar with python, we already have it, and it seems to 
be a pretty widely used language.  I normally can't envision the heaviness of 
the scripting language causing many problems as most plugins are not getting 
called enough that this should be a big issue.