Pixel Crushers Forum

I use a lot of conditions like Conversation[1].Dialog[1].SimStatus ~= "WasDisplayed". The problem is that when you have a lot of conversations and rename them, it becomes really tricky to remember what conversation the ID in the condition refers to (you need to click the conversations one by one to check their ID). Would you consider adding a way to display the ID number along with the conversation name in the Nodes and Outline Modes?

Hi,

To show dialogue entry IDs on each dialogue entry's node, you can already select Menu > Show > Show Node IDs. This of course only applies to the currently-open conversation.

Would it help to include the conversation IDs in the Outline mode's reorderable list and in the Nodes mode's conversation selection dropdown menu?

Yes, that would be perfect for conversation IDs! It would make it much easier to find a specific conversation at a glance.

Unrelated to the above, but still about IDs: something a bit more complicated that I'm foreseeing about dialogue IDs (rather than conversation IDs) is the order they are displayed to translators when you export them. So far my workflow has been:

- Write an entire conversation tree.
- Ask DS to reorder the IDs, depth first.
- Only then add all the necessary Status Sim conditions.

This gives us a more or less readable flow when exporting the file. The issue here is that we often have to make changes - adding a new node between two old ones to clarify an NPC's request, or adding a better transition from two parallel dialogue branches into a single one. Once exported, those new nodes look very out of place to the people who need to make sense of them.

I'm not sure what the best way to address this is, but it might be useful to have a second set of IDs that can be assigned solely for proofreading/localisation, so that humans can understand the flow of the exported text without confusing the machine (both the game logic as described above AND the CAT tool the translators use; it is important that the CAT tool knows which strings are new and which ones have been modified). I initially considered the idea that reordering IDs should also go through the conditions and automatically modify them, but decided against suggesting it because (1) this wouldn't catch their use elsewhere (e.g. Adventure Creator actions), and (2) it would confuse the CAT tool.

Hi,

You could use define a separate field in your dialogue entry template. (See Templates.) In the example below, I've defined a field named LocID and configured Localization Export/Import to export and import dialogue entries based on that field's value:


You'll need to set LocID manually and/or write some editor code to assign values. You can hook into the the DialogueEditorWindow.customDrawAssetInspector C# event to add a button to the Conversation Properties inspector that would assign values to LocID (see Customizing the Editor).

Hi Tony, I was revisiting this idea and I think I've run into a bug.

Your suggestion above sounds good! I was trying to figure out how to assign LocIDs in the same way Dialogue System reorders Conversation IDs when you tell it to (using depth first or an alternate method), but before I got too far, I realised that using the reorder menu's "this conversation" or "all conversations" options doesn't actually do anything now (it used to work, I've done it before, but I've updated DS a couple of times since then). Can you confirm this is a bug? A pop-up confirmation is displayed when I select the option, but then nothing happens. The IDs don't change.

A second question, once we sort the bug out: I'm struggling a bit to understand how exactly to add a button that would reorder the Loc IDs like the above button above should reorder Conversation IDs. I'm assuming it might be viable to just duplicate the code that does it, but tell it to assign Loc IDs instead? But I'm not familiar enough with DS to know how to do this.

I'm using version 2.2.41.

Hi,

Version 2.2.41 inadvertently disabled reordering. There's a patch for it. It's also fixed in the upcoming version 2.2.42.

DS_ReorderIDsPatch_2023-11-25-A.unitypackage

Thank you for the fix!

Upon further investigation, I've realised that I wasn't clear re: what I am trying to achieve. Your suggestion that I use a Key Field wouldn't work because, as far as I can tell, a Key Field replaces Conversation/Entry ID as a reference when running a Localisation import/export, correct? That's precisely what I don't want it to do. Let me explain my use case.

The way I set things up, Dialogue System sits between Adventure Creator and memoQ.

On one side, Adventure Creator deals with 90%+ of all game logic. We use AC ActionLists to check for all sorts of conditions (a mix between AC variables and the 'Dialogue System Check' custom action, running Lua Code to evaluate the Sim Status of conversation entries). These ActionLists then run the appropriate cutscenes, which often include calling Dialogue System conversations.

Dialogue System sits in the middle. We use it to write all dialogue and quests. Because we make reference to Conversation/Entry IDs all the time on the AC side of things, it is absolutely necessary that all IDs remain the same. Changing any IDs would break the game.

And on the other side, we have memoQ for localisation. We have set up the memoQ project so that when we import the CSV file from Dialogue System, it will lock the 'Conversation ID' and 'Entry ID' columns as context, and it will assign 'Original Text' and 'Translated Text' as the source and target columns, respectively. This means that when the translator translates the original text and commits the translation to the Translation Memory, the TM will pair the original and translated strings and suggest it as a partial match whenever the translator encounters a similar string elsewhere. Here, it is very important for the 'Conversation ID' and 'Entry ID' to be used as context during match evaluation: we only want memoQ to return a 100% match when not only the source strings match, but also when the IDs match as well. This way, when the same string is used in different contexts, memoQ will tell the translator: here is a 99% match (the words are the same, but they are used in a different context; make sure they fit the new context).

In short, both on the Adventure Creator and the memoQ side of things, it is essential that the Conversation and Entry IDs never change, and that Dialogue System imports/exports are always tied to them. If we create a Loc ID field, we do not want the imports/exports to be tied to them instead, which unfortunately is what a Key Field would do.

We really are 99% of the way there. The only reason why I was considering creating a Loc ID field is that when we run a Localisation Export on Dialogue System, the resulting CSV file is ordered by Conversation ID and Entry ID. For example:



The order the nodes are linked in the conversation editor is actually 0>1>3>2, but the translator wouldn't know that! Reordering the IDs would fix the order on the exported spreadsheet and make the translator's life easier, but as I explained above, this would cause severe problems both for AC and memoQ.

What we want the CSV file to look like is this:



I thought that if we created a 'Loc ID' entry field and ran a similar method to the 'reorder ID' one in order to generate their values, we could have something like this:



This would make it trivial to reorder the rows on Excel before importing the file to memoQ. The problem is that this can't be achieved because (1) a Key Field does not allow for that anyway - the point of creating a Loc ID field would have been to allow it to be changed whenever we want for sorting purposes, without messing up AC references to dialogue entries or accidentally overwriting entries when importing a CSV file back into Dialogue System (for instance, if we assign Loc ID as a key field and export a CSV to memoQ, this means we cannot reorder the Loc IDs in DS and then eventually import a translated CSV back). And (2) I'm not sure how to replicate the method that reorders entry IDs so that it leaves entry IDs alone and generates Loc IDs instead.

Now, I've noticed that when we export the database as a Screenplay, it displays the conversation nodes in a perfectly readable order regardless of the Entry IDs. Would you consider adding a checkbox to the Localisation Export section that would allow us to export the strings in the same order as the screenplay one, but keeping the Conversation and Entry IDs intact? This would eliminate the need to create a Loc ID field for further sorting.

Sure! That sounds like a good solution. I'll send you a patch when it's done.

Thank you! I really appreciate it.