[crossfire] Quest management system proposal

[Mark Wedel]

Nicolas Weeger (Laposte) wrote:
>> 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).
> 
> Just a precision: not talking about "patching" / "modifying" objects, just 
> adding event handlers in inventory.

  Which is still patching/modifying objects.  Perhaps not in a huge way, but 
still, to me, it would seem better for the object in the map to be modified, and 
not have post processing done later.

  Some of this concern may be unwarranted, but I always fear the 'its only 
plugins now, but down the road, it could be other things modified, like say 
msg/endmsg data'.

  And even with just plugins, there is always the potential that the object 
might be modified to have that event set.  What happens then when the loader 
wants to use that same event for a different script.

  I still think it would be better for the script control file to mention the 
different objects (map, x,y) that are tied to the quest, but actually have the 
objects modified in the map.  That is simpler (all the code to handle that 
already exists) and prevents possible problems.

  The only disadvantage is that if someone wants to disable a quest, there are 
now a bunch of objects to modify in maps.  However, that really isn't any 
different than things are right now with most of the basic quests out there (to 
disable them would mean removing maps, modifying them, whatever).

  But one thought on this to make it eaiser - in the quest control file, you 
could have some line like:

bunch of quest related to delivering a message
message_delivery_quest_enable=1 (or 0 to disable it)

  So instead of having to comment a bunch of lines out, it is just one line to 
change (and in fact, may make sense to have 2 files - one with all the quest 
related info, and another that describes if the quests are enabled or not - in 
this way, just a quick perusal of one file to decide what to enable/disable.

  I think the scripts could pretty easily be modified to have something like 'if 
quest_enabled(message_delivery)==0 { do nothing}'

  This does mean that the scripts may be getting called unneccessary, but I 
don't think that is a big deal.

  As I think about it, having such checks could be really nice.  I could 
envision an NPC that wants a dozen things delivered.  The script is in place to 
handle all those different things.  Instead of having an all or nothing for that 
npc, those different quests could be enabled/disabled, and the scripting 
language can check for that.


> 
>>   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.
> 
> Yes, that's another discussion :)
> But for instance Windows users don't always have Python installed, thus 
> requiring it needs adding and maintaining links to Python packages, things 
> like that.

  But if that is the issue, then requiring that python be installed I think 
would be perfectly reasonable.  Or if python isn't available, then of course 
none of the quests are available.

  I don't particularly think we should base design on having people who run a 
server to install some software.  If they want to run a server, they should be 
able to go through and install that software - it shouldn't be very hard.  If 
they don't want to, then don't run the server.