Pixel Crushers Forum

Hello, we are planning on using Dialogue System for our ongoing project that's integrated with Adventure Creator. I was wondering whether it would be possible to extend sequencer entrytag/entrytaglocal or add other usable variables. Since we may have a lot of voice acting in multiple languages having an extremely customisable foldering structure for VO files is a must. Since the cusomisation differs hugely per user, we had a similar problem with AC. The best/most universal solution we came up with was simply having an exposed delegate, which can be assigned to override the way path is generated. Would it be possible to add such an options for entrytaglocal generation or add some more reserved names to sequencer that would have associated delegates and in case those delegates are assigned/not null, they would get parsed into appropriate values. I'm just starting to dig in to the Dialogue System structure, so my apologies if the suggestions/requests make no sense in the current architecture. (If the delegates were to be implemented, one important aspect that would probably need discussing would be what parameters the delegate would have).

Hello,

Let's see if we can approach this from the angle of requirements instead of solutions. There may already be a solution that fits your needs. Can you please provide some examples of paths your project might use?

In the meantime, to completely contradict myself, here are some potential solutions.

The entrytag format can be set to VoiceOverFile, which will use the value of the dialogue entry's VoiceOverFile field. (This is a custom field that you'd define in the database's template.) The localized version will have its language appended to the end. For example, say your VoiceOverFile field is set to "Adam/Conversation42/Line1". If the language is set to "fr", entrytaglocal will be "Adam/Conversation42/Line1_fr".

If that's not flexible enough for you, you can register one of your own C# functions with Lua, and then use the [lua(code)] tag in your sequences, such as: AudioWait([lua(MyEntrytagDelegate(thisID))]), where MyEntrytagDelegate() is your C# function that returns a path to an audio file. The Dialogue System sets the variable thisID to the current dialogue entry ID. I included it here as a convenient. You technically don't need it because you can just read the DialogueManager.currentConversationState property to get the same thing.

Note that these files must still be located in a Resources folder or assetbundle so they can be loaded at runtime. If you use assetbundles, call DialogueManager.RegisterAssetBundle() to let the Dialogue System know about them.

Currently the foldering structure is:
Resources/Speech/<language>/<location data>/<original text>
It might change somewhat in the future. But essentially in AC we use "Original Text", the equivalent of "Dialogue Text" in DS, as an ID field that is filled in by hand. And simply have actual content in translations (that is content in English is written in en translation field). Given the complexity, for actual dialogue conversations we'd probably like the structure:
Resources/Speech/<language>/<location data>/<conversation name>/<dialogue text>

The key requirement is that speech audio could be distributed into language subfolders. Now as to whether we'll use <dialogue text> as custom id or use the current id implementations of DS and try to generate similarly structured ID's in AC, we'll have to see, that depends on whether we'll need to sort lines based on ID and have them in a chronological order.

Anyway, registering a script with lua, seems to solve my problem. I can easily get the data I need for dialogue line generation from globally accessible methods and variables.

Sounds good. I recommend calling the Lua function in the Dialogue Manager's Default Sequence instead of each individual node's Sequence field if possible. It will be easier to manage.