Properly Disposing DS Through Code

[Rocco]

Title says it all!

In our game we are using a combination of Adventure Creator and Dialogue System. During the game we are transitioning from AC using DS to another mini-game we have created that uses neither. I am wondering what is the appropriate way to save and destroy the instance of DS for maximum clean up potential. Additionally, if anyone knows how to do the same for Adventure Creator that would be awesome, however I am going to go ahead and post on their forums as well regarding that.

Any help is greatly appreciated!

[Tony Li]

That's a good question! I'm surprised no one's asked it before, since there is a little something you can do for maximum cleanup potential.

For the most part, just destroy the Dialogue Manager GameObject. This will clean almost everything up.

However, the Lua environment exists separately from the Dialogue Manager. To clear the contents of the Lua environment, call:

Code: Select all

DialogueLua.InitializeChatMapperVariables();

Keep in mind that destroying the Dialogue Manager and clearing Lua will get rid of all of your Dialogue System runtime data. If you weren't using Adventure Creator, I'd recommend serializing the data first using:

Code: Select all

string data = PersistentDataManager.GetSaveData();

Then save the data string somewhere. When you bring back the Dialogue System, you can reapply the data using:

Code: Select all

PersistentDataManager.ApplySaveData(data);

Since you're using Adventure Creator, you may just want to save your AC game instead. The Dialogue System ties into AC's save system, so it does that GetSaveData()/ApplySaveData() stuff behind the scenes for you.

Instead of all of this, you may find it easier to keep the Dialogue Manager in memory during the whole play session. The biggest memory consumer may be your dialogue UI, with all its textures. You can destroy it when you switch to the minigame. Just remember to reinstantiate it and assign the instance to DialogueManager.DialogueUI before running any conversations or alerts. If you're using legacy Unity GUI, you can assign a prefab; you don't have to instantiate it.

[Rocco]

Thanks for the detailed response. We are definitely going to look into this. I would like to get the most memory that I can squeeze out as possible by clearing as much as possible. After switching to the non-AC minigame we will be coming back to the main game. As such would you say the following steps are correct in terms of order of operations.

• Save AC Game First
• Clear LUA Environment. This part should be safe since we saved the AC game first correct?
• Finally destroy the Dialogue Manager GameObject to free up texture memory and DS itself

Additionally each one of our scenes has a Dialogue Manager GameObject in it by default. Would you consider this a good approach so that if we accidentally forget to initialize it will still be there? Presumably if there are two DS instances DS destroys the other?

[Tony Li]

Clear LUA Environment. This part should be safe since we saved the AC game first correct?

Yup, your Lua is safe if you save the AC game first. That's a good order of operations. You might not need to destroy the Dialogue Manager manually (see below).

Additionally each one of our scenes has a Dialogue Manager GameObject in it by default. Would you consider this a good approach so that if we accidentally forget to initialize it will still be there? Presumably if there are two DS instances DS destroys the other?

The Dialogue Manager (actually the Dialogue System Controller component on it) has two relevant checkboxes:

• Dont Destroy On Load
• Allow Only One Instance

If Dont Destroy On Load is ticked, the Dialogue Manager will stick around when you change scenes, including when you switch to your minigame scene. In this case, you'll need to manually destroy it. But if the checkbox is unticked, Unity will automatically destroy the Dialogue Manager GameObject when switching scenes, like any regular GameObject in the scene.

If Allow Only One Instance is ticked, when the Dialogue Manager starts, it will look for an existing Dialogue Manager. If it finds an existing Dialogue Manager, it will destroy itself, leaving only the original Dialogue Manager.

If the Dialogue Manager sticks around (either because the checkbox is unticked or because there's no pre-existing Dialogue Manager), the Dialogue Manager will clear the Lua environment and populate it with its Initial Database info. You can repopulate it with the runtime values by grabbing the AC variable that holds the Dialogue System saved data, and run it through Lua.Run(). (The AC variable actually contains Lua code to recreate the saved Lua environment.) This is why it might be easiest to keep the Dialogue Manager around. You don't need to fiddle with repopulating Lua.

A lot of devs tick both checkboxes (which is the default) and still add a Dialogue Manager to each scene. This lets them test the Dialogue System in that scene without having to come from another scene that has the Dialogue Manager. But if you are coming from another scene with an existing Dialogue Manager, that Dialogue Manager will continue to live and destroy the new scene's Dialogue Manager, keeping all your Lua data happily intact.

[Rocco]

Sounds good. We've actually been doing that for testing as well so we don't have to keep coming from other scenes.

I will switch our order of operations to the following then after setting Dialogue Manager GameObject to Don't Destroy on Load and Allow Only Instance

• Save AC Game first
• Clear LUA Environment
• Get rid of the UI but keep the Manager around an re-initialize the UI

[Tony Li]

Don't clear the Lua environment out from underneath the Dialogue Manager unless you repopulate Lua before doing anything Dialogue System-related.

Try this:

• Save AC Game first
• Clear Lua
• Destroy the Dialogue Manager
• When returning to a DS scene that has a Dialogue Manager, feed the AC variable to Lua.Run() after one frame (to allow the Dialogue Manager to run its Start method first)

Or this:

• (Don't bother to save; don't clear Lua)
• Get rid of the UI but keep the Dialogue Manager and Lua
• When returning to the DS scene, instantiate the UI and assign it to DialogueManager.DialogueUI

Or this:

• Nothing (just keep it all in memory)

If you keep the Dialogue Manager and Lua in memory: If you have a really, really big dialogue database, you can add it manually using DialogueManager.AddDatabase(myBigDatabase). When switching to your minigame, call DialogueManager.RemoveDatabase(myBigDatabase). Just assign a small dummy database to the Dialogue Manager's Dialogue UI field so it has something to start with.

Another way to save memory is to untick Include Sim Status. The default is unticked. When this is ticked, the Lua environment holds a field for every single dialogue entry that keeps track of whether it's been offered in a response menu or spoken by a character. Unless you're using this info, you might as well untick it.

[Rocco]

Tony,

We were able to free up around 30 - 40mb of RAM using this approach! Thanks a lot!

[Tony Li]

Great! Was it mostly in UI textures?

[Rocco]

I'm not 100% sure tbh. I would say that a larger portion is more likely from the textures then clearing the LUA. We did have quite a few UI elements.