Hi,
I'm currently using articy:draft to write dialog for our game. We're using the Dialogue System (and Adventure Creator) in Unity. I used to write using ChatMapper which allowed me to access to dialog entry ID (it uses the same IDs Dialogue System is using). This way I could implement conditions like Dialog[8].SimStatus ~= "WasDisplayed"". Dialog Entry 8 would now only be available until the player choses it for the first time. I'm trying to do a similar thing in articy:draft now.
Of course, I could create a global variable in articy:draft and then check the variable before the dialog entry and change it after it was displayed. But this would lead to having loads of variables since I'm using this technique pretty frequently.
Any ideas if there's a more elegant way to achieve this?
Thanks,
Marcus
Articy:draft - SimStatus
Re: Articy:draft - SimStatus
I was already considering adding a boolean field to my articy:draft dialog template, something like a "displayOnlyOneTime" checkbox and then rewriting the XML parser so that it includes a LUA command like the one mentioned above for each dialog entry that has this box checked. BUT I need to be able to access this information outside the entry as well. For example, I have a sub-branch that has 3 entries (and one that brings you back to the main branch). You shouldn't be able to access the branch anymore once all the options have been chosen. This means, there has to be a condition for the dialog option that brings you to this subbranch that checks if all the entries have been chosen once. This was possible in ChatMapper. I guess I'd have to use a variable for each of these dialog options, right? 
Re: Articy:draft - SimStatus
Hi,
A variable for each case is probably easiest in the long run. Also, you can give each variable a descriptive name, which is better in my opinion than Chat Mapper's use of "magic number" dialogue entry IDs. To keep the variables organized in articy, you can create a separate variableset for each conversation. They'll be imported into the Dialogue System as variableset.variablename. In articy, you can put expresso conditions on your input pins. These are equivalent to the Conditions fields in Chat Mapper. The Dialogue System's importer will convert the expresso to Lua. As long as the expresso code isn't complicated, the converter does a good job of translating to Lua. Simple variable checks convert just fine.
Alternatively, you can do what you described with the "displayOnlyOneTime" Boolean field. You could even make it a text field named "SimStatus" if you want. In either case, you should haven't to rewrite the XML parser. The challenge is that you won't know the dialogue entry ID ahead of time. However, you could look it up by Articy Id (e.g. 0x01000001000011FB) or Technical Name. I can reply with a little code blurb if you're interested in pursuing this option instead of variables and variablesets.
A variable for each case is probably easiest in the long run. Also, you can give each variable a descriptive name, which is better in my opinion than Chat Mapper's use of "magic number" dialogue entry IDs. To keep the variables organized in articy, you can create a separate variableset for each conversation. They'll be imported into the Dialogue System as variableset.variablename. In articy, you can put expresso conditions on your input pins. These are equivalent to the Conditions fields in Chat Mapper. The Dialogue System's importer will convert the expresso to Lua. As long as the expresso code isn't complicated, the converter does a good job of translating to Lua. Simple variable checks convert just fine.
Alternatively, you can do what you described with the "displayOnlyOneTime" Boolean field. You could even make it a text field named "SimStatus" if you want. In either case, you should haven't to rewrite the XML parser. The challenge is that you won't know the dialogue entry ID ahead of time. However, you could look it up by Articy Id (e.g. 0x01000001000011FB) or Technical Name. I can reply with a little code blurb if you're interested in pursuing this option instead of variables and variablesets.
Re: Articy:draft - SimStatus
Save your time and make it a template variable.
You can check them by writing a function which checks for an Articy template boolean field, then registering a delegate function like this:
You can add your own variables into Lua Variable[] table in Unity, but I'm not certain if there's a delegate which you can run automatically on import to do so.
You can check them by writing a function which checks for an Articy template boolean field, then registering a delegate function like this:
Code: Select all
public class DialogueOptionValidator : MonoBehaviour {
void Start () {
DialogueManager.Instance.IsDialogueEntryValid = IsEntryValid;
}
public bool IsEntryValid(DialogueEntry entry) {
if (entry == null) return false;
if( XXXXX() ) { // put your validation/removal code here
return true;
} else {
return false;
}
}
}
Re: Articy:draft - SimStatus
Thank you!!
I'll probably go with having multiple variables since my approach to wiring up the dialog fragments got a little more complicated than I described it before. At least the usage of multiple variable sets (one for each dialog) comes in handy. The big advantage is that now, I can use the Articy presentation tool and see if everything works the way it's supposed.
I'll probably go with having multiple variables since my approach to wiring up the dialog fragments got a little more complicated than I described it before. At least the usage of multiple variable sets (one for each dialog) comes in handy. The big advantage is that now, I can use the Articy presentation tool and see if everything works the way it's supposed.
