Different "types" of responses.

[KenCrim]

Hello! Sorry if this is asked and answered, but I couldn't find anything obvious. I'm messing around with different response prefabs for things like skill checks (on-hover previews, etc. etc.). My hope is to be able to parse these types as markdown so that templating in Yarn can go something like:

Code: Select all

[check skill="acro" dc="10"]"Watch this back flip!"[/check ]

...and I'm puzzling over the best way to do it. My hope was to intercept and subclass the "Response" class when parsing markdown and include it as a property in that subclass so it can be accessed when instantiating the prefab. Is that viable? Would directly modifying the list indices in OnConversationResponseMenu be the most straightforward way to do it. Am I missing a more obvious solution? Thanks!

[Tony Li]

Hi,

Normally you'll use Yarn's conditional logic, which the Dialogue System's importer will convert into Lua in dialogue entries' Conditions and Script fields.

However, if you want to process your custom markup, OnConversationResponseMenu(Response[]) is a good way to do it, with one caveat: The response array is fixed. You can't remove responses from it. You can, however, set a response's enabled property to false to show it in a non-clickable state.

If you want to run a skill check once the player chooses the response, you can handle it in an OnConversationLine(Subtitle) method.

Regarding response menu items, if you want to prevent the conversation from including a dialogue entry in the menu (rather than just making it non-clickable), you can assign your own C# method to DialogueManager.isDialogueEntryValid. The Dialogue System will pass dialogue entries to your C# method, which can return true if the conversation is allowed to use/show that entry and false if not.

[KenCrim]

This all makes sense, and is how we're handling a lot of it! But I think I may have done a bad job of explaining the issue - namely, trying to instantiate different prefabs based on the "type" of subtitle or response. I was able to get a working version like so (forgive the bad code):

Override OnConversationResponseMenu and Subclass Response when parsing markup in YarnCustomCommands:

Code: Select all

    public override void OnConversationResponseMenu(Response[] responses)
    {

        for (var i = 0; i < responses.Length; i++)
        {
            var markupResult = Dialogue.ParseMarkup(responses[i].formattedText.text);
            foreach (var markupResultAttribute in markupResult.Attributes.Where(markupResultAttribute => markupResultAttribute.Name == "check"))
            {
                markupResultAttribute.Properties.TryGetValue("dc", out var difficulty);
                markupResultAttribute.Properties.TryGetValue("skill", out var skillName);
                
                // SkillCheckResponse is just a simple subclass of Response with values for skill name and dc   
                responses[i] = new SkillCheckResponse(responses[i], skillName.StringValue, difficulty.IntegerValue);
            }
        }
        
        base.OnConversationResponseMenu(responses);
    }

... and then in SetResponseButtons, conditionally instantiate a prefab based on which subclass we've gotten:

Code: Select all

                        
 GameObject buttonGameObject = null;
 buttonGameObject = responses[i] is SkillCheckResponse ? InstantiateSkillCheckButton() : InstantiateButton();
 

So the above works, but just feels a smidge janky (and seems to only work because I have an array whose indices I can manipulate, so likely wouldn't work for Subtitles), so I was wondering if there's an upstream location somewhere where I could intercept and subclass?

[Tony Li]

Hi,

It sounds like you're already doing this, but I recommend subclassing StandardUIMenuPanel and doing all of that work in overridden ShowResponses() and SetResponseButton() methods instead of using a separate script with an OnConversationResponseMenu() method. Those methods in StandardUIMenuPanel are virtual for purposes just like this.

[KenCrim]

Oh, interesting, so leave the markup unstripped so that it can be handled downstream and parsed once it gets to the actual display components? Interesting, okay, will give that a try. Thanks!