Issue with instantiated objects interacting with non-instantiated objects scripts

I am having an issue having an instantiated object dealing damage with other objects in the game. I have an script, lets call it player.cs

public class Player: MonoBehaviour
{
    public int health = 100;
    public int attack = 1;

    public void TakeDamage(int amount)
    {
        health -= amount;
    }

   }

I think have a mob script

public class mob_move : MonoBehaviour
{
    public float speed;
    private Rigidbody2D rb2d;

    // Start is called before the first frame update
    void Start()
    {
        rb2d = GetComponent<Rigidbody2D>();
        speed = -10;
    }
    private void Awake()
    {
 
    }
    // Update is called once per frame
    void Update()
    {

       
    }
    private void FixedUpdate()
    {
        rb2d.velocity = new Vector2(speed, 0);
    }
    private void OnTriggerEnter2D(Collider2D collision)
    {
        if (collision.gameObject.tag == "Player")
        {
            speed = 0;
            sharedRefs.player.TakeDamage(1);

        }
    }


}

Finally a shared ref script to supposedly expose the player script to the instantiated object

public class sharedRefs
{

    public static Player player;
}

The goal currently is to have when the instantiated mob collides with the player the player takes 1 damage, however when I do this I get the error that the Object reference is not set to an instance of an object on the line sharedRefs.player.TakeDamage(1);

Can anyone point out what I am doing wrong here?

The answer for NullReferenceException is always the same… ALWAYS!

How to fix a NullReferenceException error

https://forum.unity.com/threads/how-to-fix-a-nullreferenceexception-error.1230297/

Three steps to success:

  • Identify what is null ← any other action taken before this step is WASTED TIME
  • Identify why it is null
  • Fix that

I appreciate the answer, but if I could identify what is null I would not be here hehe. sharedRefs.player and is an object of Player exits. Player.TakeDamage exists so I am not sure why sharedRefs.player.Takedamage() tells me there is a null reference.

My guess is that for some reason the instantiated object cannot reference the sharedRefs class for some reason, but visual studio does not alert me to that for some reason (same issue if I just point it to the player class which is why I created a sharedrefsc script, which I got from this thread but I am clearly missing something.

Go back to the link I already posted and scroll down to the link that shows the mindset you must use.

Remember: it is NOT that we don’t want to help you, it is that we CANNOT help you until you do Step #1.

If you have blasted ahead so fast that you don’t understand your code, then STOP. Go back and work through all the parts of what you have done and explain to your dog (see my avatar picture?) what you have done.

Understanding what you are doing is not optional.

So there is a problem with this, I can explain what my code is supposed to be doing, however what it is supposed to be doing and what it is doing are clearly 2 different things. Sometimes people miss 1 important bit that they keep missing.

I know that if I change the above to

Player player;
player.takeDamage

then that null reference goes away, because I am creating an object reference player , however then I get a different null error “object reference not set to an instance of an object” which is another null pointer exception which is a little more clear that I am calling the player, but not a specific instance of player (there is only one), so I need to figure out the proper call to get to that instance of player.

Figured it out. had to use player = GameObject.FindGameObjectWithTag("Player").GetComponent<Player>();

I had attempted that before but used GameObject(s) which does not have a getcomponent function.

Rarely in Unity do we use static fields for referencing other MonoBehaviours.

We don’t do it because it clashes with object lifecycles.

I’m not sure where the above code came from but you probably want to stay closer to the “usual Unity ways” of doing things, the ways you will learn in Unity-made tutorials.