Task System (preliminary work)

[Derision]

Originally Posted by Bulle

There is one thing you should be careful of : may be some Live tasks have simultaneaous activities. Something like "Make 7 flame Posts" and "Get banned for one week", that you need to complete before you can progress to the next activity.

That's a good point. The task I have been using as my guide has a sequential set of activities, where one must be completed before the next is revealed.

There are two types of task activity packet. One for completed and 'in progress' tasks which sends the details of the goal, and progress toward completion.

The second type is really just a placeholder, which consists just of an Activity Number, but no details of what the task is. These show up as ??? in the Task Journal.

It would be easy to alter the table and code to add a predecessor activity field. I know, (and you can see from the example in my first post), that it is possible to have more than one activity in progress displayed at the same time.

As for your other points, I skimmed over them, but they sound interesting, and I will look them over again and see what's possible as I continue to implement the system

[Derision]

I've been beavering away at this since Friday and thought I would provide an update on what I have functional so far:

Database Load routine for global task data
Database Load/Save for character task data

The database save is synchronous, but it only writes out anything that has been changed. I'll have to see if this can be done asynchronously like the saving of the other character data is.

Active task information is sent to the client when it enters a zone and so is retained across logins and zoning.

Initial Perl interface to bring up the Task Chooser with a list of up to 10 tasks:

The way I have it working right now, is the NPC has a list of all the tasks he can offer ($tasklist). It then checks whether the player already has each task in the list already assigned, (quest::istaskactive) and thus builds up a list of tasks it will offer ($tasksoffered), not including any tasks already active. quest::taskchooser then brings up the task selector window.

@tasklist =(1,2);
$tasksoffered = "";
foreach $task(@tasklist) {
	if(!quest::istaskactive($task)) {
		if($tasksoffered eq "") {
			$tasksoffered = $task;
        	}
                else {
                	$tasksoffered = $tasksoffered . "," . $task;
	        }
	}
}
if($tasksoffered ne "") {
	quest::taskchooser(eval($tasksoffered));
}

I have also added a new sub EVENT_TASKACCEPTED. This tells the NPC what task you accepted, so it can respond appropriately, summon an item etc. (When you accept the Children of the Fay task, you are given an Elven Bottle of Wine that you have to deliver).

sub EVENT_TASKACCEPTED {
        quest::say("You accepted task $task_id");
        if($task_id eq "1") {
                quest::summonitem(36078);
        }
}

You can remove a task by clicking the Remove button in the Task Journal window.

Two more Perl quest functions, quest::istaskactivityactive(taskid, activityid) and quest::flagtaskactivitycomplete(taskid, activityid).

This code checks when you hand in the Elven Bottle of Wine to see if you are on activity 0 of the Children of the Fay task (task 1), and if so, accepts the item, and flags that activity complete, sending the 'Task Stage completed' message, and unlocking the next activity:

