ı have this probelm and ı dont know this is solution
error :
MissingReferenceException: The object of type ‘GameObject’ has been destroyed but you are still trying to access it.
Your script should either check if it is null or you should not destroy the object.
PompaliSaldiri+d__17.MoveNext () (at Assets/scripts/Karaktersaldiri/PompaliSaldiri.cs:73)
UnityEngine.SetupCoroutine.InvokeMoveNext (System.Collections.IEnumerator enumerator, System.IntPtr returnValueAddress) (at <6afd1274f120405096bc1ad9e2010ba6>:0)
UnityEngine.MonoBehaviour:StartCoroutine(String)
PompaliSaldiri:Pompaliel_Ates() (at Assets/scripts/Karaktersaldiri/PompaliSaldiri.cs:37)
UnityEngine.EventSystems.EventSystem:Update() (at Library/PackageCache/com.unity.ugui@1.0.0/Runtime/EventSystem/EventSystem.cs:501)
hello first of all thank you for your reply. My problem is exactly like this: I’m making an fps game and there are 4 basic weapons in this game. I built a firing system for these guns. I made a small slot system to go back and forth between weapons. The basic logic of this system is that if you click on the button of the weapon you want, it disables everything belonging to the previous weapon and activates all gameobjects that have the characteristics of the purchased weapon. I can’t think of any other way for this slot system. The problem starts right here. While I am in the pistol weapon, the projectile throwing object of the pistol works very well when the pistol is active, but when the pump weapon is activated, everything related to the pistol is automatically disabled and the objects of the pumped weapon appear. When I want to shoot with the pump gun, it destroys the projectile throwing object of the pump gun after the first jam. It was a bit complicated, but unfortunately I wrote a long code, it’s really hard to explain it in writing. Thank you in advance!
I didn’t write any code for it to be destroyed, that’s the problem. So my logic is all about SetActive being enabled or disabled. So I didn’t write anything that will destroy that object with the code, it disappears by itself.
You can put a script on the thing that gets destroyed and do a Debug.Log() within the void OnDisable() method and see who does it, or at least know exactly when it happens.
You must find a way to get the information you need in order to reason about what the problem is.
What is often happening in these cases is one of the following:
the code you think is executing is not actually executing at all
the code is executing far EARLIER or LATER than you think
the code is executing far LESS OFTEN than you think
the code is executing far MORE OFTEN than you think
the code is executing on another GameObject than you think it is
you’re getting an error or warning and you haven’t noticed it in the console window
To help gain more insight into your problem, I recommend liberally sprinkling Debug.Log() statements through your code to display information in realtime.
Doing this should help you answer these types of questions:
is this code even running? which parts are running? how often does it run? what order does it run in?
what are the values of the variables involved? Are they initialized? Are the values reasonable?
are you meeting ALL the requirements to receive callbacks such as triggers / colliders (review the documentation)
Knowing this information will help you reason about the behavior you are seeing.
You can also supply a second argument to Debug.Log() and when you click the message, it will highlight the object in scene, such as Debug.Log("Problem!",this);
If your problem would benefit from in-scene or in-game visualization, Debug.DrawRay() or Debug.DrawLine() can help you visualize things like rays (used in raycasting) or distances.
You can also call Debug.Break() to pause the Editor when certain interesting pieces of code run, and then study the scene manually, looking for all the parts, where they are, what scripts are on them, etc.
You can also call GameObject.CreatePrimitive() to emplace debug-marker-ish objects in the scene at runtime.
You could also just display various important quantities in UI Text elements to watch them change as you play the game.
Another useful approach is to temporarily strip out everything besides what is necessary to prove your issue. This can simplify and isolate compounding effects of other items in your scene or prefab.
Here’s an example of putting in a laser-focused Debug.Log() and how that can save you a TON of time wallowing around speculating what might be going wrong:
