Hello. I just added a basic low-level quest state information storage mechanism (whao, *that* is a great name for a poor code :))
From the documentation: ******************************************************************* Quest support information ------------------------- Current quest support is low-level only. That is the server provides routines to query and store quest status, and that's all. It is the responsibility of the quest writer to call the functions, hook what needs to be handled, and such. The server does no internal state check, and it doesn't know how to handle anything except the status. Currently, a quest is composed of: - an internal code, which should be unique - a player title, a short sentence describing the quest - a longer description of the quest - the current player state (integer value, any positive value is ok, quest-specific meaning) - the current state description for the player, so she knows what to do next The information is stored in the player's directory, in a file named <player's name>.quest File is saved at each state modification, to ensure consistency. ******************************************************************* Functions are in server/quest.c One quest was written for Darcap, and is handled in the cf_darcap plugin. Now, if someone were ambitious, a quest engine could be written to handle common quest styles. I'd see some rudimentary scripting engine interpreting a pseudo-XML file, something like that... But well, maybe for another time ;) If you need help writing a quest, don't hesitate to ping me. Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web]
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
