No trolling guys. (Seriously)
And, yes, this code does work.
It’s not great code, but it does work.
Test1
#pragma strict
var script : Test2;
var potato = 2;
function Update () {
if (potato == 4)
Debug.Log ("It works!");
}
Test2
#pragma strict
function Update () {
GetComponent (Test1).potato = 4;
}
Now, a couple of notes:
First, it’s general practice to use PascalCase for Functions and ScriptNames, and camelCase for variableNames. PascalCase is where the first letter is Capitalized. camelCase is where the first letter is lowerCase. In general, it’s good to stay close withing the “best practice” zone so other people can easily read your code!
I’ve adjusted this in the code I’ve posted.
Next, a “hidden” step: To make this code work, both scripts MUST be on the same GameObject. This is how the GetComponent() works.What a GetComponent does is find a component on another GameObject. In a case like this, with no other GameObject specified, it will look on this GameObject. So, this code works because, and only if, both components are on the same GameObject. Test2 is looking, every frame, for a Component on this GameObject called Test1 and then trying to find the variable potato and then trying to set its value to 4. One particular downside to this code is the reference between these scripts is being done in Update, which means the same reference is looked up every frame. This is not efficient and can lead to slowdowns in your game.
In this case var script : Test2 is redundant, and does nothing. When you make a public variable like this, you can make a reference to another script, but you must find a way to set that reference. In Unity, the most common way of doing this is to drag the GameObject with the Component attached into the property field created by the public variable in the inspector. This will mean you can bypass the GetComponent step, which also grabs a reference by code, as you’ve created this reference in the inspector. As I said, in this case, you are not using this reference to Test2, so you don’t need it. It’s doing nothing and the reference is NULL.
For more information on this subject, you can look for my session on Communicating between Scripts and GameObjects.
To make this code work efficiently, you should try something like this:
Test1
#pragma strict
public var potato : int = 2;
private var changed : boolean = false;
function Update () {
if (!changed) {
if (potato == 4) {
changed = true;
Debug.Log ("It works!");
}
}
}
Test2
#pragma strict
private var otherScript : Test1;
private var changed : boolean = false;
function Start () {
otherScript = GetComponent (Test1);
}
function Update () {
if (!changed) {
changed = true;
otherScript.potato = 4;
}
}
What this code is doing is:
In Test1, we set up our int value. This is the value we will change. It’s public, so we can change it in the inspector. If it doesn’t need to be changed in the inspector, make it private. Then we create a boolean flag, so we don’t spam the console. With this logic, we will only get one message in our console. In Update we check every frame to see if we have changed our value to 4. If we have, then we flip our flag, so we will stop testing, and then print to the console only once.
In Test2, we set up our variable to hold the reference to our other script, but it’s NULL at this stage. It’s private, so we can’t set this in the inspector. We also set up another changed flag, so we don’t try to change this value every frame. We will set the reference to otherScript in the Start function, so we only have to find this reference once. This is more efficient that finding this reference every frame. If we made otherScript public, and we dragged the reference, we could remove the entire Start function. In Update, we check to see if we’ve change this value or not, and if we’ve not changed the value on Test1, then we use our reference to the otherScript, look for the variable potato and change its value to 4.
Does this make sense?