Bjørn wrote:
Quest Update { Quest Id, Flags [ State, Title, Description, Goal ] }

Do we need the "state" field? Since while quests arn't finished, they are active, when they gets finished for whatever reason (success, failure, cancelation, ...) they are destroyed on server side.

Also issuing warnings when the interval goes down too low and errors when it drops to zero can also be helpfull

Ablu, don't listen to him. Knowing how long the gameloop takes to execute is actually important, and as you noticed, knowing the interval between them is also very important, as it's the best indicator of how well or bad the server is doing.

I prefer the second option, the first one can get out of hand very fast.

I was constantly thinking how to implement dynamic quests... If we don't keep finished quests history, we could reuse quest ID for that. +1 bjorn However I would keep a simple, text based history in form {string quest_title, int timeout}, so when I see in the log "Quest finished" and I hav...

maybe quest with parentid is better, but we must limit the depth of that relation to one

I think a subquest structure should be something like: subquestId, questId, Text, State [open/done]

Failed can be simulated by "categories" if they are not clientside only, if not, I think it's safe to skip it.

Main / Side quests or categories in general can be done either with a type parameter (byte) or totally client side, based on quest ID (so network/manaserv part isn't affected and this can be added later). Old quests can be heavy on the network, so a GUI with tabs Open Quests / Completed Quests [ / F...

Ok, so there is Ablu's commit ( link ) from a year ago. But the main question is how do we want the questlog to work. Is it just a simple log a player should use as a general hint of stuff to do, or a more complex backlog with failed/successful quests, divided into smaller tasks, categorized (like P...