- summary: The character's whole quest journal: quests under way with their current step, finished quests, and reinitialised ones. A full replacement; nothing is sent back.
- area: Game.Quest
The character's whole quest journal: quests under way with their current step, finished quests, and reinitialised ones. A full replacement; nothing is sent back.
Kind event · Area Game.Quest
WHAT TO DO WHEN YOU RECEIVE IT
1. Throw away the journal you hold and rebuild it from this message - see below.
2. SEND NOTHING BACK. No handler of this message builds a request. The one request a
static walk reaches from it is the tutorial's own step query, raised by the
tutorial screen for its special quests - not something the journal requires.
3. If you need the step of one quest refreshed later, ask with
QuestStepInformationRequest; the journal itself is complete.
WHEN IT ARRIVES. The client asks for it - its journal request (QuestsRequest, no signature here) goes out when the quest list or the quest tab opens and when the calendar refreshes.
The server's statement of the character's quest journal. One message carries three lists:
QuestsEvent.active_quests, QuestsEvent.finished_quests and
QuestsEvent.reinitialized_done_quests_id.
IT IS A SNAPSHOT, NOT A DELTA. The client does not merge it into what it already holds. On every arrival it throws away its list of active quests, its list of finished quests, its list of reinitialised quests and both of its objective lists, and rebuilds all five from this one message. A journal that omits a quest has dropped that quest. Treat each arrival as the complete truth and replace your own state the same way.
WHAT THE CLIENT BUILDS FROM IT, in this order:
1. one journal entry per QuestActive, keyed by its quest id and holding the id of the
step the quest is on (Details.step_id);
2. the finished list: the QuestFinished.quest_id of every entry of finished_quests;
3. the reinitialised list: every id of reinitialized_done_quests_id;
4. for each active quest, every QuestObjective of its current step, sorted into still
to do and done, with its progress pair and its text parameters when it carries any;
5. for each finished quest, every objective of every step the game data declares for that
quest, all marked done;
6. last, the reinitialised ids are APPENDED TO THE FINISHED LIST.
Step 6 is the one to remember. A quest id listed in reinitialized_done_quests_id counts as finished for the client even when finished_quests does not list it; the reinitialised list is kept on its own as well, so the two can still be told apart afterwards.
QUEST IDS ARE 16-BIT ON THE CLIENT. Every id - active, finished, reinitialised - is narrowed to a signed 16-bit value before it is stored, although the wire declares int32.
TWO MEMBERS THE CLIENT NEVER READS: QuestsEvent.player_id and
QuestFinished.finished_count. They are part of Ankama's contract and the server may fill
them, but nothing in the client depends on either. Do not build logic on a meaning this
catalogue cannot observe.
Once the journal is rebuilt the client raises its quest-list-updated notification, which is
what refreshes the quest window, the calendar and the group-finder tab. The journal only
describes the step each quest is currently on; QuestStepInformationRequest asks for one
quest's step again.
When you may send it
- Requires
character_selectedinferred
Related messages
- Reply not yet recovered: the client asks for the journal with QuestsRequest, which has no signature here. On 3.2.7.15 it sends that request whenever the quest list or the quest tab opens and when the calendar refreshes; whether the server also pushes the journal unasked is not established.
Fields
| # | Field | Type | Meaning | You set it |
|---|---|---|---|---|
| 2 | reinitialized_done_quests_id | repeated int32 | Ids of finished quests that have been reinitialised. (quest id) The client stores these on their own AND appends them to its finished list, so an id listed here counts as finished even when finished_quests does not carry it. | never |
| 3 | player_id | int64 | Whose journal this is. Explicit presence: absent is not the same as zero. (character id) Never read by the client on any dumped build, the unobfuscated beta included, so its meaning rests on Ankama's name alone. Named only on builds that declare a single optional int64; where a second one is declared it stays obfuscated rather than being picked by position. | never |
| 5 | finished_quests | repeated QuestFinished | Every quest the character has completed. A list of QuestFinished. The client keeps only each entry's quest id, and rebuilds its finished list from scratch on every journal. | never |
| 6 | active_quests | repeated QuestActive | Every quest the character has under way, each with the step it is on. A list of QuestActive. Some builds declare a second list of the same type beside it; the client never reads that one and it stays unnamed. | never |