Recommended way for working with ORK UI

[mdz_grs]

I've been trying to make the Standard Dialogue UI with ORK's built-in UI system and I've encountered some problems. I've been working within Makinom to leverage most of ORK's systems.

Unlike ORK's dialogue node, the Start Conversation Node immediately triggers the next Makinom node. Using the Standard Dialogue UI to work with other ORK dialogue or UI Boxes is a bit tricky or processing any changed state that was the result of the conversation since it doesn't wait for the conversation to end.

Secondly, I'm having problems reading the Makinom variables from using the Makinom Lua functions. Do they work for local variables set in the Schematic or should I be using global variables?

[Tony Li]

Hi,

Unlike ORK's dialogue node, the Start Conversation Node immediately triggers the next Makinom node. Using the Standard Dialogue UI to work with other ORK dialogue or UI Boxes is a bit tricky or processing any changed state that was the result of the conversation since it doesn't wait for the conversation to end.

Use a Check Conversation Active node to wait until the conversation has ended.

Secondly, I'm having problems reading the Makinom variables from using the Makinom Lua functions. Do they work for local variables set in the Schematic or should I be using global variables?

Unlike the Lua node, which can store the result in a local or global Makinom variable, the makiGetXXX() Lua functions specifically check the values of global Makinom variables.

[mdz_grs]

Hi,

Yea to wait for a conversation to end I used the Check Conversation Active and a wait node to wait for the conversation to end. As for local variables, I ended up initializing Dialogue system variables with the local Makinom Variables using the run Lua node before starting a conversation and I would copy back or use any Dialogue system variables back into makinom variables so that they could be easily processed by the ORK/makinom nodes. But it's still good to get a confirmation that what I was doing wasn't wrong or suboptimal, so thank you for your response. I know you mentioned only using one quest system. But I still found it useful to define a parallel/mirror quest entry in Dialogue System, to make it easier to group any Dialogue System variables that are related to a quest conversation...

I've also noticed that there is a LUA function called "orkChangeQuestTaskStatus" but there is no equivalently named function called "orkGetQuestTaskStatus" only "orkGetQuestStatus". I haven't had a chance to test it, but is it safe to assume that you can pass in a Task name into "orkGetQuestStatus" to get the current task status?

Also when calling the "orkStart(machine, startingObject)" is there anyway for the Conversation to pause and wait for the Machine to finish before resuming the conversation?

[Tony Li]

I've also noticed that there is a LUA function called "orkChangeQuestTaskStatus" but there is no equivalently named function called "orkGetQuestTaskStatus" only "orkGetQuestStatus". I haven't had a chance to test it, but is it safe to assume that you can pass in a Task name into "orkGetQuestStatus" to get the current task status?

I'll check if this is possible and, if so, I'll add it to the next release's integration.

Also when calling the "orkStart(machine, startingObject)" is there anyway for the Conversation to pause and wait for the Machine to finish before resuming the conversation?

Same for this. If it's possible, I'll add it to the next release's integration.

[mdz_grs]

I'll check if this is possible and, if so, I'll add it to the next release's integration.

So I took a look at DialogueSystemOrkBridge.cs and implemented orkGetQuestTaskStatus by looking at how orkGetQuestStatus was done. The Task class also implements IsStatus the same as the Quest class. So I guess it was missed?

[Tony Li]

Yes, I just missed adding that one. It'll be in the next update.