Osiris/Shared/DB QuestDef State
Full Definition(s)
- DB_QuestDef_State((STRING)_QuestName,(STRING)_QuestState)
- DB_QuestDef_State((STRING)_QuestName,(STRING)_QuestState,1)
- DB_QuestDef_State((STRING)_QuestName,(STRING)_QuestState,-1)
- DB_QuestDef_AddEvent((STRING)_QuestName,(STRING)_AddEvent)
- DB_QuestDef_UpdateEvent((STRING)_QuestName,(STRING)_QuestState,(STRING)_UpdateEvent)
- DB_QuestDef_CloseEvent((STRING)_QuestName,(STRING)_CloseEvent)
- DB_QuestNPC((STRING)_QuestName,(CHARACTERGUID)_NPC)
Description
This database can be used to automatically define flags to add, and close journal quests, and to add progression entries to the quests. The _AddEvent, _UpdateEvent, and _CloseEvent parameters are the names of object flags. When such flags are set on a character, they will trigger, respectively, a QuestAdd, QuestUpdate, or QuestClose of the related quest or quest state on that character.
DB_QuestDef_State is a shorthand. For example, if you define DB_QuestDef_State("RatKillQuest","FoundInfestation"), then the following databases will be defined:
- DB_QuestDef_UpdateEvent("RatKillQuest","FoundInfestation","QuestUpdate_RatKillQuest_FoundInfestation");
- If no DB_QuestDef_AddEvent("RatKillQuest",_) has been defined yet, it will also define DB_QuestDef_AddEvent("RatKillQuest","QuestAdd_RatKillQuest");
- If no DB_QuestDef_CloseEvent("RatKillQuest",_) has been defined yet, it will also define DB_QuestDef_CloseEvent("RatKillQuest","QuestClose_RatKillQuest");
DB_QuestDef_State("RatKillQuest","FoundInfestation",1) is similar, but it will never define a DB_QuestDef_AddEvent() with the default event name as shown above. Instead, regardless of whether any DB_QuestDef_AddEvent()s have been defined already, it will define a DB_QuestDef_AddEvent("RatKillQuest","QuestUpdate_RatKillQuest_FoundInfestation"). I.o.w., this update event will at the same time also trigger the addition/activation of the quest if it was not yet active.
DB_QuestDef_State("RatKillQuest","FoundInfestation",-1) does the same for DB_QuestDef_CloseEvent().
Whenever a flag is set on a character that corresponds to a quest add/update/close event as defined using the above databases, this same flag will also be set on characters associated to this _QuestName via DB_QuestNPC().
Notes
- In many cases, you not only want to add an entry to the quest journal, but later you also want to check in dialogs whether or not a character did something already that is associated with a particular journal update. In as many cases as possible, you should use flags from these databases for that. The reason is explained in the following point.
- Apart from being a convenience feature, the logic behind these databases also takes care of quest flag sharing in case party members move from one party to another, or when you recruit a new party member. In the journal editor, you can mark a quest a Character, Party or User-level, and additionally whether or not is Shared. If a non-Character-level quest is marked as Shared and handled using these databases, and if the party has the quest unlocked but the joining party member does not (or vice versa), then all quest updates and update events/flags as defined above for this quest will be synchronised between the party and the new member. For example
- Party accepts quest RatKillQuest, which is defined in the journal as a sharable party quest.
- Party gains quest RatKillQuest update FoundInfestation by setting the party flags QuestAdd_RatKillQuest and then QuestUpdate_RatKillQuest_FoundInfestation
- New character joins the party -> the RatKillQuest is added for this character, it gets the FoundInfestation quest update, and additionally the QuestAdd_RatKillQuest and the QuestUpdate_RatKillQuest_FoundInfestation flags will also be set on this character. It keeps these flags and quest updates when it leaves the party.
