Bark Actor Issue

[Xenrathe]

I'm having an issue that I cannot figure out, in which the bark actor keeps being improperly assigned.

In the Conversation that the Bark references, the three entries (START node + two children node), both the ACTOR and CONVERSANT fields are ALL marked the first actor [1]. Yet the Bark dialogue / UI keeps being assigned to the second actor [2].

In trying to resolve this issue, I went to the GetBarker function in DialogueSystemTrigger.cs and looked at the line:

var barkActor = DialogueManager.MasterDatabase.GetActor(conversationAsset.ConversantID)

First, why is it using the ConversantID (what I understand to be the 'listener') instead of the ActorID (what I understand to be the 'speaker')?

Second, yes the ConversantID is ALWAYS 2, even though NONE of the actual dialogueEntries ever use actor [2] as the ACTOR or CONVERSANT. Edit: I see it's pulling the default actor/conversants #s from the overall conversation itself rather than the individual dialogue entries.

So I suppose my revised question now is am I simply mis-using barks? Or is there some way to have the bark actor/conversant be pulled from the DIALOGUE ENTRY, rather than the overall CONVERSATION itself?

Some additional information that may be of use:
-I'm calling this DialogueTrigger manually via script with an OnUse()

[Tony Li]

Hi,

Yes, it's inconsistent and confusing to use the conversant, but there's a reason. By default, when you create a conversation it assigns the Player as the conversation's Actor and the NPC as the conversation's Conversant. Most users were just adding nodes as children of the <START> node without changing the actor assignments. To make life easier for them, barks use the conversant so users don't have to remember to switch the actors. If you're using a Dialogue System Trigger, you can override this by assigning a GameObject to the Dialogue System Trigger's Bark > Barker field.

[Xenrathe]

So my use-case here is that I have a single conversation for all of a given scene's bark dialogue. So the conversation's dialogue entries will very often have different actors that I want to be speaking the bark dialogue.

As such, I can't assign a single GameObject in the Dialogue System Trigger's Barker field. I would have to dynamically update that via script, at which point I feel I'd be replicating functionality that I was hoping to have from the Dialogue System itself (which is that the actor + conversant are being pulled from the DIALOGUE ENTRY, rather than the BARK CONVERSATION itself).

One solution could be to have a Dialogue System Trigger and a Bark Conversation entry for every single different speaker. But that's a little inelegant and could get unwieldy if I end up having many different barkers.

Think I'm going to have to go into the IEnumerator Bark(--) function in BarkController and adjust the base code, so it pulls the speaker and listener from the actual chosen entry rather than the overall conversation itself.

EDIT: I added the following lines

Code: Select all

if (barkEntry != null)
{
	//ADJUSTMENTS TO CODE
	speaker = CharacterInfo.GetRegisteredActorTransform(DialogueManager.MasterDatabase.GetActor(barkEntry.ActorID).Name);
	listener = CharacterInfo.GetRegisteredActorTransform(DialogueManager.MasterDatabase.GetActor(barkEntry.ConversantID).Name);
	barkUI = DialogueActor.GetBarkUI(speaker);
	//END ADJUSTMENTS TO CODE
	...
}

into the mentioned function. This resolved my issue.

[Tony Li]

Hi,

Do the child nodes (linked from <START>) have different actors assigned to them? For example:

multipleBarkActors.png (8.42 KiB) Viewed 258 times

The catch is that bark conversations often use a generic actor (e.g., "NPC") that multiple characters can use. For example, think of general "hello", "nice day, innit?", etc., barks that any number of random villagers in a village could bark. In this case, you'll want to tell the specific villager, not the generic "NPC" actor, to bark the line.

What about this change?

• If the dialogue entry's actor is the same as the conversation's conversant, use the specified character (e.g., specific villager).
• If the dialogue entry's actor is different from the conversation's conversant, tell the dialogue entry's actor to bark instead.

Would that work for your needs?

[Xenrathe]

Thank you for the responses!

I resolved the issue to my satisfaction (see my code edits in previous post). However, for your edification and for other users who may encounter this problem, I can answer your questions / provide more feedback.

I do see that the Barker can be assigned through various means, such as an override in the Dialogue Trigger or pulled from a Usable component for OnUse(). However, I don't do any of that as I was calling the trigger manually via an OnUse() call in a generic Controller script that tracks various game-states.

My expectation was that, lacking an explicit Barker assignment, the Bark Conversation would function similarly to a Cutscene Conversation, which is that the Actor and Conversant would be pulled from the Dialogue Entry. Which may or may not be the case, with one problematic exception:

Yes the child nodes have different actors assigned to them. That doesn't matter, however, because your code for barks (IEnumerator Bark in BarkController) assigns the BarkUI from the speaker transform BEFORE the BarkEntry/DialogueEntry is chosen. Lacking an explicit Barker assignment, this speaker transform is just assigned on the basis of the Conversation's default Actor / Conversant entries.

This is not what I wanted, so I put in code that assigns the BarkUI transform using the ActorID ***AFTER*** the BarkEntry/DialogueEntry is chosen. This resolved the issue and makes it behave as I expected it to behave, which is that the BarkUI appears above the Actor in the given DialogueEntry.

Note: Edited after looking at the code some more and realizing that I had mis-diagnosed the problem. I believe it's not an issue of the speaker/listener assignments, per se, but the BarkUI assignment that occurs before DialogueEntry/BarkEntry is chosen.

[Tony Li]

Sounds good. Thanks for the detailed explanation of your scenario. That made it easier to understand.