Task System (preliminary work)

[Derision]

I've been looking at whether it would be possible to get the Task System working. The OPcodes and
structs are pretty much squared away (a lot of this was already mapped out in the code, so I just
filled in the gaps with some info from a packet collect by Solid11 over at PEQs repository).

At the moment, I have written code to send the relevant OPcodes to the client and I'd thought I'd
share.

Bring up the Task Selector:



Send Task Description and Activity packets:



Send Task Stage Completed packet:



Send Task History:



I don't know what should go in the 'Quest Progression' part of that window ... maybe an Opcode I
am missing. I'll have to hop on live and see.

I haven't seen any packets relating to the 'Shared Tasks', but that is not a particular priority for me.

At the moment, all I have are some #commands to bring up these windows etc, as a test. There is still
a lot of work to do to integrate it into a working Task system. If anyone has any thoughts on how to
tie it in to, for example, the quest system, feel free to post your ideas.

[So_1337]

Deliver 2 Elven Bottle of Wine to KLS
Kill 4 Forum Trolls

Hahaha! Talented and funny!

Isn't this one of the primary roadblocks on any sort of LDoN functionality? I know getting any form of instancing working is also a pretty big hold-up, but I believe that the original form of LDoN didn't really have any -- It was simply 10 different versions of the same zone that could handle a group each. The Rujarkian Hills 'instance' was ruja-rujj, for example. Though I'm sure this is already common knowledge around here.

Just wondering, since that's the first I remember the task window ever coming into play. I know it was used for quests after that, but I didn't play much at all during that period and am thus unfamiliar. Was it retroactive at all? Did it handle some older quests by chance? My gut feeling is that it didn't.

[Andrew80k]

Dude!

I've been thinking about this for a while, but haven't had the time to get into it much. I think it would be great if we could tie it into the quest system. I haven't come up with a good solution, because I just don't know enough about how it works within the client. Basically, how it's passed to the client. Is all the quest data passed into the client at the time the quest is assigned, and then how do the updates affect it?

I was thinking about doing something on the order of quest::taskassign(blah, blah,blah) or however it worked out to assign tasks. Then quest::update(blah,blah), or what ever as far as how the data is then passed to the client. That is if it could even be integrated into the quest system.

Anyway, that's an awesome start. Thanks for taking it on...

[So_1337]

Having no idea whatsoever how it's actually handled, I feel perfectly qualified to pitch an idea for how it should work.

Initiate a quest with an NPC. That should pass the quest completion criteria to the client's task window.

quest::task(type,quantity,id);

Where type is the type of quest (collect or kill), quantity is how many must be collected/killed, and id is either the item ID or NPC ID.

Is there an op_code triggered by looting a certain item ID or killing an NPC of a certain type?

Feel free to shoo me away from this thread. I know I'm in far over my head. Just pitching that out there, though, as a rough example.

[Andrew80k]

Originally Posted by So_1337

Hahaha! Talented and funny!

Isn't this one of the primary roadblocks on any sort of LDoN functionality? I know getting any form of instancing working is also a pretty big hold-up, but I believe that the original form of LDoN didn't really have any -- It was simply 10 different versions of the same zone that could handle a group each. The Rujarkian Hills 'instance' was ruja-rujj, for example. Though I'm sure this is already common knowledge around here.

Just wondering, since that's the first I remember the task window ever coming into play. I know it was used for quests after that, but I didn't play much at all during that period and am thus unfamiliar. Was it retroactive at all? Did it handle some older quests by chance? My gut feeling is that it didn't.

Nah. The older quests were never "retrofitted" for the task system, which is a failing in Live, IMO. Would have been handy for those long epic quests. Or even the smaller ones. I think most of the "older" quests eventually yielded mostly crappy, in comparison, stuff so was thought to be more work than it is worth. It would be really nice to work it into the emu quest system though so as to rectify it if possible. We still have a lot of older quests that haven't been completed that could be fitted to make it work if it was possible to have it work that way.

[Derision]

Originally Posted by So_1337

Is there an op_code triggered by looting a certain item ID or killing an NPC of a certain type?

No, the way I see it working is, whenever you kill a mob, or loot something, the server will need to check if you have any active tasks, and if killing that mob, or looting that item, was an objective of the task, then incrementing the kill/loot count for the task and sending the Task Complete packet when you have killed/looted the required number.

