Pixel Crushers Forum

I see, this is quite obvious...too bad! I'm trying to find a way around it, but it looks quite unsolvable.

I'll have to keep that in mind in articy and to change some nodes configuration because it's a pattern I use quite often.

Many thanks for your help on this topic and for your time!

If a good approach occurs to you, let me know and I'll implement it.

Tony Li wrote: ↑Sun Jun 16, 2024 5:04 pm If a good approach occurs to you, let me know and I'll implement it.

I will, thank you!

Just a last thing: I've found a case when group[10] is not disabled. Based on the same setup as my last example (no condition involved, just a high priority link):
I just switched the links order, without changing the priority.

On the image on the left, it works as expected (group[10] disabled).
On the right, group[10] is not disabled, and if later on the path the dialogue system blocks on something, it tries to evaluate group[10] again (potential infinite loop, should not happen with linear mode).

Have a good day!

That's a bug. Consider it fixed in the next release.

Thank you. I've checked our previous example (with the random int), the same happens: the stack overflow exception is back when the "try again" group is not set to the last link.
Good luck!

Just sharing a few thoughts here for when you'll tackle our problem for the next release of the Dialogue System.
To get back to this example:
I guess that if you fix this last bug, making all other sibling nodes disabled whatever-the-link-order, the piece of dialogue above won't work anymore.
Because if "try again" is played, groups [6] and [7] will be disabled and won't be re-evaluated after a new random int is generated.

To fix this issue, we could:

- always add manually a regular node in the loop. If I understand well, it will "reset" disabled nodes. Quite easy, but it increases the risk of error when authoring dialogues, if you forget this step.
- allow the dialogue system to ignore disabled sibling groups in the case of a voluntary return.

I don't know if it's something feasible. If not, I'll stick to the first workaround.

I think the most common use case by far is this one:



In this case, if the child group node [9] links to a group node [10] that its parent [4] also links to, when it gets to the child group node [9] it will unblock [10]. This is technically a special case, but it probably covers the majority of actual uses in practice.

This is the latest update to group link evaluation if you want to give it a try:

DS_EvaluateGroupsPatch_2024-06-18.unitypackage

Hi Tony! What does the last update do? It doesn't seem to work, group[10] is played twice in my test scene

Hi,

In Linear Group Mode, when evaluation finds a link to a valid group node, it blocks all links to group nodes that appear later in the "Links To:" list and all links to lower priority group nodes even if they appear earlier in the "Links To:" list.

However, if the child group node ([9]) links to a group that the parent ([4]) also links to -- that is, [10] in the example above -- then it unblocks [10].