Hello Everyone,
first off, nice package!
I am currently integrating it in our current project and have a few questions, which I was not able to find a satisfactory answers from the code documentation.
We won't be using any of the provided Triggers, rather than starting conversations through dynamic commands. I was not able to find any indications on where I can register my classes for the conversation events (especially OnEnd) in Code?
Is the package modular enough for us to drop the LUA implementation? Or might there be a micro/light version of your package in the future? We will be using only the Dialogue and Bark part and would like to drop most of the Overhead (like sequencing, conditions etc.).
The Articy-Importer is a really helpful addition, are you planning to keep the code locked away in your assembly? We might need to make some additions to get all our necessary data imported, do you see any possibility for us doing that?
Thanks for your time and Kind Regards!
Package Integration Issues
Package Integration Issues
Hi,
You've probably already found this, but you can start a conversation in code using DialogueManager.StartConversation().
To hook into Dialogue System messages, see the Script Messages page. OnConversationEnd is broadcast to the participants and the Dialogue Manager. You could add this method, for example, to a script on the player:
void OnConversationEnd(Transform otherParticipant) {
Debug.Log("The player just ended a conversation!");
}
It's not possible to drop Lua entirely. It's integral to how the Dialogue System handles data. That said, it's designed modularly so you can swap in your own Lua implementation, even an implementation that's mostly empty stubs if that's what you want. The bundled Lua implementation is LuaInterpreter, which is very small and lightweight and performs very well. The Third Party Support folder also includes an implementation that uses NLua. Is there a reason why you're interested in dropping it? Removing Lua, sequencing, and conditions would be a major task for you, and you'd net less than 100 KB of savings in the assembly size, which is just a fraction of the size of a single texture file.
Full source code is included. The pre-compiled assembly is just provided as a convenience. Since the Dialogue System has so much code, especially in custom editor scripts, this speeds up iteration time considerably. See How to Unpack the Source Code for instructions on unpacking the source code.
If you have any feature requests for articy:draft import, please let me know. They might be useful to others, too. I recently added a customer's request to prioritize connections between dialogue fragments using connection colors, which provides a nice, visual way to differentiate them.
You've probably already found this, but you can start a conversation in code using DialogueManager.StartConversation().
To hook into Dialogue System messages, see the Script Messages page. OnConversationEnd is broadcast to the participants and the Dialogue Manager. You could add this method, for example, to a script on the player:
void OnConversationEnd(Transform otherParticipant) {
Debug.Log("The player just ended a conversation!");
}
It's not possible to drop Lua entirely. It's integral to how the Dialogue System handles data. That said, it's designed modularly so you can swap in your own Lua implementation, even an implementation that's mostly empty stubs if that's what you want. The bundled Lua implementation is LuaInterpreter, which is very small and lightweight and performs very well. The Third Party Support folder also includes an implementation that uses NLua. Is there a reason why you're interested in dropping it? Removing Lua, sequencing, and conditions would be a major task for you, and you'd net less than 100 KB of savings in the assembly size, which is just a fraction of the size of a single texture file.
Full source code is included. The pre-compiled assembly is just provided as a convenience. Since the Dialogue System has so much code, especially in custom editor scripts, this speeds up iteration time considerably. See How to Unpack the Source Code for instructions on unpacking the source code.
If you have any feature requests for articy:draft import, please let me know. They might be useful to others, too. I recently added a customer's request to prioritize connections between dialogue fragments using connection colors, which provides a nice, visual way to differentiate them.
Package Integration Issues
Thank you for the fast reply and you are right, the full source code package I did overlook. I will take a closer look at this at some point.
Regarding the OnConversationEnd script, I do not have a player represented by a MonoBehaviour that could receive a Unity ScriptMessage in the scene. What I need would be soumething like this pseudocode to be compatible with our framework:
<pre class="lang:default mark:4-7 range:1 decode:true " title="Pseudocode example">// Set some necessary data here!
var chapterdialogue = DialogueManager.StartConversation("chapter/enemy02/introdialogue");
chapterdialogue.OnDialogueEnd += () =>
{
// Do Some dynamic stuff here!
}
So I am guessing I would have to hook in our event messaging system to get around your send message approach? I don't like the idea of polling the current state of the Dialogue system in a coroutine, since it might result in missfired events within my current project architecture.
From my personal and external perspective LUA seems like an unnecessary addition. I just want to keep dependencies and used technologies as slim and lean as possible and therefore weigh my possibilities. Basic Dialogue integration resulted in a 2MB increase for my Android built, but since it is just a demo implementation I am sure there is to be done more optimizations on my part first to have accurate data on this.
The Articy feature sounds really great. We did mention to the friendly devs at Nevigo that we are using your tool with their server solution, if you are interested I can share some details on our (planned) workflow with you.
Regarding the OnConversationEnd script, I do not have a player represented by a MonoBehaviour that could receive a Unity ScriptMessage in the scene. What I need would be soumething like this pseudocode to be compatible with our framework:
<pre class="lang:default mark:4-7 range:1 decode:true " title="Pseudocode example">// Set some necessary data here!
var chapterdialogue = DialogueManager.StartConversation("chapter/enemy02/introdialogue");
chapterdialogue.OnDialogueEnd += () =>
{
// Do Some dynamic stuff here!
}
So I am guessing I would have to hook in our event messaging system to get around your send message approach? I don't like the idea of polling the current state of the Dialogue system in a coroutine, since it might result in missfired events within my current project architecture.
From my personal and external perspective LUA seems like an unnecessary addition. I just want to keep dependencies and used technologies as slim and lean as possible and therefore weigh my possibilities. Basic Dialogue integration resulted in a 2MB increase for my Android built, but since it is just a demo implementation I am sure there is to be done more optimizations on my part first to have accurate data on this.
The Articy feature sounds really great. We did mention to the friendly devs at Nevigo that we are using your tool with their server solution, if you are interested I can share some details on our (planned) workflow with you.
Package Integration Issues
Hi,
Yes, please share your planned workflow. I'm always interested in seeing how different teams design their workflow. Thanks!
The 2 MB is mostly coming from textures and other files in Resources folders, mainly under the Examples folder. You can delete them. Anything in a Resources folder is included in the build, even if it's not used. After building, check the editor.log to identify what the big assets are.
There's no need to poll! OnConversationEnd broadcasts a message, instead of using a C# event, to support UnityScript programmers, and generally to make life easier for most coders. Since conversations don't end every frame, there's no performance worry. You can fire an event from it. Add a script like this to the Dialogue Manager:
using UnityEngine;
public class ConversationEvents : MonoBehaviour {
public delegate void ConversationEventHandler(Transform actor);
public event ConversationEventHandler conversationEnded = delegate {};
public void OnConversationEnd(Transform actor) {
conversationEnded(actor);
}
}
Then hook into it:
DialogueManager.Instance.GetComponent<ConversationEvents>().conversationEnded += () =>
{
// Do Some dynamic stuff here!
}
Yes, please share your planned workflow. I'm always interested in seeing how different teams design their workflow. Thanks!
The 2 MB is mostly coming from textures and other files in Resources folders, mainly under the Examples folder. You can delete them. Anything in a Resources folder is included in the build, even if it's not used. After building, check the editor.log to identify what the big assets are.
There's no need to poll! OnConversationEnd broadcasts a message, instead of using a C# event, to support UnityScript programmers, and generally to make life easier for most coders. Since conversations don't end every frame, there's no performance worry. You can fire an event from it. Add a script like this to the Dialogue Manager:
using UnityEngine;
public class ConversationEvents : MonoBehaviour {
public delegate void ConversationEventHandler(Transform actor);
public event ConversationEventHandler conversationEnded = delegate {};
public void OnConversationEnd(Transform actor) {
conversationEnded(actor);
}
}
Then hook into it:
DialogueManager.Instance.GetComponent<ConversationEvents>().conversationEnded += () =>
{
// Do Some dynamic stuff here!
}