Modifying ConversationPopup field fails to mark Prefab as modified?

[skullthug]

Hello. I'm currently working through my first project with DS- so far it's been pretty slick. But I am currently running into an odd issue.
I have a custom script in a prefab that is calling a conversation ID via the ConversationPopup(true) inspector UI- which is pretty cool. However I'm noticing when in prefab edit mode, and I'm trying to change what conversation to populate it with, it will never mark the prefab Dirty and Unity won't enable the Save button or know there are changes to be saved. I have to toggle one of my bool checkmarks off and then on again to trigger the ability to Save the prefab.

This seems like maybe a bug? I'm going to keep investigating.
Using Unity 2019.2.12f1 and DS 2.2.2

[Tony Li]

Hi,

This looks like an issue with the new prefab system. I'll try to post an update to handle it by tomorrow.

[skullthug]

Gotcha. Thanks for letting me know and for the quick response!

[Tony Li]

I haven't been able to reproduce the issue. This is the script I'm using:

Code: Select all

using UnityEngine;
using PixelCrushers.DialogueSystem;

public class TestPopupScript : MonoBehaviour
{
    [ConversationPopup(true)]
    public string conversation;
}

It's on a prefab. If I edit that prefab and change the converation dropdown, it marks the prefab dirty.

Would it be possible for you to send me a script and prefab that can reproduce the issue? If you can export them as a unitypackage, that will keep all of the associated metadata.

[skullthug]

I think I understand what possibly confused me now. To repro this you need at least 2 dialogue databases.

If you select any conversation in the fold out, it will correctly mark the Prefab dirty.

ScreenClip [14].png (6.44 KiB) Viewed 3995 times

However if all you do is change out what Database is being used, it will not mark the Prefab dirty. Even worse is the change will actually stick around if you back out of the Prefab without saving.

ScreenClip [16].png (3.23 KiB) Viewed 3995 times

When I created this thread I was running into this issue, as I was trying to setup a prefab to be already pointed to a specific database. But we were starting to run into issues with our game trying to load conversations from the wrong database for some reason, and I think this weird Database serialization thing might be what was causing it.

I'll record a GIF here after I post this.

[Tony Li]

If you use this:

Code: Select all

[ConversationPopup(true)] public string conversationTitle;

versus just:

Code: Select all

[ConversationPopup]) public string conversationTitle;

it will show a database field as a convenience. If you assign a database, it will use that database's conversations for the dropdown. But it doesn't actually save the database assignment. It only saves the conversation title as a string.

Internally, the Dialogue System's editor scripts maintain a static reference to a dialogue database. If this static variable is accessed but unassigned, the editor scripts will check the current scene for a Dialogue Manager and assign its Initial Database to the static variable. When you use [ConversationPopup(true)], it shows the value of this static variable. I don't know if this explanation helps, but hopefully it clears up the logic of what's going on under the hood.

[skullthug]

[skullthug]

I see, i think we should be able to work around it since we decided to stick to one database ultimately.
It just made for some confusion initially during our setup process.
Due to the way we split up all our additive load scenes (with a DialogueManager instance only living in the core one) - we still have to rely on ConversationPopup(true) even though we're using one database, in order to be able to still select the specific conversations.

[Tony Li]

Sounds good. BTW, you can keep Dialogue Managers in the other scenes, too. It makes it more convenient to playtest individual scenes in the editor. As long as the Dialogue Managers have Allow Only One Instance ticked, the one from the core scene will survive across scene changes and automatically destroy the (test) Dialogue Managers in the other scenes.

[skullthug]

Good to know! Thanks again for helping me work out what was going on.