Pixel Crushers Forum

Hi,
(And sorry for the delay in your post appearing here. The forum was set to require moderator approval of new users' first posts to reduce spam. Other anti-spam measures are in place, so I just now disabled that setting.)

That's a really good question. The short answer is to use this format when you know a node may be linked from another conversation:
where 42 (for example) is the conversation ID of node 56's conversation.

I'll provide the long answer in the next post.

The long answer:

The Dialogue System's internal data structure is based on Chat Mapper. It's robust and proven (which is why I chose it), but it does have a quirk with the Dialog[#] table.

Internally, SimStatus values are stored in a tiered set of tables:

Conversation[conversationID].Dialog[dialogueEntryID].SimStatus

The Dialog[#] table is merely an alias for the current dialogue entry's conversation.

Let's say conversation 1 - dialogue entry node 3 (aka 1.3) has a link to conversation 42 - dialogue entry node 56 (aka 42.56).

When the Dialogue System gets to 1.3, it evaluates the conditions of all of its links. It's currently in conversation 1, so the Dialog[] table refers to conversation 1. However, the link points to 42.56. In this case, you can't use "Dialog[56]" by itself because the Dialogue System will think you're talking about Conversation[1].Dialog[56]. Instead, you need to use "Conversation[42].Dialog[56]".

I prefer not to fiddle with ID numbers when possible. If I only need to remember the status of a few nodes, I'll usually turn off SimStatus on the Dialogue Manager and just define some variables instead. Then I can set the Conditions field to something more understandable to me, like:
and in the appropriate node I'll use Script field to set the variable true: