[crossfire] Quest management system proposal

[Mark Wedel]

Nicolas Weeger (Laposte) wrote:
>>   Latex stuff could probably go away - I don't know the last time anyone
>> updated the tex stuff (but to be fair, not sure last time any documentation
>> has been updated).
> 
> Actually, it seems to be kind of uptodate, since it generates data from 
> archetypes and such.
> I'd be more inclined to keep it - spoilers, handbook and such are nice. Also a 
> list of gods is nice to have locally.
> (could be used to make PDF manuals distributed with client)

  But there is html version of that same data.

  Granted, HTML doesn't print out as nicely, but I wonder how many people really 
print out the crossfire information (I actually rarely print out information of 
any sort - having it on the computer often makes it easier to search).

  The spoiler is pretty much completely generated from archetype data, so yes, 
it probably remains up to date.

  The handbook has a lot more static data.  The reason that is probably still up 
to date (effectively) is that there haven't been changes made that 
conflict/contradict the data that is there.

  A lot of changes we are talking about in the future would likely make some 
portion of this data out of date.

  At some point, it is a bit of a bother to have to update 2 different files 
(html + latex).  But more to the point, not sure how many people really use the 
latex data vs the html (I wonder how many people use latex in general now, given 
that there are lots more good & free WYSIWIG editors for *nix now).

> 
>>   OTOH, we are talking a very basic scripting language here.  If we want to
>> be technical, we could say the existing message/endmessage stuff if some
>> very very basic scripting language - its just simple enough that it is easy
>> to for anyone to use because it has very few options/commands.
> 
> True. But at some point people will want more than what the message/endmessage 
> offers, so we'll be back at square one - either use our own scripting 
> language, or an existing one.

  Maybe.  I'm not 100% sure that is a compelling argument - on that basis, 
anything done could be considered incomplete because it may not do something 
that someone may want in the future.

  Of course, it could be a case that you do the conversation by plugin, and 
people see it too cumbersome/complicated for basic conversation, and a 
'conversation light' syntax is added without need for plugins.

  Right now of course, there is no real scripting at all for messages.  So any 
addition, well, adds functionality, so basic scripting as I described may be 
enough for a large number of needs, and if it goes beyond that, then telling 
them to write a script would seem reasonable.


>>   If that is done, then the give_exp.pyc, and other general purpose scripts
>> need to be well documented so people know about them
> 
> Yes, but there aren't many scripts around - the IPO, a few related to guilds, 
> casino, misc. They should probably be documented, yes.
> 
> Note that right now you can't easily directly add exp to a skill, but imo 
> that's a function to be added. Will try to do that at some point.

  My point for scripts is that if general purpose scripts are added, for things 
like adding experience, etc, then those scripts need to be documented so it is 
easy for people to use.

  But I'll also continue to say that there should be an archetype that can be 
used to add exp, and that it shouldn't be necessary to use a script for such a 
basic operation.