I'm hoping this will spark further conversation around the quest system and lead contributors into helping as things continue to develop. There is a lot of work yet to do for a single person, but with help it becomes very achievable.

Nice writeup! It's great to see this come along,working quests in Daggerfall Unity will be a huge step. I'm definitely interested in helping out, I'll start in ASAP.

One thing I was wondering - have you found any connection between quests & the action object system? There are some actions on quest objects that I assumed act as triggers when you activate them, but I haven't looked into it.

Thank you! If you need any info, please don't hesitate to ask in forums or send me an email. I'm looking forward to us bouncing work around again.

I haven't seen anything relating to action object system yet, but I will be the first to admit I'm still climbing the knowledge ladder and I can't see the top rungs yet. And my job is that much harder because I don't just have to understand Daggerfall's quest system and Tipton's Template, I also need to abstract all that into Unity in a way that makes sense and be used by multiple people, then build all the related systems. I'm just working from the bottom up and trying to find practical solutions to everything without getting overwhelmed.

I am also interested in helping, I am especially interested in quest place resources.
Hope I can find some time in the next weeks for getting started (although I will be completely lost in the beginning I fear)

Thankyou Nystul. I'll put some condensed information together regarding location and quests for you. It might help you get started a bit faster, or at least scope out some of the various moving pieces.

LypyL wrote:If we need to lookup the "parent" component (or just the quest object itself) from a child, what is the best way to do that?

This is a little rough right now and depends on your starting point.

For actions, the owning Task passes a reference to itself when calling Update() on Action.
For tasks, the owning Quest passes a reference to itself when calling Update() on Task.

This will change soon because a tasks and actions will always need to know their owning Quest to perform lookups on other resources (like messages, places, etc.).

On a slightly related subject: currently quest system ticks once per Unity update. I'm debating whether any quest will need per-frame time resolution. I might change this to tick quest system say 10-30 times per second instead. This will keep quest overheads down quite a bit.

If you have something in mind, let me know where you're starting (either here or send an PM/email, whatever's easiest) and I'll work in the framework changes to assist.