Task System (preliminary work)

[Flare83]

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.

It means zone into a certain instanced / zone basically ~.~

[Bulle]

When you say : for kills, handling through quests, do you actually mean patching/creating many NPCs Perl quest files ? There can be an orc_centurion in several zones, some of them actually "dinging" the quest..

As the kill activity is very common, having a lookup table (ID of activity, ID of mob) seems worth doing. Especially as you can attach this list/set to the activity in a field once it is loaded from the DB. It probably is not in the scope of Live-like, but extending this to several activity types you could then have activities that accept looting "any rusty weapon". Not trying to make my shopping list for the first implementation, just trying to keep doors open here

Or may be you thought of another way through quests ?

As a professional programmer let me say one thing : filtering on the name (or a part of the name) will inevitably create unsolvable situations, or to say it bluntly, it will suck. It always does when you start doing such things.

[Derision]

Originally Posted by Bulle

When you say : for kills, handling through quests, do you actually mean patching/creating many NPCs Perl quest files ? There can be an orc_centurion in several zones, some of them actually "dinging" the quest.

I took it to mean calling the task activity update method from within sub EVENT_DEATH, which works.

As the kill activity is very common, having a lookup table (ID of activity, ID of mob) seems worth doing. Especially as you can attach this list/set to the activity in a field once it is loaded from the DB.

My concern was, in the case of an Orc Centurion, having to check through a list of 40 NPCIDs every time the player killed something to see if he had killed an Orc Centurion. It occurs to me now that if the list is sorted, I could do a binary search on larger lists, so maybe it wouldn't be so bad

I could always include both methods and have a flag to indicate whether the activity count update was to come from a quest, or be checked from a list.

[KLS]

EVENT_KILLED_MERIT was designed with mob kill quests in mind. You could make 40 different quest files or you could just make a single an_orc_centurion.pl. It basically just simplifies the problem that was discussed above but is hardly the only solution.

[Bulle]

You really have two ways of processing quests : the configured way, and the custom way.

At the moment EQEmu "shines" in the custom way. I put shine in quotes because I hate Perl, but other than that it is very much open-ended With the Perl scripts you can do a lot of things, it just takes time, knowledge and patience (did I mention "time" ?).

The other way is what wow-emulators provide : table-driven definitions to easily specify kill quests, loot quests, explore quests and a few others. The list is limited, the configuration tolerated is limited, but it is very efficient (in that the server handles it, and it avoids the silly Perl syntax errors).

Both can co-exist. The server can first check the "configured" quests, and then the fully-custom ones. At the moment EQEmu is lacking in the second option, which covers a big portion of the quest/task neeeds. If we had that, many "newcomers" could write their own basic quests, by tweaking tables instead of writing Perl. I am not only speaking of "Live"-like quests there, many custom quests would become very easy.

This is really what I was hinting at, that there are two parts in what you would like to implement, Derision :
* Exposing the functionality (opcodes) allowing the Quest Journal to work. Providing the functionality through functions in C++ and possibly Quest:: Perl function calls. This is the basis for task tracking.
* creating an "easy-quest" framework, using the requirements of the EQ Task system as a guideline.

You can have all those alternatives in a game :
* easy and limited quests with no tracking
* complex and open-ended quests with no tracking (as it is at the moment)
* easy and tracked quests (Quest Journal + Task system, what you are trying to achieve , and what basic wow emu supports)
* complex and tracked quests (what I am suggesting you enable by opening the Quest Journal implementation)

Not trying to scare you off there, but the task you have started encompasses all four, as adding the third one to the second one is close to enabling the four programming-wise. If your design is good you should get the other two as a nearly-free bonus. If not, well... You will still get the third one ! Just do not be puzzled when you realize the task you embarked on is tough. eh eh. The end-result will be awesome, but the price has to be paid !

At least that is my analysis of what is going on I wish I could offer my help on this project, but I will be quite busy in the coming month. Still if you would like to submit some interfaces (function or quest:: Perl prototypes...) for review, some of us could find the time to provide some feedback. It is up to you.

[Bulle]

I think you can forget your worries about scanning 40 mob IDs in a list, as long as everything is already in memory : our regular CPUs do that in no time. Doing a binary search for that small a number is not worth it. From 500 IDs on OK may be... Or may be from 5000... You have to profile that to be sure.

What matters is that you read the ID list only very rarely from the database. DB queries cost. If it is all loaded in one shot at startup, then it is not a concern. Just make sure you do not issue one DB query per activity, as it would be a killer. For example, issue one query to load all activities at once, then one query to load all dependent mob IDs at once, then do any activity-dispatching (list creation and populating) in-memory. If you add proper "ORDER BY" sections to your queries you can even scan your activity list and your mob ID list in parallel, making it a very efficient process.

[Derision]

