How do I reference the input field of another object?

Unity Engine
, , ,
1

I’d like to assign passwordInput to a different game object. Dragging and dropping from the inspector window works fine, but I plan to use this script multiple times in the future. I tried the GameObject.FindGameObjectWithTag("PasswordInput") so I can look for whatever object has that tag, but I can’t yet figure out how to use it properly.

using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using UnityEngine.Rendering;
using UnityEngine.UI;

public class ReadInput : MonoBehaviour
{

    private string passcode;
    public InputField passwordInput;
    private string input; 

    // Start is called before the first frame update
    void Start()
    {
        passcode = "password";
    }

    // Update is called once per frame
    void Update()
    {
        
    }

    public void ReadStringInput()
    {
        input = passwordInput.text;
        
        if (input == passcode)
        {
            Debug.Log("Correct");
        }
        else
        {
            Debug.Log("Wrong");
        }

    }

}
1 Like
2

Using Singleton design pattern, you can save the reference and use it in other places of your code without linking every time in inspector.

Simple Example:

public class ReadInput : MonoBehaviour
{
    private static ReadInput instance;
 
    public static ReadInput GetInstance()
    {
        return instance;
    }
 
    private void Awake()
    {
        instance = this;
    }
}

public class AnotherClass : MonoBehaviour
{
    private void SomeMethod()
    {
        ReadInput.GetInstance().passwordInput;
    }
}
1 Like
3

A couple of quick opinions… First is given that you couldn’t quite get FindGameObjectWithTag to work is to take some time to get it to work. Find out why you couldn’t or what you need to do to get it to work (like add a tag). And try transform.GetChild and transform.parent and a bit of GetComponent in there as well.

You don’t have to nail every eccentricity but familiarization (with a reason to try it) is a good idea.

Second, discard the code that uses FindGameObjectWithTag :slight_smile: Not a good way to do it (you should still know how it works).

I personally wouldn’t use a Singleton. I don’t see the need for what you describe. Would dragging a control a couple of times a year be a chore? I have to assume that the input is “nearby” or could placed nearby (like a child of your ReadInput gameobject. If so you can use “convention” and know that the object you want is the first child and get it at runtime.

I’m not a big fan of a class named ReadInput and I’d remove the empty Update() method and I would recommend something other than assigning the passcode to a hardcoded string in the Start method.

Look at it as an opportunity to adopt robust practices before they drown you in spaghetti.

1 Like
5

This is great, thank you! Unfortunately for me, it’s surprisingly easier to just make new scripts for each scene so different scenes can activate one another while using different passcodes each, rather than stuffing all that in one code. Who would have thought. This is really useful information though, thanks!

Edit: Thought I was replying to the wrong guy, so I deleted my comment. Turns out that’s just how threads work

1 Like
6

All noted, thanks! I was also able to fix FindGameObjectWithTag, dunno what I was doing wrong there

7

The passcodes themselves could actually come from a Singleton. Think of it as a “config” class that contains things that “something” will want to know about. So passcodes, whether something is visible by default, default colors, and things like that.

You would only need to edit your config class and rebuild. If you use a dynamic config file you would only need to edit the settings in that file instead and wouldn’t need to recompile.

8

Yes you’re right, but I have to set different objects to be activate every time every time the password is correct, and I’m worried I won’t be able to do that if I just use the 2 scripts. Or maybe not, just had an idea while typing this. Thanks

9

Always get things working before you optimize but… don’t fail to look for optimization opportunities.

Basically any time you notice you are copying and pasting a lot of code or (which may be the case here) you have nearly duplicate code in more than once class it indicates “code smell”.

You may be able to (for instance since I have no idea) be able to assign the password to the property from the Inspector. That way (again I’m just grasping at straws here) you would use the same code but can have unique passwords.

Eventually (when it is all working) move the passwords out of the class and into some sort of config file.

10

Yeah that’s actually what I’m doing right now, assigning passwords using the inspector, along with where I want the screen to cut to once you insert the password. The only variables that change are, the password, the next screen, and the screen you cut back to. I was committed to using the inspector the least I could, but that only made things more complicated