[crossfire] Quest management system proposal

Nicolas Weeger (Laposte) nicolas.weeger at laposte.net
Tue Jun 27 12:04:20 CDT 2006


>   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'.

Well, for quest to work correctly, quest system will need to "override" 
current NPC system anyway, I think.
So extend the syntax, to add quest-dependant information, probably.

>   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.

Possibly. In which case quest system should check item still exists at map 
loading :)

>   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.

True. But remember, for Windows for instance, it isn't as easy to compile the 
server. So people will need a specific Python version, leading to possible 
collisions with required versions for other things.
But globally I agree. People want all features? Then install what's 
required :)


I think someday I'll just, if I can find the willpower, start coding, keeping 
all that in head, and change during the course of different versions :)

Nicolas



More information about the crossfire mailing list