Quote:
Task initiation will be done through the existing Perl quest system, so the usual checks
for class, race, faction can be done before the NPC initiates the Task Chooser. (Also provide
a function so that a check can be made in Perl to see if the player has already completed
a particular task, so as not to offer it again).
|
See this to me presents a unique problem in that it would be cumbersome if not impossible to write quests to include all the tasks a person has from a given npc. Keep in mind some task givers are giving out lots and lots of tasks, especially the ones for shards and such give out literal boatloads of tasks.
Personally I'd do something like:
Code:
CREATE TABLE TaskSet (
id int(11) unsigned NOT NULL,
globaltaskid int(11) unsgined NOT NULL,
PRIMARY KEY(id, globaltaskid)
)
Would allow you to group tasks together into tasksets and the quest code could be simplified to quest::BringUpTaskWindow(taskset). Different npcs offer different tasks and more than 1 at a time if you qualify for them on live.
Would also need some way of enabling the tasks if one were to go with such an implementation.
Quote:
CREATE TABLE CharacterTasksEnabled (
charid int(11) unsigned NOT NULL,
taskid int(11) unsigned NOT NULL,
enabled tinyint(1) default '0',
PRIMARY KEY(charid, taskid)
)
|
Could then offer quest::EnableTask(taskid), quest::DisableTask(taskid), etc to make it much simpler to write quests that use the task system.
Putting it in shared memory is also probably a better option as the structures are probably going to need to be in some cases quite large and with the assumed 10000 entries it would really add up for a server that loads quite a few zones. A couple MB per zone doesn't seem like a big deal until you load up 50.