Pixel Crushers Forum

Hi Tony,
I've tried with the new package, I still have the stack overflow issue.

Could you, in your articy project:

- add a hub just after the start of the conversation, allowing only one pass (for me it's a simstatus check in the input pin & a simstatus set in the output pin) - set the low priority on the "try again" link: I want to be sure that it happens only after the evaluation of the 3 other nodes (the converter does not preserve my articy nodes vertical order here. In articy from top to bottom I have A - B - C - TryAgain, but in the database from left to right I get B - C - A - TryAgain).

- add a jump at the end, going back just before the simstatus check (at the beginning of the conversation) .

In my opinion, when it blocks on this simstatus check (just after the dialogue system makes the jump), this should mark the end of the conversation. But instead, it keeps evaluating the random int value on the nodes that haven't been evaluated yet. Do you get the stack overflow error with this setup?

Hi,

Can you try this Unity scene and articy:draft 3 project?

Unity scene: DS_ArticyTest_2024-06-06.unitypackage

Articy project: DS_ArticyTestProject_2024-06-06.zip

The articy project looks like this:
It imports into Unity like this:
using these import settings:
When I run the scene, it loops until it hits a valid number, then it stops.

Also, sort of unrelated, are dialogue nodes not being imported in order according to their vertical positions? For example, in the articy screenshot above, the "Links To:" section will be "x==1", "x==2", and "try again".

If I move the "x==2" above "x==1", reexport from articy, and reimport to Unity, the "Links To:" will be "x==2", "x==1", "try again".

Thank you for the scene! I think I've found the problem. The difference between your articy project and mine is the nodes evaluating the int (x == 1 etc...). I have instructions nodes (converted into groups), while you have dialogue fragments (converted into regular nodes).
In your setup, it seems that when the condition is met, the dialogue entry is spoken and the dialogue system "selects" this dialogue path (other branching conditions will never be evaluated).
In my setup, with groups, when the condition is met (ex: x == 1) it continues evaluating all the groups following that node, and when it blocks on a false link (ex: simstatus), it goes back to the initial branching and it tries the other conditions (ex: x == 2).

When we have a branching with conditionnal groups, if a group has its condition met, it should never evaluate the other groups, right? With regular nodes I think it works like that. Groups should be evaluated the same way, I guess. But maybe it's not possible without breaking something else...

Just an idea: does it has something to do with the Continue() sequence that is played in your example? It's not played in mine, of course, because I have only groups.

For the nodes order, this is what I have in articy: And what I see in the database: I noticed this after the last official update of the Dialogue System, some days ago. But I'm not completely sure it was not there before. I tried disabling the reorder ID option, same result. I think I can do some additional tests in a few days to try to find the cause. For many other dialogues, the order is respected.

Hi,

Can you set "Instructions As" to "Regular Entry"?

The nature of group nodes is that they will evaluate until they exhaust all possibilities, but your current setup creates a logical infinite loop. When evaluation gets to [259] (Jump to <Act1>), it evaluates Act1, and then Act1 evaluates the simStatus check which is false, so it backtracks to [259], then back to e.g., [255], then back to [253], and then it tries [257], which just starts the loop again.

If your checkpoints A, B, & C were regular nodes (e.g., dialogue nodes or instructions imported as regular entries), then the group evaluation would end there. Then they would accept those nodes and then proceed to the jump node.

With the latest patch (or maybe the one before), it should work now. In my reproduction articy project, I changed the nodes into instruction nodes:


I used the same import settings as before and verified that it would cause a stack overflow. (In version 2.2.47, this will instead abort when it hits a looping depth of 100 to prevent the stack overflow.)

Then I changed "Instructions As" to "Regular Entry". It created this conversation, which runs just fine without an overflow:

Hi there

Yes, it work as expected with the regular setting for instruction nodes! Great.

I was not aware that the group nodes have a such different behavior (going forward and backwards). It may be useful, but also dangerous...let me explain it with this articy project (please download it):

https://www.mercygroundcreations.com/dl ... -06-08.zip

Rest assured that I'm not trying to put the Dialogue System to the test just for fun: I'm still encountering the issue in another conversation, and thanks to the example you provided before, I think I've found why it is still failing, even with regular nodes. The articy project above brings my problem into focus.

Even with regular nodes option in the converter, conditions and hubs are still converted into groups. It's a problem, here.
In the example above, the variable "x" can be set to 0, 1 or 2 (manually).
Depending of it's value, x is evaluated by an instruction node, a hub or a condition node.
The "High Priority Hub" is always evaluated to true, it's there to show that this kind of node (group) adds a layer of complexity.

If x == 0:
X is set to 0 -> High Priority Hub -> Another Hub -> x is set to 42 -> Jump to Act1 -> Block on SimStatus check.
Conversation ends. This result is what is expected.

if x == 1
X is set to 1 -> High Priority Hub -> Another Hub -> Untitled Hub -> Jump to Act1 -> Block on SimStatus check -> Block on x == 2 -> Evaluate group Another Hub (true) -> Block on x == 0 -> Untitled Hub -> Jump to Act1 -> Block on SimStatus check -> Block on x == 2.
Conversation ends. Some parts of the conversation are "read" 2 times.
If x == 2
The same as x == 1, approximately.

I understand your explanation of how groups work and why some parts of the dialogue are read 2 times, but having such different behaviors just depending of using an instruction, a hub or a condition node is a problem, in my opinion.
To handle my game logic, I need this kind of dialogue authoring:
Or this again, without any dialogue entry, just hubs, instructions and conditions:
...and this is just the end of the conversation! So I let you imagine how it can turn into a nightmare when I see that many of my scripts are executed and evaluated twice in this kind of conversation.

About possible solutions, let me add some thoughts:

• Maybe you should remove the option to convert instructions as groups. As long as groups don't behave like regular nodes, I think it's very risky to allow the user to use it.

• What about converting groups, conditions and instruction to regular nodes systematically? I guess it could be a great fix. But it means a lot of more fields in the dialogue entries (localization fields especially) and it would execute lots of sequences (OnContinue) & send lots of Unity messages (OnConversationLine...) for nothing. Optimizable, perhaps?

• Or maybe, an option just to align the behavior of groups to the behavior of regular nodes: in a branching, if a condition is met, the branch is "selected" and the other branch will never be evaluated. I'm not sure about this one, because in some cases it could be limiting.

• Or keep the original behavior, but add these limitations (about conditions and hubs converted to groups and what it means) to the articy documentation. Plus, if it's not present yet, something about the specific behavior of groups.

Thank you for reading

Hi,

Thanks for the detailed explanation of your scenario and your suggestions. I'm going to give this some thought and do some testing before committing to a solution. I'm leaning toward offering an option to follow a group node if it's true but not also follow sibling group nodes in that case (i.e., the next-to-last suggestion in your list above). As you said, it could be limiting, but in this case it wouldn't be any more limiting than articy, so it's probably fine.

Scratch that. It's not going to work in a case that's commonly used. Devs will often refactor a conversation like this:



into this:



in which case both siblings ({group}A and {group}D) need to be evaluated.

I'll check how articy handles your scenario and make sure the Dialogue System has an option to do the same thing.

Indeed, in this kind of case it's limiting. But it's funny, how everyone may have very different ways to handle the logic behind its project. As an example, to achieve what you posted above, I could never have imagined that the dialogue system would go backwards to evaluate the group D if group A doesn't have a valid dialogue entry. To accomplish that, I'd rather have used a jump at the end of the "group A" paths to go back to the group D, or to the START node, with something like a simstatus to avoid making a loop going to group A again.

In 99% of cases, my conversations follow a "funnel" logic, quite linear, evaluating by example the current level, then the story advancement (the "Act"). Say, as an example, we're loading the level PoliceStation, Act 1, but it blocks on a false link. It will evaluate all the other acts, then all the other levels, for nothing. Too bad.

I wonder how many users of the Dialogue System consciously make use of the groups' ability to go forward then backward. You're probably the best person to know Is the information somewhere in the documentation?
Anyway, it looks like an option to disallow groups going backward when they're in a dead end would fit perfectly to my project. I hope you'll find a solution! Take all the time you need

I'm still working out a clean solution, but in the meantime I'll try to better describe how groups work. When evaluating what dialogue entries (nodes) are available from the current dialogue entry, evaluation must end on one or more non-group nodes. You can think of it like water flowing through pipes. Group nodes are like valves that can stop the flow or let it continue. But there always needs to be a point (a non-group node) where the water can come out. The "water" comes out as a list of one or more non-group nodes. If there are no non-group nodes, the water just keeps flowing in an infinite loop.

Evaluation doesn't really go backward per se. It's that it's recursive. Looking back at this example:



Let's say evaluation goes to node 3. When we call the EvaluateLinks(node[3]) method, it evaluates 4, 6, and 7 by first calling EvaluateLinks(node[4]). This in turn calls EvaluateLinks(node[5]) and so on, which ultimately ends in a block because SimStatus is set to WasDisplayed. So then that whole stack of recursion finishes, and EvaluateLinks(node[3]) proceeds to 6, and that gets blocked, so it goes to 7, which goes calls EvaluateLinks(node[3]), ad infinitum. This is what we want to avoid, and I'm looking at some solutions that do that without adding any additional complexity.

For a more straightforward, typical example of how this recursion works, look at:



Let's say "D and F" are true. So the evaluation would be:
--> valid links: F.

I think I'm getting the picture now. Your metaphor sums it up nicely!

I sometimes use this feature for response menus, allowing to add a set of responses from elsewhere easily to the existing ones in the current conversation, like this:

The jump to the other group (placed in another conversation) "retrieves" its responses. Very handy, in some situations, even if it increases the risk of losing control on what's happening in more complex "gameplay" conversations with lots of conditions, hubs & instructions.

If you find no "win-win" solution, I think that I will reshape my conversations to take this behavior into account, by introducing empty dialogue fragments where I want to force "select" on a path, by example.