[HOWTO] How To: Monitor Conditions in Custom Quest Conditions
Posted: Fri May 17, 2024 9:47 am
When writing a custom quest condition, the condition may not be true as soon as the condition's quest node becomes active. Here are 3 ways to check for quest conditions that may become true after the quest node has become active:
1. Listen for messages from the message system. See MessageQuestCondition.cs for an example. In StartChecking(), it calls MessageSystem.AddListener(). In StopChecking(), it calls MessageSystem.RemoveListener().
2. Register for some C# event from your own code. See CounterQuestCondition.cs for an example. In StartChecking(), it registers with the counter's changed C# event. In StopChecking(), it unregisters.
3. IQuestTimer. Either of those ways above are preferable. But if you can't do either one, you can implement the IQuestTimer interface. In StartChecking(), call QuestTimerManager.RegisterTimer(). In StopChecking(), call QuestTimerManager.UnregisterTimer(). Every 1 second, Quest Machine will run the condition's Tick() method. You can check conditions there. See TimerQuestCondition.cs for an example.
1. Listen for messages from the message system. See MessageQuestCondition.cs for an example. In StartChecking(), it calls MessageSystem.AddListener(). In StopChecking(), it calls MessageSystem.RemoveListener().
2. Register for some C# event from your own code. See CounterQuestCondition.cs for an example. In StartChecking(), it registers with the counter's changed C# event. In StopChecking(), it unregisters.
3. IQuestTimer. Either of those ways above are preferable. But if you can't do either one, you can implement the IQuestTimer interface. In StartChecking(), call QuestTimerManager.RegisterTimer(). In StopChecking(), call QuestTimerManager.UnregisterTimer(). Every 1 second, Quest Machine will run the condition's Tick() method. You can check conditions there. See TimerQuestCondition.cs for an example.