x


DontDestroyOnLoad - is it intended behavior?

Today I found out that DontDestroyOnLoad function clones host gameObject at level reload. It seems to me, that before Unity 3.1 it acted differently (unfortunately I dont have other versions at hand). Is it OK or is it a bug? alt text

more ▼

asked Nov 16 '10 at 10:11 AM

zoon gravatar image

zoon
88 1 1 9

It seems that should be the expected behavior, yes? Every time you reload the scene a new 'dummy' object will be created; since each of these objects will persist from level to level, you end up with multiple dummy objects. (A more typical use of DontDestroyOnLoad() would be, I think, to apply it to an object in e.g. scene A, and then progress through scenes B, C, etc. In this context, the single object created in scene A would persist through any subsequently loaded levels.)

Nov 16 '10 at 10:32 AM Jesse Anders
(comments are locked)
10|3000 characters needed characters left

3 answers: sort voted first

I think this behaviour was present in previous versions. It is not that DontDestroyOnLoad is cloning the gameObject, it is that the non-destroyable-object is persisting (as it should), but re-loading the level is also loading a new copy of the object (because it exists in the scene file).

If you want to reload the scene which contains the "Don't Destroy" object, but you don't want two copies of that object, you need to add some code which makes the 2nd new copy of the object destroy itself, leaving the first to persist. For example, a static boolean variable could be used to do this:

private var _sofar : float;
private static created = false;

function Awake() {
    if (!created) {
        // this is the first instance - make it persist
        DontDestroyOnLoad(this.gameObject);
        created = true;
    } else {
        // this must be a duplicate from a scene reload - DESTROY!
        Destroy(this.gameObject);
    } 
}

function Update() {
    _sofar += Time.deltaTime;
    if (_sofar > 3) {
        print("reloading level ...");
        Application.LoadLevel("test");
    }
}
more ▼

answered Nov 16 '10 at 10:33 AM

duck gravatar image

duck ♦♦
41.4k 95 152 415

An alternate approach is to not pre-create this persistent "state" object in your hierarchy at all, rather have every scene check if the object exists, and create it dynamically (i.e. using some "LoadState" script), only if it doesn't already exist. This way, you always have just one copy of this object, and it doesn't matter what scene you start in.

Aug 04 '12 at 10:43 PM ciabaros
(comments are locked)
10|3000 characters needed characters left

That's normal, including versions before 3.1

more ▼

answered Nov 16 '10 at 10:32 AM

Mike 3 gravatar image

Mike 3
30.7k 10 67 256

(comments are locked)
10|3000 characters needed characters left

An alternate approach to Ben's answer is to not create this persistent "state" object in your hierarchy at all, and have every scene check if the object exists, and create it dynamically (i.e. using some "LoadState" script), only if it doesn't already exist. This way, you always have just one copy of this object, and it doesn't matter what scene you start in.

more ▼

answered Aug 04 '12 at 10:48 PM

ciabaros gravatar image

ciabaros
16 1 1 3

(comments are locked)
10|3000 characters needed characters left
Your answer
toggle preview:

Up to 2 attachments (including images) can be used with a maximum of 524.3 kB each and 1.0 MB total.

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Topics:

x5275
x2175
x84

asked: Nov 16 '10 at 10:11 AM

Seen: 5836 times

Last Updated: Aug 04 '12 at 10:48 PM