Difference between revisions of "Osiris/Shared/DB QuestDef State"

From Divinity Engine Wiki
Jump to: navigation, search
m
m (Tinkerer moved page Osiris/Shared/DB QuestDef Sate to Osiris/Shared/DB QuestDef State: typo in page name spotted by an esteemed colleague)
 
(3 intermediate revisions by the same user not shown)
Line 21: Line 21:
 
'''DB_QuestDef_State'''('''"RatKillQuest"''','''"FoundInfestation"''','''-1''') does the same for '''DB_QuestDef_CloseEvent'''().
 
'''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 character associated to this same '''_QuestName''' via '''DB_QuestNPC'''().
+
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 =====
 
===== 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.
 
* 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.
Line 27: Line 27:
 
** Party accepts quest '''RatKillQuest''', which is defined in the journal as a sharable party quest.
 
** 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'''
 
** 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.
+
** 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.
 +
 
 
===== See Also =====
 
===== See Also =====
 
* [[Osiris/API/QuestAdd|QuestAdd]]
 
* [[Osiris/API/QuestAdd|QuestAdd]]
Line 33: Line 34:
 
* [[Osiris/API/QuestClose|QuestClose]]
 
* [[Osiris/API/QuestClose|QuestClose]]
 
   
 
   
[[Category:Osiris Shared Mod Helpers]]
+
[[Category:Osiris Shared Mod Helpers|QuestDef State]]

Latest revision as of 09:49, 21 December 2017

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.
See Also