articy instructions not converted into groups?

[Tony Li]

It turns out articy doesn't address the issue at all in its presentation mode.

I think the best solution will be to:

• allow instruction nodes to be regular dialogue entries (not groups)
• if a hub or other would-be group node has output pin code, automatically make it a regular dialogue entry, not a group
• stop evaluation at a group node when that group node has already been checked.

I think this should handle all of the cases mentioned above.

[_marc]

So, in other words, in articy, if I have whatever-the-node running some instruction, it will always be converted to a regular node, so the Dialogue System will never evaluate the previous sibling groups, right?

Aren't you worried that some other users, used to seeing all their groups evaluated (like in your example with the refactoring), don't understand why the evaluation of other groups stops just because they put some script somewhere? I'm afraid that it would be useful to me, but a new problem for some others...

I think the most important thing is to have a consistent behavior between all kinds of articy nodes. Your solution goes in this way.

What about allowing the user to choose between 2 workflows for the behavior of groups?

- regular mode (default): the solution you mention in your previous post. It allows for the refactoring example you talked about. In the articy converter, all instruction-related nodes (including filled output pins) are converted to regular entries.

- linear mode: Force to not follow sibling groups if a group is evaluated to true, as you mentioned before. In the articy converter, make groups for everything that is not a dialogue fragment (conditions, instructions, hubs, with or without instructions in output pins). It would be quite consistent, and perfect for those (like me) who write their conversations in a more linear way, or who have a huge quantity of logical content. As I said before, this would allow for a much lighter, less complex converted database, with no localization fields, and no sequences to play for each instruction (easier to debug, as well, with fewer logs).

I think that each workflow would do the trick to avoid our problems. Maybe in this case It would not even be necessary to "stop evaluation at a group node when that group node has already been checked", as sometimes it could be necessary to go back to evaluate the same hub many times (I'm thinking about the "try again" node with the random pick we talked about before). But I'm not sure if it's concerned by your idea to avoid double-evaluation.

[lcn_mc]

Hey guys, wanted to jump into this thread with a side note for Tony about something I just observed in Articy after the Dialogue System's recent patch and figured it was better than making a standalone thread since maybe it's related:

• I've observed that conversation to conversation links no longer work after the most-recent Dialogue System for Unity update.

When I say 'conversation to conversation' links, I'm referring to one Dialogue object connected to another in Articy, as shown here:

An example of linked conversations in Unity.

ArticyExample_LinkedDialogues_061124.png (13.84 KiB) Viewed 103 times

Prior to the recent Dialogue System update, these conversations would've connected without issue, but now it looks like the link has broken and the linked conversation never occurs.

I can work around this issue since I was only using conversation linking sparingly, but I thought I'd let you (Tony) know since you're already looking at Articy as part of this thread.

[Tony Li]

Thanks! I'll look at that, too.

[Tony Li]

Give this a try:

DS_ArticyPatch_2024-06-11.unitypackage

It fixes that issue with dialogue-to-dialogue links not working, adds a "Use Linear Group Mode" checkbox to the Dialogue Manager's Other Settings section, and sets nodes with output pin code to regular entries if Instructions As is set to Regular Entry.

[lcn_mc]

Tony,

Thanks for the patch. I'm wrapping up my workday right now, but I'll try this tomorrow morning and get back to you here.

[_marc]

Hi there! Thank you, I've tested the last patch in our test scene, with ""Use Linear Group Mode" set to true and with instructions imported as groups, I've got the stack overflow exception again

StackOverflow.png (79.26 KiB) Viewed 80 times

Even when random result is 2, it evaluates the "try again" group after blocking on SimStatus condition. Do it still happens on your side?

[Tony Li]

Export issue. That package has the wrong ConversationModel.cs. Please import this and try again:

DS_ModelPatch_2024-06-12.unitypackage

[lcn_mc]

Good morning, Tony.

I downloaded and installed the patch from earlier (for the Articy convo linking problem), and now I'm seeing ten compiler errors in the log and I'm unable to launch in Play Mode. Here are the ten errors, as they appear in the Console in Unity:

• Assets\Plugins\Pixel Crushers\Dialogue System\Scripts\Importers\Articy\ArticyConverter.cs(909,89): error CS1061: 'ConverterPrefs' does not contain a definition for 'DelayEvaluation' and no accessible extension method 'DelayEvaluation' accepting a first argument of type 'ConverterPrefs' could be found (are you missing a using directive or an assembly reference?)
• Assets\Plugins\Pixel Crushers\Dialogue System\Scripts\Importers\Articy\ArticyConverter.cs(929,57): error CS1061: 'ConverterPrefs' does not contain a definition for 'ConvertInstructionsAs' and no accessible extension method 'ConvertInstructionsAs' accepting a first argument of type 'ConverterPrefs' could be found (are you missing a using directive or an assembly reference?)
• Assets\Plugins\Pixel Crushers\Dialogue System\Scripts\Importers\Articy\ArticyConverter.cs(929,97): error CS0117: 'ConverterPrefs' does not contain a definition for 'CodeNodeMode'
• Assets\Plugins\Pixel Crushers\Dialogue System\Scripts\Importers\Articy\ArticyConverter.cs(1515,35): error CS1061: 'ConverterPrefs' does not contain a definition for 'ConvertInstructionsAs' and no accessible extension method 'ConvertInstructionsAs' accepting a first argument of type 'ConverterPrefs' could be found (are you missing a using directive or an assembly reference?)
• Assets\Plugins\Pixel Crushers\Dialogue System\Scripts\Importers\Articy\ArticyConverter.cs(1515,75): error CS0117: 'ConverterPrefs' does not contain a definition for 'CodeNodeMode'
• Assets\Plugins\Pixel Crushers\Dialogue System\Scripts\Importers\Articy\ArticyConverter.cs(1607,82): error CS1061: 'ConverterPrefs' does not contain a definition for 'ConvertInstructionsAs' and no accessible extension method 'ConvertInstructionsAs' accepting a first argument of type 'ConverterPrefs' could be found (are you missing a using directive or an assembly reference?)
• Assets\Plugins\Pixel Crushers\Dialogue System\Scripts\Importers\Articy\ArticyConverter.cs(1607,122): error CS0117: 'ConverterPrefs' does not contain a definition for 'CodeNodeMode'
• Assets\Plugins\Pixel Crushers\Dialogue System\Scripts\Manager\DialogueSystemController.cs(682,36): error CS1501: No overload for method 'Initialize' takes 5 arguments
• Assets\Plugins\Pixel Crushers\Dialogue System\Scripts\Manager\DialogueSystemController.cs(719,30): error CS1501: No overload for method 'Initialize' takes 5 arguments
• Assets\Plugins\Pixel Crushers\Dialogue System\Scripts\Manager\DialogueSystemController.cs(1119,42): error CS1501: No overload for method 'Initialize' takes 5 arguments

Could you take a look at the above?

[_marc]

Thank you! We're almost there, there is no more stack overflow exception, but when the random int condition is finally evaluated to true...

Conversation_idling.png (12.52 KiB) Viewed 60 times

...the Dialogue System does nothing more (the log you see above is the last I get). It doesn"t end the conversation, and it doesn't go to the next group neither (the jump).
If I replace the group node (the jump node) by a regular node, then it works.