Previously evaluated, but not traversed groups

[VoodooDetective]

I've run into an issue where previously evaluated, but never traversed groups are blocking when I try to re-run a conversation. Here's an example conversation.

Groups.png (52.36 KiB) Viewed 763 times

The left group has this condition:

Code: Select all

not Variable["chic_menu_known"]

The right group has this condition:

Code: Select all

Variable["chic_menu_known"]

"Never mind." has no condition.

Variable["chic_menu_known"] == false always.

If I start the conversation, pick never mind, then restart the conversation, the conversation blocks and never speaks at "Can I get you anything." The subtitle menu shows up, but no text is displayed and the menu stays open indefinitely.

[VoodooDetective]

Actually, I'm seeing this strange blocking behavior in an even simpler case.

The sequence for all nodes is:
WaitForMessage(Typed)

Blocked.png (15.15 KiB) Viewed 761 times

This is actually the exact same code as the code-flip example given in the documentation. I have the x = math.random(2) in the start node, but I've also tried it in a separate node.

The conversation works properly up until the same number comes up twice in a row. Then the conversation will freeze as shown in the screenshot without ever showing the text. It brings up the subtitle, but doesn't display.

[Tony Li]

What are the Conditions and Script values on the nodes?

[VoodooDetective]

Start
Condition:
Script:

Code: Select all

x = math.random(3)

Empty Node
Sequence: None()
Condition:
Script:

Left Node
Text: [auto]I can't use that here.
Sequence: WaitForMessage(Typed)
Condition:
x == 1
Script:

Right Node
Text: [auto]That won't help here.
Sequence: WaitForMessage(Typed)
Condition: x == 2
Script:

[Tony Li]

Both of the response nodes have the same Conditions?

[VoodooDetective]

Oh no, sorry that was a typo. It's x==2 for the right node.

[Tony Li]

Hmm, I don't see the same behavior. Would you please compare this scene to yours:

DS_TestVoodooDetective_2020-02-16.unitypackage

I think I set it up similarly, except I used different text for the left and right nodes (111 and 222, respectively) and set the Sequence to:

Code: Select all

Delay(1)@Message(Typed)

to give me enough time to see the text. But I also tested with WaitForMessage(Typed) and that worked fine, too.

When you click the 'Start Conversation' button, it will start the conversation. One thing to keep in mind: If the trigger's 'Skip If No Valid Entries' checkbox is ticked, then it will run the <START> node's Script once in order to determine if there are any currently-valid nodes linked from <START>. It will detect the empty node and allow the conversation to start. When the conversation starts, it will run the <START> node's Script again.

[VoodooDetective]

Thanks so much for the example! So I think I tracked this down to a problem with the TextAnimator asset. I just emailed you and Febucci (TextAnimator author) about it with my issue. It actually happens with an even simpler example:

Screen Shot 2020-02-17 at 1.54.35 PM.png (240.86 KiB) Viewed 743 times

Here's what I said in the email so folks on the forum can see too:

Code: Select all

I think I've run into a new problem.  Anytime DSU runs the same exact dialogue twice in a row, the text animator will think DSU wants to display an empty string on the second attempt to play dialogue.

As far as I know, DSU will set the text mesh pro like this:

Play Conversation
TMP.text = "new text";
...
TextAnimator animates and calls OnTextShowed (which I have hooked up to SequencerMessages.Typed for DSU's benefit)
...
TMP.text = "";
...

At least that's how I understand it.  Maybe Tony can correct me if I'm wrong.  

What I'm seeing is that when I try to play the same single option conversation twice in a row, the second time will halt permanently.

So I stepped through the code and saw this in TextAnimator:
"""
        private void Update()
        {
            //TMPRO's text changed, setting the text again
            if (!tmproText.text.Equals(text))
            {
                //trigers anim player
                if (triggerAnimPlayerOnChange && tAnimPlayer != null)
                {
                    tAnimPlayer.ShowText(tmproText.text);
                }
                else //user is typing from TMPro
                {
                    _SyncText(tmproText.text, ShowTextMode.UserTyping);
                }

                return;
"""            

First Invocation:
text == null
tmproText.text == "new text"

Second Invocation:
text == "new text"
tmproText.text == ""

And so on the second invocation, OnTextShowed is never called and so DSfU hangs there forever waiting for its message to be typed (which will never happen).  So maybe "text" is never cleared up? 

I've found that if I manually set TMP.text = "" after every OnTextShowed() event, the problem goes away. So perhaps my assumption that DSU cleans up the TMP.text after a showing a subtitle is incorrect. But in doing this, I lose the delay for players to read the text.

[Tony Li]

Looks like Federico emailed you a TextAnimator fix. If that doesn't solve it, let me know. I can take a look on the DS side, too.

[VoodooDetective]

I spoke with Federico a bit more, and it looks like the problem is a little more complicated than first we understood.

The workaround ended up being this change to TextAnimator.cs:

Code: Select all

        private void _SyncText(string text, ShowTextMode showTextMode)
        {
            BuildTagsDatabase();

            //Prevents to calculate everything for an empty text
            if (text.Length <= 0)
            {
                hasText = false;
                text = string.Empty;
                _tmproText.text = string.Empty;
                tmproText.ClearMesh();
                return;
            }

            if (triggerAnimPlayerOnChange) { text += " "; } // <----------- CUSTOM CHANGE

Basically, Text Mesh Pro doesn't send a TextChanged event in very specific circumstances, and since that's how TextAnimator tries to detect changes, this was the only way around for now. Sounds like Federico is going to try to ask Stephan for help with the event stuff. The only other alternative is to somehow have DSU call ShowText() directly, but I'm not sure how that would work unless there were some interface for different text components.

Anyways, I guess I'm happy since there's a workaround. Without it, you can't really use TextAnimator with DSU.