koobas.hobune.stream
How can I access other scripts and their functions?
I understand the use of GetComponent, but is this the best or only way to access other scripts? If I create a file that consists of single class, how can I instantiate that class? Does it have to be attached to a game object? Are there any good examples of a complex script setup?
As you have said in your question, you can use "GetComponent" at runtime to access references to other MonoBehaviour scripts.
The main ways to access other objects and other components are listed on these two manual pages:
However, there is one method that is quite unusual and very useful mentioned on those pages, but not in great detail. As a result, many beginners don't spot this feature, particularly if they are coming from other programming environments which don't have this concept, so I'm going to write it up in more detail here.
Drag-and-drop Editor References
I'm talking about the way that you can create references to scripts on other game objects by literally dragging and dropping GameObjects in the editor. I'm not sure if there's a specific technical term coined for these, but I'm going to call them 'dragged references' from here on. These are created by a simple two-step process:
Step 1: Create a variable in your script, whose type is the exact name of the type of script you want a reference to. For example: a simple "bat and ball" game. You have a player GameObject, which has a "Player" script attached, and a ball GameObject with a "Ball" script attached. In your "Player" script, you would have:
// in Javascript: var ball : Ball;
// or in C# public Ball ball;
This creates a public variable which can contain a reference to an instance of your "Ball" script. (In this example, the variable name is "ball" - a lower-case version of the script's name. This is a common convention, but you could pick any suitable name you like).
Because the variable is public, and your "Ball" script is effectively a Component (because it inherits from MonoBehaviour), the Unity Editor spots this, and makes the variable visible as a special "slot" which is visible in the inspector. You would need to click on your Player GameObject in the hierarchy to see this.
Step 2: Make sure the target variable slot is visible in the inspector, then click and drag the object which has the desired script to be referenced, from the hierarchy pane into the variable slot. This now makes an automatic reference which you can use at runtime to refer to the instance of that script. For the Player and Ball example, you'd click the "Player" object, so that you can see "Ball" variable slot. Then you'd drag the "Ball" GameObject from the hierarchy pane straight into that variable slot.
That's it.
You can also have a script which has variables that can contain references to other instances of the script itself. For example "ScriptA" might have a public variable which is also of type "ScriptA". A practical example of why you might want this could possibly be a tennis game, where you might have variables set up in the "Player" script like this:
// script is called "Player.js"
var ball : Ball; var otherPlayer : Player;
In this example, we have one public variable ready to have the 'ball' object dragged into it. However we also have a variable called "otherPlayer", whose type is "Player" (the name of the script itself). This is so that you could have two players, and each player would be set up with a dragged-in reference to the other player - their opponent.
You can also have arrays of dragged references. For example, in a game where there are ten targets to hit, and each target has a "Target.js" script attached, you might have this variable on the "Player" script:
// in Javascript: var targets : Target[];
// or in C# public Target[] targets;
This creates an array which can be filled with as many "Target" references as you like. In the inspector, you'd then assign the array a size of "10", and then drag each target gameobject into the 10 slots available in the inspector.
There are limitations to using Dragged References, the major one being that they become impractical when there are many references to be made. (For example, it would be incredibly tedious to drag-assign references from each team member to every other team member in a game of football!). In these cases, it's probably better to either write some script to grab these references at runtime using the methods mentioned in the link at the top of this answer, or write an Editor Script to help you automatically build these references at edit-time.
Duck's answer is great. Remember this method also works with instantiate - so one script can drive a script on all those instances.
Beware though, the drag&drop method makes adding new objects to the scene a lot more work than if the objects configure themselves. At least try to use http://docs.unity3d.com/Documentation/ScriptReference/RequireComponent.html where the presence of a script is required. I would opt to assign the properties through code, and save myself from the potential of hand maintaining hundreds of links. ball = gameObject.GetComponent<>() (I think there is a bug in the syntax parser, it shouls say ball in between there < Ball >.
Brilliant explanation Duck - I've been stumped for days and you've solved it - I had been dragging the script rather than the object which contained the script. Thanks.
if your script is a child of MonoBehaviour then you need to attach that script to a GameObject as a Component but if your script is not a child of MonoBehaviour you can create it with new keyword like other normal classes. don't use MonoBehaviours without attaching them to GameObjects because they always assume that they are attached to a GameObject and they use some of the properties of their attached GameObject. for example when you type scriptname.name it will try to get the this.gameObject.name and when you did not attach it, it fails and many other problems are available too. GetComponent takes a reference from your component and returns it to the caller and you can use methods and properties of the other scripts in current GameObject or others. use normal classes whenever it's possible and easy. they are more lightweight and you can use their constructors. they can be in an external dll, however you should create them by mono's command line yourself. go to angryant.com to see some complex scripts. path project is under GPL license and you can see it's source code and even use it under the terms of GPL.
Cool. Thanks. This clears up several issues I was having.
Like this you can access functions from other scripts.
// First class
using UnityEngine;
using System.Collections;
using System.Collections.Generic;
public class Class1 : MonoBehaviour
{
public void FunctionOne()
{
Debug.Log("Works!");
}
}
// Second class
using UnityEngine;
using System.Collections;
using System.Collections.Generic;
public class Class2 : MonoBehaviour
{
public Class1 class1;
public void Start()
{
FunctionTwo();
}
public void FunctionTwo()
{
class1.FunctionOne();
}
}
