Accessing an object's script within its class definition

Unity Engine
1

For example…

class Bear
{	
	function BearStuff ()
		{camera.backgroundColor = bearown}
}

…does not work. How do I access the camera, attached to the game object that the following script would be attached to, using code in the Bear class?

var booboo : Bear;
2

This might not be the best way, but I use an initialize command on the GameObject that is using the class.

class Bear {
  private var owner : GameObject;
  function Initialize (go : GameObject) {
    owner = go;
  }
  function Growl () {
    owner.audio.Play();
  }
}
3

Do you mean for Bear to not be a MonoBehaviour? If you explicitly define the class you need to define it as class Bear extends MonoBehaviour. As is you can’t attach it to an object, so what you’re asking for doesn’t make much sense…

4

Sorry about the lack of sense-making; Unity doesn’t come with a manual for its JavaScript implementation. This code does work:

class Bear 
{  
	var beariable : int;
   	
   	function BearStuff () 
      {beariable = 1;} 
}

var booboo : Bear;

The Game Object to which that script is attached then shows an instance of the class, named Booboo, in the inspector. How do I affect that object’s attached camera.backgroundColor, for instance, from within a function, defined in the Bear class?

5

careyagimon has the right solution then. The Bear object instance is serialized and displayed in the inspector, sure, but it exists totally separate from the MonoBehaviour class referencing it. You’ll need to explicitly inform it:

class Bear
{ 
	var beariable : int;
	var go : gameObject;

	function Initialize(go:gameObject)
	{
		this.go = go;
	}
	
	function DoSomething()
	{
		Debug.Log("go is: " + go);
	}
}

// from here down we're actually in a second class definition (based on the filename)

var booboo : Bear;

function Start()
{
	booboo.Intialize(gameObject);
}

The thing is, you’re declaring two classes here–they could (and maybe should?) be in two separate files. One class is the intrinsically-named MonoBehaviour class, based on the filename, and the other is the Bear class you’re defining, which is derived from System.Object.

What are you trying to do?

If you want Bear to only exist on one GameObject, and to utilize other components on that GameObject, you should really think about making it a proper MonoBehavior. What benefit are you after by declaring outside of Unity’s constructs?

6

I’ve got this:

class Sky
{	
	function Sunrise (//input)
		{return //something done to input}
}

var sky : Sky;

function Update ()
{
	if (//conditions)
		 camera.backgroundColor = sky.Sunrise(//input);
}

and I want to move "camera.backgroundColor = " out of Update, because I think it’s ugly there. It’s not worth doing if it’s not simple, but I don’t see why it shouldn’t be.

7

Let’s say that script is named Environment.js. What you’ve actually got it:

class Sky
{   
   function Sunrise (//input)
      {return //something done to input}
}

class Environment extends MonoBehaviour
{
	var sky : Sky;

	function Update ()
	{
	   if (//conditions)
	       camera.backgroundColor = sky.Sunrise(//input);
	}
}

There are two separate classes here. If you wanted to keep them separate I would recommend simply adding the “parent” class to the input:

class Sky
{   
   function Sunrise (env:Environment //input)
      { // do something with env.camera.backgroundColor}
}

class Environment extends MonoBehaviour
{
   var sky : Sky;

   function Update ()
   {
      if (//conditions)
          sky.Sunrise(this //input);
   }
}

Really, though I would still recommend the simple route of creating two MonoBehaviour-derived components, Sky and Environment (and whatever that other one is). Sky would have easy access to the GameObject’s components, then…