I've got one conversation that has become a nightmare to manage due to its freaking HUGE size. It's so big that I suspect I'll run out of space in the Editor in just two or three game versions from now.
Even worse is the fact that the Editor is lagging to a point that I need to wait a second before a node gets actually selected, so I really need to divide this up.
There are a number of approaches to do that, but I'd very much prefer to maintain a 'central' convo that manages the flow (variables/quest conditionals, etc.) and take the actual conversation chunks outside this central convo (original name appended with a slash and the name of the 'sub-convo').
But for that to happen I'd need to be able to call another conversation from the 'central' one, play it, and then returning to the next node in the previous 'central' convo.
Is this readily possible with some command I don't know about?
To link a node to another conversation, inspect the node. In the Inspector's Link To: dropdown, select (Another Conversation).
Group nodes may also help organize things. They serve as "hub" nodes that don't actually show any text. They just evaluate their conditions and pass through to their children. To create a group node, inspect the node and tick the Group checkbox.
Ooooooh! Nice! How could I have missed something like this?
Just one clarification though. This doesn't trigger any End Conversation event nor it's needed to activate the "Allow Simultaneous Conversations" option, right?
I also assume that for returning to the calling node in the previous convo, I'll need to use another 'Link To: Another Conversation' link pointing to the next node I'm interested in? No built-in method to remember the calling node, right?
Abelius wrote: ↑Wed Jul 04, 2018 2:54 pmThis doesn't trigger any End Conversation event nor it's needed to activate the "Allow Simultaneous Conversations" option, right?
No. You don't need to activate Allow Simultaneous Conversations, and it doesn't trigger any end conversation events. But you can hook into OnLinkedConversationStart if you're interested in knowing when the Dialogue System follows a link to another conversation.
Abelius wrote: ↑Wed Jul 04, 2018 2:54 pmI also assume that for returning to the calling node in the previous convo, I'll need to use another 'Link To: Another Conversation' link pointing to the next node I'm interested in?
That's correct. Just use another cross-conversation link back to the next node.
I'm having an issue due to the gigantic size of my 'central' convo...
When I link from there to another small conversation, I can select the target node ID number without a problem.
But when I create a link to the original conversation, I get a HUGE list of node IDs that always start from the oldest to the newest one created... and I have more than 2000 nodes in the hub convo.
If that object list had some way to quickly navigate to the end of it, with a key shortcut or something, this wouldn't be an issue. But I only have two arrows to click-hold and see how displaces at a sloooooow rate. It takes ages to scroll down to the node IDs I'm interested in selecting.
I believe this is a Unity problem, not DS-related, considering I've seen that type of control in other plugins as well but, do you know some way to navigate in them in some quicker fashion?
That's a tough one. You're right that it's just the way dropdown menus work in the Unity editor. Here are some ideas:
1. Split up the dropdown menu into submenus, say 20 items each.
2. Get rid of the square brackets. Instead of "[9] Blah blah blah" it would be "9: Blah blah blah". This way you can press the number keys to jump down to the next menu item that starts with that number (9, 90-99, 900-999).
3. Insert up to 26 inactive menu items 'A' through 'Z' so you could jump through the whole list 1/26th at a time by pressing a letter key.
Yeah, option 1 would reduce the time needed to reach the bottom of the list by 20 times, which is more than okay. However, other users may not like the aesthetic change.
Option 3, IMHO, introduces even more 'garbage' that most users won't dig. Also, letters don't relate to numbers so, in big lists, it would be a trial and error method at best.
And option 2, while it's not a bad idea, may not work as well as intended because if I try to reach node ID 2345, and I press '2', I'll just get to node ID 2 in my first press, then 20, then 21, and so on. However, it would be different if that type of control allows for multiple key presses like '2', '3', '4' and '5' in quick succession. In that case, this would be the ideal solution in my opinion. I don't know if it supports this behavior or not...
On another note, I tried myself a little experiment before coming to you.
What I did was to change the node ID number of the target node. I changed it from 2359 to 11 (a free number due to some old nodes being deleted, I guess). But when I clicked on the drop-down again, it wasn't in the first positions. I believe it was still at the end of the list. I even restarted Unity just in case but it was still nowhere near the top of the list.
So I believe that list is ordered by node creation time. Because even changing the node ID number, it's still at its original position in the list. And I've also observed that when a node gets deleted, its node ID number it's not used again in that convo newly created nodes (correct me if I'm wrong).
Therefore, I'm thinking of another approach that *might* be nice, without any aesthetic changes that users may not like.
First, you could change those node drop-down lists so they get ordered by their node ID numbers (so if I modify one, it moves in the list also).
Second, you could start auto-assigning numbers to newly created nodes from 100 onwards.
That way we could change specific nodes IDs to a number between 1-99 and be guaranteed that they'll be presented first in the list.
You're correct that the dropdown shows nodes in the order they were created. This is by design, since in many cases it's more helpful than internal ID numbers that are assigned relatively randomly. (They're generally assigned increasing values, but it's possible when adding a new node that it could use a lower number that's no longer being used.)
If you want to reorder them by ID, you can select Menu > Sort > Reorder IDs > This Conversation. (Make a backup first, just in case you find that this isn't what you want after all.) Then they should show in up the dropdown in ID order.
Side note: Be very careful when changing node IDs manually. (Better yet, don't do it at all.) If you change a node's ID from 2359 to 11, you'll need to manually go through all links that point to and from that node, and update the link's ID, too. Otherwise the link will still point to node 2359, which doesn't exist any more.
I'll look into option #1. If there are more than 100 entries, it will split them into sub-menus of 20 entries each. If there are 100 entries or less, it will work like it does now. If it works out, I'll try to get the change published by the end of the weekend, along with a first pass at global search & replace.
Tony Li wrote: ↑Fri Jul 06, 2018 8:50 am
You're correct that the dropdown shows nodes in the order they were created. This is by design, since in many cases it's more helpful than internal ID numbers that are assigned relatively randomly. (They're generally assigned increasing values, but it's possible when adding a new node that it could use a lower number that's no longer being used.)
Ah okay. That thwarts my evil plan.
Tony Li wrote: ↑Fri Jul 06, 2018 8:50 am
If you want to reorder them by ID, you can select Menu > Sort > Reorder IDs > This Conversation. (Make a backup first, just in case you find that this isn't what you want after all.) Then they should show in up the dropdown in ID order.
Yeah, I've tried and that's not quite what I need. It 'fills' the gaps between node IDs, but it orders them as it sees fit. No control over the process.
Tony Li wrote: ↑Fri Jul 06, 2018 8:50 am
Side note: Be very careful when changing node IDs manually. (Better yet, don't do it at all.) If you change a node's ID from 2359 to 11, you'll need to manually go through all links that point to and from that node, and update the link's ID, too. Otherwise the link will still point to node 2359, which doesn't exist any more.
Thanks for the warning. In fact, I've observed that the links pointing to the changed node ID simply disappear...:
In fact, I think they're still pointing to ID 11, which is even worse because it's not considered an error and no warning shows up on the console, so you could get into a troubleshooting nightmare very fast.
Yeah, better not touch anything.
Tony Li wrote: ↑Fri Jul 06, 2018 8:50 am
I'll look into option #1. If there are more than 100 entries, it will split them into sub-menus of 20 entries each. If there are 100 entries or less, it will work like it does now. If it works out, I'll try to get the change published by the end of the weekend, along with a first pass at global search & replace.
Oh, nice...! If you can selectively activate that behavior only when there are more than 100 objects, then go for it by all means!
Playing around with it, I set the cutoff to 50 because 100 is still a lot to scroll through. I'm setting version 1.8.4 release candidate 1 to build now, and I'm going to go walk the dogs. When I get back, I'll send you a link to try it out.
