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:
Code: Select all
Variable["insultedTheKing"] ~= true
and in the appropriate node I'll use Script field to set the variable true:
Code: Select all
Variable["insultedTheKing"] = true