Task System (preliminary work)

[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!