Best practice for a quest that can be retried?

[nratcliff]

I am trying to set up a quest in which the player must talk to an NPC to start a race, do the race, then return to the NPC to check whether they were fast enough. If they fail, the quest should continue to display in the quest log with a message like "Win the race." The player should be able to talk to the NPC to try the race again.

The race timing and conditions are handled by a script outside of the quest, and the nodes progress based on messages from the race script. The quest itself is pretty simple:

Screenshot 2023-03-01 at 3.05.44 PM.png (22.43 KiB) Viewed 1074 times

I followed the guide here to set up the quest to restart, with a couple of modifications. Mainly, the quest is restarted from Dialogue System Lua, and I'm setting the failure node to inactive on quest active because it was getting stuck in the active state after restarting.

Screenshot 2023-03-01 at 3.09.39 PM.png (20.39 KiB) Viewed 1074 times

Screenshot 2023-03-01 at 3.08.05 PM.png (57.74 KiB) Viewed 1074 times

Screenshot 2023-03-01 at 3.08.36 PM.png (10.51 KiB) Viewed 1074 times

I have two issues:

1. After the first restart, the quest HUD text disappears and does not return.
2. The quest does not reach the end after the 2nd restart. The win/lose nodes become active but the state fails to pass through the lose node into the failure node.

Screenshot 2023-03-01 at 3.16.38 PM.png (24.52 KiB) Viewed 1074 times

The win/lose nodes have a simple Lua condition check (this is the lose one):

Screenshot 2023-03-01 at 3.11.40 PM.png (9.71 KiB) Viewed 1074 times

What's the best way to do what I'm trying to do here? Happy to change my approach in any way.

[Tony Li]

Hi,

The player can never really fail the quest, right? It sound like, once accepted, the quest stays active until the player wins the race. If this is the case, you could change that failure node to a node that either resets everything so "wait to start" is the active node (and nodes below it are inactive), or you could add another branch that shows different text instead of "wait to start" such as "Ready to try it again?"

[nratcliff]

Just came here to say I've tried that approach and while the journal text does remain visible (yay!), the lua condition check nodes still fail to progress on the second go. I've tested and the value is still false but for some reason the condition nodes get stuck active.

Screenshot 2023-03-01 at 3.53.55 PM.png (27.73 KiB) Viewed 1068 times

[nratcliff]

Aha, seems I managed to bump into a little bug here. If the condition being checked for is true when the node is activated and starts checking for conditions, the node state changes to True before m_isCheckingConditions is set to true, so the call to SetConditionChecking in SetState that should disable checking doesn't do anything (checking is still false). Then, after the state updates in the frame (and the next node sets the condition-checking node to Inactive), m_isCheckingConditions gets set to true. The next time the node is activated and condition checking should start, isCheckingConditions is already true but the conditions aren't actually active.

Screenshot 2023-03-01 at 4.12.15 PM.png (39.58 KiB) Viewed 1064 times

Screenshot 2023-03-01 at 4.12.36 PM.png (67.29 KiB) Viewed 1064 times

Moving the m_isCheckingConditions assignment above the if statement block fixes the issue!

[Tony Li]

Hi,

That change is in the repo for version 1.2.34, so you won't have to reapply your fix when you update.

[nratcliff]

Hey Tony,

Just a heads up: I updated to 1.2.34 from the Asset Store today and actually did end up having to re-apply that change. m_isCheckingConditions was moved back to the bottom after importing the package, and I ran into the same issue as above. Applying the change fixed it though!

[Tony Li]

Sorry, I was unclear. The current version on the Asset Store is 1.2.33. The upcoming version 1.2.34 (early next week) will have that change.

[nratcliff]

Ah whoops! I should have read a little closer, too. Thanks as always!