I have two scripts that mess each other up by removing targets

Questions & Answers
1

I wanted to seemingly move between levels with my player on level loads so I used the don’t destroy script, but I was running into a problem whenever I went back to the first level. it loaded 2 copies of the same object so i added to the script, destory the object if there are 2 copies type thing…

  {
        if (control == null)
        {
            DontDestroyOnLoad(transform.gameObject);
            control = this;
        }
        else if (control != this)
        {
            Destroy(transform.gameObject);
        }
    }
}

It fixed the problem of having multiple copies, but now it messed up my other scripts that have reference targets to the gameobject, like my camera follow, once it deletes the orignal, the target in the inspector tag reads unasigned target. How would I go about in fixing that?

2

So you have one instance of your player being created when you load level 1. The player exist in the scene and other components depend on this object being there. Your problem is arriving back to level 1. If you remove this player that exist in the scene and keeping the one that came from the other level, all references will be broken.

I guess I have two “but… but…” kind of questions.

Why do you need the player to exist only on level 1? (Or so I assume your setup is based on what I read.) It seems like a weird workflow because if you are editing level 5, you’d have to load level 1 to test-run level 5, then load level 5 back to make small tweaks. To me it sounds awkward to work like that.

Why do you need the player to not destroy on load? I will make the guess that you want some data to carry over from one scene to another, like player health and other information. You could pass that information in a static structure which the player will read in during Awake. This way each level can have their own Player instance and it will check if there are any arguments to be loaded from a previous level.

Anyway, what you could do is instead of destroying the original object, you could destroy the object coming from the previous scene, but grab whatever information you needed from it so the object in the current scene can apply them to self. If this is not an option (for example you may have coroutines running on the player and you really, really need to keep that for your buffs to work etc), then you have to make sure that the components in the scene have the bare minimum of what they need and not depend directly on the player that will get destroyed.

For example; The camera follow just need a transform to look at, right? So you can place an empty gameobject somewhere in the scene (let’s cal it “look at”). The player, when it has loaded the scene, can look for specially tagged game objects such as the “look at” object, and parent it to itself. It will claim ownership of it. If it had one already, it would throw the previous one away. So the idea is then to make your scene components to not rely directly on the player, but something the player can “pick up” when it loads in.

Or rewrite all code that references the player to look it up via a static variable or FindWithTag etc.

If you need to destroy the Player object, all of your code must respect and anticipate this so they don’t reference the Player object that happens to exist in the scene by default. Instead you could have a proxy dummy object in every scene which exposes functions for callbacks etc that has no real implementation and only routes calls to the real player object.