The object of type 'GameOverScreen' has been destroyed but you are still trying to access it.

GameOverScreen is the script for GameOverMenu, whenever it is called third time its giving me this error, but only script about Destroy is attached to its parent, GameOverUI any suggestions why this happens?

Code (CSharp):

1. using System.Collections;
2.  
3. using System.Collections.Generic;
4.  
5. using UnityEngine;
6.  
7. public class hopeFull : MonoBehaviour
8.  
9. {
10.  
11. public static hopeFull instance;
12.  
13. void Awake()
14.  
15. {
16.  
17. if (instance == null)
18.  
19. instance = this;
20.  
21. else
22.  
23. {
24.  
25. Destroy(gameObject);
26.  
27. return;
28.  
29. }
30.  
31. DontDestroyOnLoad(gameObject);
32.  
33. }
34.  
35. // Update is called once per frame
36.  
37. void Update()
38.  
39. {
40.  
41. }
42.  
43. }

 

Why do you need destroy in awake? That seems like a poor design decision.

Not clear why you do that or how the rest of your game is engineered so can only comment on what you've provided and destroy in awake just seems like you're going about something the wrong way.

 

Destroy on Awake is because this is a Singleton. Once you get that single value assigned to instance, if you go back to that scene, you want to destroy future instances of that hopeFull script. So there is nothing wrong with this setup.

For OP, unfortunately I don't really understand where your error is because you didn't provide many details. But the error pretty much says your issue. GameOverScreen is attached to a gameobject that is being destroyed. Which, in this case means when your hopeFull script is destroyed, but is on a parent object of other items that also have scripts that run awake, you probably are running into an order of execution error. But, you didn't show how things are connected. So, be careful about what you choose to set as singletons with DontDestroyOnLoad.

If this doesn't make sense. It's simply you can't guarantee the order in which Awakes with all run, so you have to set that up.

 

Couldn't disagree more. Singletons are horrible (hot take among these parts it seems). Monobehaviours have pretty obvious lifecycles. Hamming them into immortal-zombies-that-can't-die-yet-can-also-spawn-multiples-but-get-headshot-instantly-if-they-do seems like absolutely the worst way to manage the lifecycle of an object. Monobehaviours were designed to die, don't make them immortal zombies.

If something in your game needs to live forever make it a Scriptable Object as they're never unloaded, always available and things from multiple scenes or different prefabs can reference the same instance of it. In essence, they're application lifetime objects you can serialize a reference to - why you'd use immortal zombie monobehaviours when you have that out of the box has always been a mystery to me. You also git the benefits of not being tied to a static reference so it's easier to test and swap out behaviour and you can save runtime state back into the scriptable object (or copy it via Instantiate). So many advantages of MonoBehaviours.

The other option is to make a scene that's never unloaded.

If you do have object lifecycles that are longer than a single scene but also need to be unloaded then you can just use scene management to have a seperate scene with the objects you need loaded only as long as required. Writing a custom solution that's backed by Addressables is also not a terrible way to go.

No one should be building games on a foundation of monobehaviour zombies. Maybe for a quick 24h demo mashup or game jam perhaps but for anything longer there's better and more maintainable ways to do it IMO.

 

This a help thread, not a thread to voice our grievances with certain design patterns.

 

The thread itself was created because a bad design pattern was used. I'm discussing alternative ways to manage the lifecycle of an object as I identified the how it's currently being does does not seem to be working well. The thread title itself strongly hints that object lifecycle management seems to be a problem as the OP is getting errors about objects being destroyed that they thought should not be destroyed.

But hey, now we're discussing what to discuss when helping, which is absolutely not what this thread is for.

 

Honestly your post across more about hating on Singletons than it was helpful, not to say there wasn't good advice within it. Perhaps be less aggressive in the future.

Remember only Sith deal in absolutes.

In any case we really need more information from OP to provide a proper solution to their specific problem.

 

WTF the Sith got to do with anything? If I see bad code, I'll say it's bad. If you disagree then please change my mind, I love finding out I'm wrong, means I've learnt something. That's the whole point of the forums no?

I also said Scriptable Objects are essentially Unity's version the Single Instance pattern and a much better implementation that approaches a more robust DI / IoC way of working. Unity also actively recommend against using DontDestroyOnLoad (see link below) since they added additive scene loading over a decade ago. It only existed to get around an early engine limitation.

https://docs.unity3d.com/2020.1/Documentation/Manual/MultiSceneEditing.html#:~:text=It is recommended to avoid,your managers and use SceneManager.

Would love to know why people are so weirdly attached to MonoBehaviour singeltons but that's clearly a different thread.

 

hey, im really newbie as you can see so i don't really know what info you need but if you would make me understand ill be more than thankful, because i really need this to work