DyegoAlehandro

Nothing came up for this on the search for either this forum or Pixel Crushers, so I thought I'd start here.

I'm not sure if the issue is with ORK or with Quest Machine. I have a custom controller which I've got setup and working properly. When I access a normal ORK event that blocks camera and player control, (to show dialogue as a test) it works just fine.

However, when I try to launch a Quest Machine dialogue through an interaction event, even though I set the event as "blocking" and block player and camera control, when the Quest Machine UI shows up the controls are not actually blocked and I am unable to click on accept or decline for the quest.

Attempting to switch any of the built-in parameters for starting the Quest Machine dialogue event comes up with a "can't find quest giver."

If this is an issue with Quest Machine, I'll look for answers on the Pixel Crusher forums, but I thought I'd start here and see what I can find out. Thanks for any help!

gamingislove

Hm, I've never used Quest Machine and Pixel Crusher did the ORK integration, so I'm probably of little help here.

From ORK's perspective, if an event interaction starts an event, it'll first do the control blocks before going through the nodes - but if the quest machine node doesn't wait for that part to be finished and just continues with the event, the event will probably be over in the same frame, unblocking the controls at the end.

hellwalker

Ok, I checked and yeah that is happening.
StartDialogueNode does not wait for Quest Machine dialogue to be finished. You can ask PixelCrusher to add that feature or try modifying StartDialogueStep.CS to wait until dialogue is finished.

BUT. I have not messed with QM internals yet so can't say for sure. But, I think doing that on quest machine side can be problematic. I casually glanced at the code and depending on integrations and different settings What is actually a dialogue and when it ends can be hard to track.

So, to simplify things I would recommend that you have like a custom integration Manager.
And what you would do is you would have a Dialogue finished delegate in your Manager.
1) From Ork event you would subscribe to this delegate. And you would keep looping ORK event until you get feedback from this delagate.
2) On quest machine dialogue UI, on close button or whatever you Invoke a delegate in your manager telling it Dialogue has finished, and subsequently telling subscribed ORK event that it can finish too.

Alternatively, there might be something you can override inside quest machine and block ORK controls from there via C# command.

If you are not in a hurry, sometime next week I'll be doing my journal UI and will probably need similar solution and I could share my code with you.

DyegoAlehandro

Thanks to both of you for the answer! My instincts were telling me that it was on QM's side that was either overriding or not listening to Ork's blocking command. Never even considered it might be a timing issue.

@hellwalker I'm not in a huge rush so yeah, that code would almost certainly be handy! I'm going to bring this issue up on the Pixel Crusher forums anyway and see if anything can be done on future QM+Ork bridges. I think the main problem stems from my custom controller, so maybe there's something that can be done to help others who might find themselves in my predicament.

DyegoAlehandro

Tony Li of Pixelcrushers is looking into the issue, so perhaps soon we'll have another option.

PixelCrushers

Hi!

I replied here on the Pixel Crushers forum.

I'll recap here, too:

It's by design, as some devs may not want to block control when the quest journal is open or when showing the dialogue UI. The intent is that you'd set up your own event to block control when the dialogue UI is open, if you want to.

The Quest Machine Extras page has an updated ORK Framework integration package with an additional convenience component named ORKEventsOnPausePlayer that works similarly to the Dialogue System's ORK bridge component. If you add ORKEventsOnPausePlayer to your player prefab(s), it will automatically block control when Quest Machine's dialogue UI is open -- or, more precisely, whenever Quest Machine sends a "Pause Player" message. You don't have to do anything except add it to your player prefab. However, if you want to run extra events when Quest Machine sends "Pause Player" and "Unpause Player", you can assign them to this component.

(Note for future readers: If you're using Quest Machine 1.2.6 or newer, it already includes this updated package.)

DyegoAlehandro

The new additions seem to be doing the trick, but I'd still be very interested in seeing your journal solution still, @hellwalker . I might want to implement something similar, so thanks for the offer :)