Bug Mesh Renderer Eneable/disable stopped working

Hi!
I have a game logic where I enable and disable a mesh renderer of an object . At around the 50th timethe mesh renderer never gets enabled. I do so through the script attached to the object and through other scripts in the project. This is a snippet of the code, attached to the object. Any idea what could be the issue?

Code (CSharp):

1. using UnityEngine;
2.  
3. public class AimingDiscScript : MonoBehaviour
4. {
5.     public GameObject discPrefab;
6.     public GameObject discLaunchPosition;
7.     public static bool isPlacedInitially;
8.     [SerializeField] private Camera mainCamera;
9.     [SerializeField] private LayerMask layerMask;
10. //   private GameObject newDisc;
11.     public Vector3 mousePosition;
12.     public static MeshRenderer initialDiscMesh;
13.  
14.  
15.     private void Start()
16.     {
17.       initialDiscMesh = GetComponent<MeshRenderer>();
18.     }
19.  
20.     void Update()
21.     {
22.         FollowMouse();
23.     }
24.     public void FollowMouse()
25.     {
26.         if ((isPlacedInitially == false))
27.         {
28.             Ray ray = mainCamera.ScreenPointToRay(Input.mousePosition);
29.             if (Physics.Raycast(ray, out RaycastHit raycastHit, float.MaxValue, layerMask))
30.             {
31.                 transform.position = raycastHit.point;
32.             }
33.             mousePosition = transform.position;
34.             if ((Input.GetButtonDown("Fire1") && (GameManager.Hits > 0)))
35.             {
36.                 initialDiscMesh.enabled = false;
37.                 PlaceDisc();
38.             }
39.         }
40.     }
41.  
42.  
43.     public void PlaceDisc()
44.     {
45.         GameObject shootingDisc = ObjectPool.SharedInstance.GetPooledObject();
46.         if (shootingDisc != null)
47.         {
48.             shootingDisc.transform.position = discLaunchPosition.transform.position; ;
49.             shootingDisc.transform.rotation = discLaunchPosition.transform.rotation;
50.             shootingDisc.SetActive(true);
51.             GameManager.Hits--;
52.             isPlacedInitially = true;
53.         }
54.     }
55.  
56. }

 

Your initialDiscMesh variable is static. So there is only one instance of that variable. Are you sure this script you've shown only exist once in your scene and at no point in time is another one created? Why is that variable static in the first place? Are other scripts messing with this variable? This calls for a disaster as you have no control or oversight who's doing what to which object. The point of classes and encapsulation is to reduce / restrict the usage of internal fields so it's easier to reason about when a certain state change. That's why classes would implement methods / interfaces for other objects to communicate through a well defined channel so the class has full control over its own state. If the state can only be changed through well defined methods, it's easy to see who may be messing with the state as you can simply add a Debug.Log to that method.

We can't really tell you where your mistake may be. However it seems you have several such bad designs in your code. Like

of is "Hits" actually a property that executes code? Though that's generally not a good approach. You want to provide a "Hit" method and the game manager would change its internal state based on that.

Some people say: "encapsulation just makes the code more complicated. I just make everything public and static so I can use everything I need everywhere, much simpler". This is somewhat true, but ultimatively leads to situations like this where when something goes wrong you will have a really hard time figuring out where you've gone wrong. Great power, great responsibility, you know ^^. The splitting of code into classes is meant to reduce the number of points where separate concepts may interact with each other. (separation of concerns). For small games / projects that may not be that important as long as you have the full picture in your head. However if a project grows at a certain point you can't remember every dirty trick you may have used. So it's important to have clear sections where you know they work as intended when provided with reasonable input. Also at interface points (methods) you can implement safety checks or logging which helps debugging.