Generated quest {TARGETDESCRIPTOR} in dialogue incorrect

[nratcliff]

We're using Quest Machine + Dialogue System as well as the quest generator for our quests. One quest we have asks the player to decorate the questgiver's village with a random number of items (wooden crate, post light, etc). This mostly works (with some hacking to quest generation to support things like random goal numbers), but I'm getting a bug with the quest dialogue.

In a scene with a handful of NPCs who all generate a decorate quest, they all ask the player to put the post light around town, even though their quest is for something else, like the wooden crate. Digging into it, it looks like DialogueSystemQuestMachineBridge is replacing the {TARGETDESCRIPTOR} tag with the value from a cached quest instance which is set to an instance of a generated post light quest. I think this is because SetCurrentQuestID in DialogueSystemQuestMachineBridge does not update the quest properly. Not sure exactly what's going on but a quick look shows that the "QuestID" field on the conversation is set to a post light quest even when the current conversant has a different quest. Maybe this is because the generated quests are sharing a conversation instance?

Would love some help getting this worked out!

[Tony Li]

Hi,

Is the DialogueSystemQuestMachineBridge component on the Dialogue Manager GameObject? If so, can you put a breakpoint the OnConversationStart() method (line 605)? Let's make sure it's receiving the "OnConversationStart" message, which makes it clear the cached quest.

Can you also confirm that the quest IDs are unique for the generated quests? They should be, since the generator adds a new GUID to each generated quest's ID.

Regarding your hacked-in extra functionality, let me know if any C# event hooks or virtual methods would allow you to add that functionality without having to directly modify Quest Machine / Dialogue System scripts. In the long run, it'll make life easier for your game because you won't have to keep track of your customizations to the scripts.

[nratcliff]

Is the DialogueSystemQuestMachineBridge component on the Dialogue Manager GameObject? If so, can you put a breakpoint the OnConversationStart() method (line 605)? Let's make sure it's receiving the "OnConversationStart" message, which makes it clear the cached quest.

Yep on both. the bridge is attached to the Dialogue Manager GameObject and OnConversationStart is called, setting m_currentQuest to null.

Can you also confirm that the quest IDs are unique for the generated quests? They should be, since the generator adds a new GUID to each generated quest's ID.

Yes, the generated quest IDs are unique (looking at the quest giver's quest list in the inspector). The current conversation's "QuestID" field is not set to the quest ID for the current quest giver's quest though, it is always the same value.

Regarding your hacked-in extra functionality, let me know if any C# event hooks or virtual methods would allow you to add that functionality without having to directly modify Quest Machine / Dialogue System scripts. In the long run, it'll make life easier for your game because you won't have to keep track of your customizations to the scripts.

I'll circle back on this sometime in the new year when we're not under a big milestone deadline.

Full transparency: we're already planning to move away from the quest generator in favor of a combination of prewritten quests with some random bounds (like randomized goal counters) and some custom scripting to select/"generate" those quests. While it seems fitting for the provided demo, the quest generation system seems too limited for our use cases unfortunately.

I can definitely still let you know what problems we ran into and where we had to make changes!

[Tony Li]

I think this patch should fix the issue:

QM_DSPatch_2022-12-13.unitypackage

[nratcliff]

That did the trick! Thanks for the swift fix as always!!

[Tony Li]

Glad to help! Thanks for letting me know about the issue.

[nratcliff]

Regarding your hacked-in extra functionality, let me know if any C# event hooks or virtual methods would allow you to add that functionality without having to directly modify Quest Machine / Dialogue System scripts. In the long run, it'll make life easier for your game because you won't have to keep track of your customizations to the scripts.

Ok! Finally have some time to circle back on this.

I think the easiest thing to do would be to outline what hacks we made and why:

1. Support for random required values for generated quests.

As far as I can tell, there is no way to randomize required values for generated quests. In fact, the required value is always based on the amount of the entity in the domain (fact.count). I added properties to ActionCompletion that let me specify a range of random values if I wanted to use those instead of the default entity count. There are a few places where the entity count is hard-coded as the assumed required value, so I had to replace all of those (PlanStep, PlanToQuestBuilder, QuestGenerator).

2. Randomly select from equally urgent actions rather than always select the first one

Our use case calls for many situations where a quest giver has equally urgent actions based on their current world model. In this case, we want a random action to be chosen to create some variety as well as prevent the others from never appearing in the game. I modified QuestGenerator.DetermineGoal to select the lowest weighted urgency or randomly replace the best candidate if the urgencies are equal.

3. Events on entity added/removed from quest domain

The main reason I added this is to allow generated villages (with a village quest domain) to send a message notifying quest givers in the village that an entity was added. This was important in our case for generated quests that required the player to place something in the village like furniture or plant a certain kind of plant. We didn't want the notification to be sent for any item placement, only those within the village domain.

4. Generated quest counter message conditions always have "any" target specifier

There is no way to set the targetSpecifier for the generated quest counter message event, which we needed for our use case. Because our NPCs are generated at runtime, we need to be sure that the targetSpecifier was set to Quest Giver so the appropriate target was assigned/notified. This allowed 3 to work because the village would notify each of the NPCs with messages that targeted them directly.

5. Weighted random algorithm in QuestGenerator.ChooseWeightedMostUrgentFact doesn't seem to work (bug?)

I noticed some issues with the values being returned from ChooseWeightedMostUrgentFact and on digging into it I found an implementation of weighted random that I'm not familiar with. Maybe it's just a lack of my understanding but it didn't seem to be selecting a random fact by weight in the way I expected. I replaced it with the standard strategy of checking if randomValue is less than the weight (fact.value) and then subtracting the item's weight from randomValue if not.

6. Runtime drive values don't always update when changed (bug?)

ResetRuntimeValues never seems to be called, which creates issues when changing an entity's drive values after exiting playmode because m_validatedRuntimeDriveValues is serialized and keeps its value on exit playmode. Until adding some code to call ResetRuntimeValues() when exiting playmode in the editor, we frequently had issues with drive values not actually applying to the generation. This was a particularly nasty bug because it took a lot of stepping through the generation process to figure out that the drive values shown in the editor were not the same as the ones going to the generation system.

Hopefully this is helpful! I'm happy to follow up with more detail if needed.

[Tony Li]

Hi,

Thank you very much for the detailed writeup. I think most of these issues are already fixed in the current version on the Asset Store or in the upcoming release. I'll check QuestGenerator.ChooseWeightedMostUrgentFact again. Maybe there's an issue with my unit test for that.