Pixel Crushers Forum

1/ Ok, I understand, thank you! In fact, I'm not sure that it is the way to go... Yes, it fixes the link order problem but only in a specific situation. I agree that this node configuration is a very common case (I use it a lot), but there are too many situations where it won't work and we'll have to be hyper careful about adding extra nodes sometimes but not always. It won't work if group[9] is replaced by 2 or more following nodes. Or if in articy the group[9] is a condition, it will be converted to 3 groups by the dialogue system. I find it simpler to remember just one rule, a rule that is valid in all situations.
Moreover, the fact that unblocking [10] results in playing this node (and all following groups!) twice is dangerous: it means making double increments, calling scripts twice...

2/ On this setup :
This configuration works with the link order 1 2 3, but with 3, 1, 2 (link 3 is below normal priority) it loops infinitely. Even with the last patch. Here, the solution could be to unblock all links starting from [1] and beyond only in the case when we go back (with a link) to a previous node that has already made its child evaluation (and blockings). That means, in this example, when the "try again" goes back to group[1], already "displayed" before in this group path. But it should not unblock groups made before group[1]. I suppose it requires storing additional information while the Dialogue System evaluates and progresses into a group path.

I'm sorry that this "linear group mode" turns to something so complex... I couldn't have imagined we'd run into so many new problems! It's up to you to tell me if we should forget it, if it's the case I'll respect your decision and will update my dialogues in articy accordingly. And if you want to continue, I'll continue to test the patches and to provide feedback.

I don't think there's a hard and fast rule that handles all cases. Correct me if I'm wrong, but it seems like some decisions are context dependent. If this is the case, perhaps it's best to use the most restrictive interpretation that blocks more than you might want to block, as in:





and then add a custom property in articy to specify that certain group nodes should not be blocked. Would that work for your project?

Tony Li wrote: ↑Wed Jun 19, 2024 3:54 pm and then add a custom property in articy to specify that certain group nodes should not be blocked. Would that work for your project?

I don't think it will help... In the example below, disabling blocking on group[10] would result in the same problem that I was facing before you add the linear group option: when blocking on a false link on the group path, it will evaluate group[10] and all its following nodes a second time.
Another idea for the common case above, would it be possible to delay disabling of group[10] one step later? If it could happen just after the evaluation from [9] to [10] (after it's validated), it would work nicely.

That might work! I'll test it tomorrow.

Please give this a test:

DS_EvaluateGroupsPatch_2024-06-21.unitypackage

It passes all of my tests, but it's possible there are some scenarios you've set up that I haven't made tests for.

Thank you

This is...amazing! Everything (and more!) seem to work now, it passes all my tests too

Even this case works...
And the situation with the random int and the "try again" loop, it looks fixed as well!
Would you tell me (roughly) how did you manage to handle such special cases?!

Hi,

I just shifted the "disallow" code until later. This gives evaluation time to check the proper paths before blocking things off.

Hi there!

Can't believe the solution was so simple, well done! I've tried the patch on my group-based-mega-conversations and I see no problem. I'm very, very relieved to know that I can keep my articy conversations without having to add many extra nodes

Other thing, do you remember that I had a problem with the vertical order of my articy's nodes not being respected after the conversion? I think I've found the problem, in the ArticyConverter script, in the function BuildDialogueEntryFromInstruction, isn't a line missing, like for the other kind of node conversion? It solves my problem, apparently.

Good catch. I'll add that missing line.