Feel free to shoo me away from this thread. I know I'm in far over my head. Just pitching that out there, though, as a rough example.

I welcome anyones ideas. I never actually did any of these Tasks when I played on live.

[So_1337]

That sounds about right. I'm trying to remember the different quest types. I remember kill and collection, as those were the easiest. My friends and I pretty much kept requesting a new task until we got one of those, heh. Again, though, this only applies to LDoN. I suppose it could apply to many different quests that came later and fit the format correctly. Might need someone with a little more insight as to how it was used on Live, but your understanding of it sounds pretty spot-on thus far. It's the application of the system that's going to take some understanding.

[Derision]

Originally Posted by So_1337

I'm trying to remember the different quest types. I remember kill and collection, as those were the easiest.

There is an 'Activity Type' field, which determines, whether the activity is loot, deliver, kill etc. I've not tried all the possible values yet, but I know there is an 'Explore' type, which I imagine could be tied into the quest proximity detection in some way.

[Andrew80k]

Originally Posted by So_1337

That sounds about right. I'm trying to remember the different quest types. I remember kill and collection, as those were the easiest. My friends and I pretty much kept requesting a new task until we got one of those, heh. Again, though, this only applies to LDoN. I suppose it could apply to many different quests that came later and fit the format correctly. Might need someone with a little more insight as to how it was used on Live, but your understanding of it sounds pretty spot-on thus far. It's the application of the system that's going to take some understanding.

Most of the task quests involved kill and collect. There were locate explore type quests as well, where you just ran around looking for stuff. These were mostly to get questers familiar with the zones and such. I don't have the latest expansion so I'm not sure if there are other types in the later ones. I've done a lot in the DoN and a several in the Depths of Darkhollow. Most of those were kill and collect.

[Andrew80k]

Originally Posted by Derision

There is an 'Activity Type' field, which determines, whether the activity is loot, deliver, kill etc. I've not tried all the possible values yet, but I know there is an 'Explore' type, which I imagine could be tied into the quest proximity detection in some way.

Yeah, set up an invisible mob/object and set a proximity around it. Have the quest for that object send a task update. If you have the task your task updates, if not the client will likely ignore it.

[Flare83]

Awsomeness Derision, did you used to work for Sony? lol j/k but nonetheless great work.

[Flare83]

Damn edit button

The main things i remember from the task system was

EQlive must of kept a table for what quests you completed. Becuase some of the quests where long 12 mission arcs.
DoN used it heavely for its raids/group content.
GoD/OoW used the alt+z window for it's missions. i think they are alot different but on the other hand might be alot alike /shrug.
Ldon used alt+v i think

[KLS]

No, the way I see it working is, whenever you kill a mob, or loot something, the server will need to check if you have any active tasks, and if killing that mob, or looting that item, was an objective of the task, then incrementing the kill/loot count for the task and sending the Task Complete packet when you have killed/looted the required number.

Basically, we can already handle this kind of stuff via player quests too, proximity mobs for explore etc.

Would add a internal task tracking system for time, completion/failure and maybe item amounts since that would be cumbersome then could probably do the rest via quests.

quest::updatetaskvalue(taskfield,value)
quest::enabletaskforplayer()
quest::disabletaskforplayer()
quest::opentaskwindow()
quest::istaskcompleted(taskid)

etc. probably more or different.

Biggest issue if you've gotten most the packets worked out will probably be trying to with some finesse track the quests offered. Since quests offered to a player will vary based on: who the player is(race,class), what they've done(tasks/quests complete), which npc is giving it.

That said if you need help and I get time I'd be most excited to help you hammer out a system to do it.

[trevius]

Maybe quest globals could be used for tracking purposes for tasks? They sounds to be similar systems and I think you would just need to allow the task window to work with the quest globals system. If so, it seems like it would minimize the work needed to get this finished. Or maybe use some of the code from the globals system to implement something similar to be used only for tasks. I am sure you would need a table for tracking them and similar fields.

[KLS]

Actually it would probably be harder to integrate it into an old system than to create a new one as the system would probably be fairly straight forward really. For performance issues I think also it's probably not a good idea; think every time you have to do a quest action you need to re-export globals, integrating it into qglobals would probably inc the number of globals in use by a lot and make it just that much more work every time the server processed quests.