Loading...   

[Show Table of Contents]


There are currently five rules that govern operation of the Task System.

  1. RULE_BOOL ( TaskSystem, EnableTaskSystem, true)
    1. To enable the Task System, this must be set to true.
  2. RULE_INT ( TaskSystem, PeriodicCheckTimer, 5)
    1. This is a timer value, expressed in seconds, default 5 seconds.
    2. The 'Periodic Check' code in the Task System currently does two things:
    3. It checks whether tasks that have a set duration have exceeded their time limit. If so, it sends a red Task Failed. message to the client and removes the task from the Active Task Window.
    4. The second function is in relation to the 'Touch' activity. The first time the periodic check is called following entry to a zone, a check is made to see if the player has any activities to touch that zone, in which case they are marked complete.
  3. RULE_BOOL ( TaskSystem, RecordCompletedTasks, true)
    1. If true, tasks that a player has completed are recorded in the completed_tasks table.
  4. RULE_BOOL ( TaskSystem, RecordCompletedOptionalActivities, false)
    1. Tasks may have activities that are optional. If this rule is set to true, any optional activities that a player completes are also recorded. If there are lots of tasks developed that have lots of optional activities, then this table could potentially grow rather large over time.
  5. RULE_BOOL ( TaskSystem, KeepOneRecordPerCompletedTask, true)
    1. Live keeps an entry in the completed task window each time you complete a task, even if you have completed the task before. The client will only display the first 50 completed entries. Enabling this rule will keep a single entry per task, no matter how many times you complete it. If you have this rule set to false, and then set it to true, the next time a player completes a task that he has done before, the completed entries for that task will be disgarded, apart from the latest one.
  6. RULE_BOOL ( TaskSystem, EnableTaskProximity, true)
    1. If enabled, explore activities can be completed using proximities defined in the proximity table.

There are also some hardcoded limits, most based on what the client will accept.

#define MAXTASKS 10000
#define MAXTASKSETS 1000
// The Client has a hard cap of 19 active tasks
#define MAXACTIVETASKS 19
// The Max Chooser (Task Selector entries) is capped at 40 in the Titanium Client.
#define MAXCHOOSERENTRIES 40
// The Client has a hard cap of 20 activities per task.
#define MAXACTIVITIESPERTASK 20

Although not set by a #define, the client will only display the last 50 completed task entries sent to it. For this reason, the Task System sends the most recent 50 tasks completed. If anyone should ever complete more than 50 separate tasks, details of the ones not sent to the client are still retained for the purposes of checking with quest::istaskcompleted. (This is assuming RecordCompletedTasks is set to true.

ยงLogging Options

The following logging options are used by the Task system:

LOG_CATEGORY( TASKS )
LOG_TYPE( TASKS, GLOBALLOAD, DISABLED )
LOG_TYPE( TASKS, CLIENTLOAD, DISABLED )
LOG_TYPE( TASKS, UPDATE, DISABLED )
LOG_TYPE( TASKS, CLIENTSAVE, DISABLED )
LOG_TYPE( TASKS, PACKETS, DISABLED )
LOG_TYPE( TASKS, PROXIMITY, DISABLED )

Most of them should be fairly self-explanatory. TASKS UPDATE is used to print out debug info when checking if activities are completed.