I've been busy with work this week and not had as much time as I would have liked to work on this, but today I figured out the Titanium OPcode to flag a task as complete (which is different from 6.2) and make it display the green 'Task Completed' message (I think I have found the struct values to make it display 'Task Failed', but I haven't got around to testing that yet.



The more astute amongst you will note that the 'Children of the Fay' task does not finish in Kurn's tower, however I used a bit of 'artistic license' is setting the task goals during development.

There is still quite a bit left to do, but the system is now functional end-to-end for tasks with talk/kill and loot activities. Hopefully I will get a lot more done over the weekend.

[trevius]

That is so awesome! I am currently working on a custom zone that will use qglobals to track kills similar to tasks. But, it would certainly be cool to use the real task system for it instead!

[Derision]

I've started to document how the system works on the Wiki, the overview page links to the pages I've written so far:

http://www.eqemulator.net/wiki/wikka...SystemOverview

There are still some Perl interfaces to be written, and a few tweaks to the tables, code cleanup and testing (robustness against bad data in the tables, discovering the limits on the number of active tasks, task selector entries, completed tasks, etc, that I can send to the client without it crashing) before it will be ready for an alpha release.

[Andrew80k]

Dude! Can't wait... I love seeing stuff like this getting done in the emu.

[bleh9]

Knowing nothing about tasks, here's some quick thoughts after a cursory look.

1. Why have activity types? Why not push complexity out to scripts?

  sub EVENT_ITEM
  {
    if (quest::hastask(1234)) {
      quest::completetask(1234);  # completetask() gives any rewards
      quest::givetask(12345); # givetask() gives any items needed to complete task
    }
  }

2. Are tasks accessed so frequently that they need to be in memory? Why not just query the database? Especially if number of tasks increases, this will leave resources to the server (e.g., for disk caching). In any case, please don't put it into shared memory as suggested -- there's too much there as it is.

3. Could the step info be removed and replaced by prerequisites? A single lookup table should suffice:

  create table tasks (
    task_id int primary key
    -- whatever else a task needs
  );

  create table task_prerequisites (
    task_id int references tasks(task_id) on delete cascade,
    task_id_prereq int references tasks(task_id) on delete cascade
  );

Most tasks will only have one entry in this table (e.g., task 3 requires task 2), but also allows for requiring disparate tasks to be completed before beginning another.

4. Why not create a one-to-many relation for task rewards? Either an aggregate reward table as follows or a reward table for each type (e.g., task_exp_rewards, task_coin_rewards). This can allow for

create table task_rewards (
  task_id int references tasks(task_id),
  exp int,
  coin int,
  item_id references items(id) -- think that's the column name; don't have schema handy
);

On a semi-unrelated note, I've seen very little eqemu code that uses JOINs when it comes to SQL, and I don't know that I've ever seen any foreign keys. Is this a MyISAM effect?

[trevius]

Holy cow Derision! Tonight was the first time I got to really check out the new system and try actually creating a task. It is very complex, but also very versatile! I can't believe you did all of the work on this alone lol. Even the wiki pages by themselves must have taken forever! I think this system has alot of potential and I will definitely try to push the limits with making some interesting tasks on my server

Huge thanks for putting this whole thing together. I still can't believe how much work this must have been lol. Jeez! You do some amazing work, but damn man, nice job!

Makes me glad the new SVN is setup so I can finally test all of this without having to mess with code updates.

[joligario]

Wrote my first task today... wow that can get involved!

I have a couple ideas/requests/observations:
1. Under the rewards, if there is a cash reward can you display the amount or at least have it say Cash?
2. The reward text does not show on the task screen unless it is an item.
3. Under description, can you set up a description for the initial task window? For example: [0, This is my general description.][1, This is my description for step 1][2,3, This is my description for shared steps 2 and 3.]. Currently it is blank if step 1 and 2 are shared but if there is only 1 step, the main task window shows the entire text from the first step.
4. In activities, even though activitytype is over-ridden if text3 is populated, setting it to 0 will produce erroneous results in the task window. Currently you have default set to 0.
5. You have done an OUTSTANDING job on this!

I think that's it for now. Learning a lot and noticing that we now have many more possibilities with this system. Thanks!

CRAP, please move this to the discussion thread!!!

[ChaosSlayer]

I have a question on task system.

When goal is set to loot say 50 Wolf Pelts.
When players loots the pelts- where do they go? To players inventory?
Cuase if system grants you credit when you loot the petl, once you looted it, you can turn around and sell it, but you allready got the credit for looting it.

OR does the system automaticly destroyes all goal looted items after giving player the credit to prevent cheating?

[Andrew80k]

Most of the time, but not all, the things you are required to loot either have to be turned in to the quest giver, or they are no drop. Depends on the task. It's sort of up to the task creator.