Pixel Crushers Forum

Hi Tony,

I searched the forums and found some similar problems, but all seemed a little more complex than mine so I thought I'd just check if there is a very simple solution.

I've been having a bit of trouble keeping some "special case" secondary dialogue UIs working properly when my project transitions from scene to scene.

The dialogue trigger for this conversation is set to "On Enable", and the game object is enabled by a keystroke.
Game Object: Dialogue System hierarchy: This works fine in the first scene. When I transition into the next scene however, the dialogue appears in its proper panel, but also appears behind that in the generic conversation panel from the dialogue system's Default Canvas. So the player would have to make the same selection twice in two dialogue UIs.
First scene: Second scene: Nothing changes in the Cursor Inventory's Override Dialogue UI component from one scene to another, so I'm a bit baffled by the inconsistency.The problem also persists if I return from the second scene to the first one, so I'm guessing it's something wrong with the transition between scenes rather than some difference between the scenes. The Dialogue Manager's Don't Destroy On Load box is ticked anyway, so I suppose a difference shouldn't matter?

Is there something obvious that I'm missing?
I'm handling this "cursor inventory" through the Dialogue System because which cursors the player currently has access to are controlled by Lua variables which change during dialogue, but if it turns out that having multiple UIs and moving between scenes is inherently complicated to handle I guess I can write the inventory from scratch (I see there was a recent post about how to access Lua variables in C# code).

Hi,

Is Cursor Inventory part of the Dialogue Manager's hierarchy, or other a GameObject that's marked Don't Destroy On Load?

If not, keep in mind that the Dialogue Manager GameObject survives scene changes and replaces any Dialogue Manager that might have been placed in the second scene at design time.

For example, let's call the Dialogue Manager in the first scene "Dialogue Manager 1" and the Cursor Inventory GameObject "Cursor Inventory 1". Cursor Inventory 1's Override Dialogue UI points to Dialogue Manager 1's Cursor Inventory Dialogue UI.

In scene 2, you might have another Dialogue Manager named "Dialogue Manager 2" and a Cursor Inventory GameObject "Cursor Inventory 2", where Cursor Inventory 2's Override Dialogue UI points to Dialogue Manager 2's Cursor Inventory Dialogue UI.

This will work fine if you play each scene individually in the editor. But if you play from the first scene and then change to the second scene, Dialogue Manager 1 will survive into the second scene and remove Dialogue Manager 2. Since Cursor Inventory 2's Override Dialogue UI pointed to Dialogue Manager 2 (which no longer exists), it runs into a problem.

I don't know if that's related to the issue, but that's usually the problem when these issues only happen after scene changes. This article explains the same issue with screenshots, in the context of player components instead of Cursor Inventory components, if screenshots would be helpful to explain the issue.

If that's not the issue, can you send a reproduction project to tony (at) pixelcrushers.com?

Hi Tony,

Thanks for the speedy reply. I'm almost sure you've identified the problem here! Or at least: making the Cursor Inventory part of the Dialogue Manager hierarchy rather than being a separate Don't Destroy On Load game object (as it used to be) seems to have resolved the immediate problem.

My only questions are: does everything persistent related to the Dialogue System need to be contained within the Dialogue Manager hierarchy? And are there any potential pitfalls to doing so?

Standard NPCs (those whose dialogues use the default canvas) work perfectly across scene transitions, and they are set up essentially as you indicate in the [HOWTO] link. In both scenes they are outside the Dialogue Manager hierarchy.

For now I've childed the Cursor Inventory game object to the Cursor Inventor canvas, and done the same with the Phone Canvas and the one NPC whose conversations happen there. In other words, any NPC who uses one of the two secondary UIs is now part of the Dialogue Manager hierarchy. This seems to have solved the gameplay problems (which is great!).

However I'm not sure if this is a wise or sustainable thing to do, I had up to now conceptualised the Dialogue Manager hierarchy as something I should leave alone as much as possible. Is my current fix bad practice in your opinion?

Thanks again!

If both GameObjects are marked Don't Destroy On Load in the same scene, they shouldn't have to be all in the Dialogue Manager's hierarchy.

Since putting them in the same hierarchy makes the problem go away, it does seem like an issue where the reference is lost when changing scenes since the referenced GameObject no longer exists. It's fine to put both in the Dialogue Manager's hierarchy, but it's also fine to set it up a different way as long as it keeps the reference.

Devs usually set up the Dialogue Manager (including whatever else they want to put in it) and then save their customized Dialogue Manager as a new prefab or prefab variant. This way they can drop the prefab into their scenes for testing, and they only need to update the prefab to have the updates appear in all scenes.

Hi Tony, sorry to resurrect this old post.

I'm returning to this issue after a few months and—contrary to what I said before—the problem still exists. Maybe I'd solved a slightly different version of it last time, unfortunately I don't really remember. In the meantime my design has changed significantly so that most of my gameplay happens within a single scene, so I'd stopped thinking about it. However it's returned now because I'm trying to write a simple intro scene (something like a character creator) where the player makes some choices affecting variables that persist in the main gameplay scene.

Having re-read the link you sent last time I now fully understand that my problem lies in assigning references between regular GameObjects and persistent singletons. However I'm struggling to understand how to avoid this when using the Override Dialogue UI component.

In concrete terms:
My game has a phone assistant who the player can summon by clicking a phone icon button. That button enables this game object: ...which triggers the conversation, which is overridden to the SMS Dialogue UI.
However to override it to this UI I have dragged and dropped from the version of the Dialogue Manager in the "main gameplay scene".
Naturally, when transitioning from the intro ("character creator") scene into this main gameplay scene, the Ui referenced in the Override Dialogue UI component can't be found, since it is looking for the one in the scene hierarchy rather than the one that has been carried over from the previous scene. They are the same prefab, but still I understand why the regular, non-persistent GameObject Phone Narrator can't find it.

What I don't understand is whether there's any way to use the Override Dialogue UI component in such a way that it doesn't create this problem? That is: how can I implement this component without referencing between regular and persistent GameObjects?
I was trying to think of a way of making the Phone Narrator also persist across scenes even though it's not needed in the first one, but that just handed the problem on to the button not being able to reference the Phone Narrator, and etc etc.

Since this is a very simple game I can probably make the "character creation" sequence actually just be part of the main gameplay scene with everything else if it comes down to it. But it would be good to understand the basic principle here for potential future projects.
Thanks!

Hi,

Can you make your Charlois SMS Dialogue UI a child of the Phone Narrator? Add a Canvas to the Phone Narrator, then add the dialogue UI to the Canvas.

Wellll, making it a child of the Phone Narrator produced some odd behaviour for reasons I don't understand, but moving it to elsewhere in the hierarchy outside the Dialogue Manager parent has worked!

Thanks Tony.

Glad to help! The original issue is probably similar in concept to this article: How To: Manage Player Controls and Scene Changes