Export for proofreading

[Tony Li]

Hi,

What are you using Actor.localizedName for? It's supposed to be the localized version of the "Name" field, not the "Display Name" field.

What are you trying to accomplish? Perhaps I can suggest a better approach.

[rey]

Hey Toni

Whenever the DS to Loc creates a String Table, it uses Display Name {loc code} as its localization field for the name of the actor.



Whenever we attempt to get the Actor.localizedName to display this name in our UI, it does not find localized fields for "Name {loc code}", because the DS to Loc named the localized fields "Display Name" (see screenshot above).

So either the DS to Loc converter should create the "Name" fields for localization, or the Actor.localizedName should look for the "Display Name {loc code}" instead I think.

Hope that is more clear, the issue appears to be the DS to Loc converter. It can be reproduced by creating a project with the standard unity localization, Dialogue System, and the DS to Loc bridge, then create an actor, and press the Dialogue System to String Table button, then import that by pressing the STring Table To Dialogue System button.

[Tony Li]

In what context are you attempting to get the Actor.localizedName in your UI? If it's during a conversation, use the CharacterInfo object instead. CharacterInfo.Name will be the localized Display Name if available, otherwise the localized Name. This is what the Dialogue System's dialogue UIs use. At any particular point in the conversation, you can check DialogueManager.currentConversationState.subtitle.speakerInfo, or check the subtitle in an OnConversationLine(Subtitle) method.

If it's outside of a conversation, you can use DialogueActor.GetActorName().

[rey]

This requires an object reference to the DialogueActor, which seems unnecessary.

We do not use any of the markup and Conversation stuff. While no doubt beautiful for no-code/low code solutions, it just feels like a lot of overkill and abstractions we'd rather not have in the project at this early stage.

Instead we work directly from the Conversation Database and wrote our own simplified navigation tools that can just navigate nodes back and forth as we want and parse our own pseudo code.

Likewise, we fetch the actor directly from the database:

Code: Select all

Actor a = DialogueManager.masterDatabase.GetActor(currentEntryNode.ActorID);

then use a.LocalizedName to fetch the name. Which appears perfectly valid, it has a fetch function and does not require an additional reference to an DialogueActor object. The only minor thing is the bug that the fetch and localization fields do not line up, as can be seen in the debug logs when attempting to do so.

Happy to share the script here, its just for prototyping right now but it might point to something either I'm not understanding, or you might be missing. My goal is to keep it as barebones as possible, and only to use/integrate what we need, something Dialogue System seems to still fight us on from time to time

[Tony Li]

Sorry, I thought you were using a ConversationModel, which handles dialogue entries' Conditions and Script fields, etc.

If you were using a ConversationModel, it has CharacterInfo objects with valid Name properties.

If you're not using a ConversationModel, use:

Code: Select all

Actor a = DialogueManager.masterDatabase.GetActor(currentEntryNode.ActorID);
string displayName = a.LookupLocalizedValue("Display Name");

[rey]

I will try that in the morning!

Thanks again, really appreciate this above and beyond level of support and response.