sub EVENT_ITEM {
        if (plugin::check_handin(\%itemcount, 36078 => 1)) {
                if(quest::istaskactivityactive(1,0)) {
                        quest::say("Thank You!");
                        quest::flagtaskactivitycomplete(1,0);
                }

I'm still undecided about how to implement the predecessor activity requirements. E.g. say a task has 10 activities and when you completed activity 1, activities 2 and 3 open up. Task 4 then won't open up until tasks 2 and 3 are complete.

As I see it, I can either put a limit on how many predecessors an activity can have (let's say 4), and then have four columns in the table, predecessor1, predecessor2, etc.

Or, have a text field which could contain a comma separated list of predecessors, e.g. "2,3". I dislike this because it means I have to parse the string to get at the predecessor info.

I'm leaning toward option 1 (a fixed, small number of predecessors and having a column for each).

Still lots left to do!

[AndMetal]

Originally Posted by Derision

I'm still undecided about how to implement the predecessor activity requirements. E.g. say a task has 10 activities and when you completed activity 1, activities 2 and 3 open up. Task 4 then won't open up until tasks 2 and 3 are complete.

As I see it, I can either put a limit on how many predecessors an activity can have (let's say 4), and then have four columns in the table, predecessor1, predecessor2, etc.

Or, have a text field which could contain a comma separated list of predecessors, e.g. "2,3". I dislike this because it means I have to parse the string to get at the predecessor info.

I'm leaning toward option 1 (a fixed, small number of predecessors and having a column for each).

Still lots left to do!

I think something like the "_entries" or "_metadata" tables currently in the database would work best, similar to what KLS recommended above. Here's an example:

CREATE TABLE TaskOrder (
	taskid int(11) unsigned NOT NULL,
	activityid int(11) unsgined NOT NULL,
	step int(11) unsigned NOT NULL,
	PRIMARY KEY(taskid, activityid)
)

"step" could be used to group each stage, so using your example, activity 1 would be step 1, activities 2 & 3 would be step 2, and activity 4 would be step 3:

taskid		activityid	step
1		1		1
1		2		2
1		3		2
1		4		3

That way, it's more dynamic, and doesn't create a large table if you want something more than 4 prerequisites deep.

Hope this gives you some ideas, the whole task system seems REAL promising

[Derision]

Originally Posted by AndMetal

"step" could be used to group each stage

Thanks! I think just adding a 'step' column to the activity table, rather than creating another table should suffice.

Anyway, I've hit upon another snag. I've just implemented the code to update 'Kill' and 'Loot' activities, based on NPCTypeID or itemid respectively, which works great, however ...

I wanted to add a Kill activity to kill 5 Orc Centurions, but there are 40 entries for Orc Centurions in the npc_types table!

As they say, no plan survives contact with the enemy! I would welcome ideas on this one. Doing a lookup against a list of 40 NPC IDs per kill seems a bit OTT. Maybe some sort of sub-string match again the NPC name may be a less expensive way to go.

[Andrew80k]

Hmm. Could be you just let any of them meet the requirements. Or you could just filter them out like you say. It probably makes more sense to filter them out and then let any of the resulting id's after you filter them to your satisfaction, meet the requirements for the task.

[AndMetal]

Originally Posted by Derision

As they say, no plan survives contact with the enemy! I would welcome ideas on this one. Doing a lookup against a list of 40 NPC IDs per kill seems a bit OTT. Maybe some sort of sub-string match again the NPC name may be a less expensive way to go.

I think an easy way to do this would be to allow either a # (NPC ID for a specific mob) or a string. Then, the server can check to see which it is. If it's a #, use the specific NPC ID. If it's a string, allow multiples based on the string (SELECT name FROM npc_types WHERE name LIKE '%an_orc%'). I think it would be a lot easier to utilize overall (an_orc for example, instead of an_orc_warrior, an_orc_oracle, or an_orc_pawn). However, in the same token, I believe it could cause problems for mobs that have different names, but are different (lower) levels (read: exploit).

As much as I like the first option, I think the "better" way to do it would be to create a similar lookup table like I mentioned above. Yes, it is another table, but it makes it much more powerful overall. That way, you could also include named mobs that are rare spawns to include towards the kill target. Yeah, it seems like more work in the database, but that's also what relational databases are for: creating complex relationships between data sets

[KLS]

Use quests for the kill component =p

[AndMetal]

Originally Posted by KLS

Use quests for the kill component =p

*smacks forehead* I should have had a V8!

[Derision]

Originally Posted by KLS

Use quests for the kill component =p

Thanks

I've now mapped out some more of the activity types:

Activity Type Codes:

1 Deliver x to y
2 Kill n MobX
3 Loot n ItemA
4 Speak With x
5 Explore y
6 Create n ItemA using Tradeskills
7 Fish for n ItemA
8 Forage n ItemA
9 Use on 
10 Use on
11 Touch ItemA

So 1, 2, 4 and 5 can be handled through quests.

3 I already have handled by hooking into Corpse::LootItem, and I imagine 6, 7 and 8 should be done by hooking into the code as well.

I'm guessing that the 'Touch' activity means clicking on a clickable-object, like a door or something. I found a task on Alla that has 'touch' as an activity:

http://everquest.allakhazam.com/db/q...tml?quest=3151

But it's not clear what it means.