How do I see my static vars? I want them to be public in the sense I can manipulate them in the Inspector.
I have tried
public static var hero1 : GameObject;
.
static var hero1 : GameObject;
.
static public var hero1 : GameObject;
None seem to show the object in the inspector.
:.?
You can’t see static variables in the inspector. Static means there’s only one instance, and all inspector variables are instanced, so it’s impossible.
–Eric
hmm.
well how would I declare what it is?
I mean what I did was create the vars as seen… so say…
static var hero1 : GameObject = nameOfObjectAlreadyInScene;
But that did not seem to work.
:.?
I doubt there’s any reason why you’d need to use static variables.
–Eric
well it was just that, I get an error when they are non static.
You see I placed them, make calls to them in a static function. I do this so I can call call that function from another script.
error:
I think you might need to go do a little study. You need to understand the difference between a class and its instances!
You don’t need to make a function static to call it from another script. Only use static for the specific reason of having one instance of a variable or function. Accessing from other scripts merely requires the variable or function to be public, nothing more. http://unity3d.com/support/documentation/ScriptReference/index.Accessing_Other_Game_Objects.html
–Eric
oh ok.
What about static variables and calling them.
Say,
static var xyz : boolean;
then using this, as a global var I can adjust from anywhere with ease.
.?
If that’s only meant to be one instance, it’s reasonable. Also you should look into singletons.
–Eric
Thanks Eric.
Can you explain what you mean? What it is in my thinking that makes you think that?
I see a Class as a script, with in that class is all of it’s vars.
I see an instance as a single object of that class, a var, a function… Am I way off? Those readings on the msdn boards are not too colorful.
:::)(
At the risk of sounding nit-picky, a Class is not a script. A Class is a Class. A script on the other hand is an instance of a Class. The two may be similar to you but there’s a fundamental difference between the two (much like “a cat is an animal but not all animals are cats”).
In C# and Java, everything is a Class. From the main method that runs the program, to data constructors, subroutines etc. Class is a very generic term that encompasses a lot of different things.
On to your issues.
static var hero1 : GameObject = nameOfObjectAlreadyInScene;
This will give you an error but not because you use the static keyword. You do either of the two following errors :
And you try to assign from level 0 a value to your static object that will be created at some abstract point in the future. Until then, that object reference is null. Which leads to Unity casting a Null Reference Exception to you on the console.
JohnnyA has a point in what he said. By trying to do either of the two things above, it’s clear you don’t fully understand the concept behind classes and instances. Hopefully now you do.
Given our explanation, the following code would do what you want.
static var hero1 : GameObject;
var nameOfObjectAlreadyInScene : GameObject;
function Start() {
if(!hero1)
hero1 = nameOfObjectAlreadyInScene;
}
Note that I first check if the static object is null before assigning it. We do that in order to prevent overwritting the value of hero1, in case it’s already assigned, given the fact that static members are never garbage collected, even between loading different levels.
Eric’s singleton approach takes my example above and instead of assigning an instanced value to a static member, it assigns an instanced class to a static class. The principle is the same but singletons can be expanded with a lot more functionality than what I just showed you.
Cool
thank you very much Diviner. This is clear but I need more time to digest it.
Much appreciated.
Ren
I use a lot of statics, one instance is a good idea in many circumstances.
To initialize them, use the start function of the script they are declared in.
To call them, use the name of the script or class with a period and then the name of the variable.
If you have a decent editor, like Monodevelop, they will come up in autocomplete when you name the class and put a period, so your spelling will always be correct. I find them extremely handy and they save memory.
my main reason for using them was to create globals i could access anywhere. but this is not necessary? why do you, as a programmer use them?
It’s mainly to get easy access from other scripts. They also save memory if use a static texture or something else that consumes a large amount of memory like an array and you only need one. You can use the same texture in different models and many times you only need one array.
No, no, no. This is a myth that seems to have perpetuated for some reason. A static variable is to be used when the value it contains should exist at the class level instead of the instance level. This is true across the board - in Unity or not.
True but I think they’re discussing in which point should that value exist on the class level instead of the instance level. I believe they’re trying to determine the functionality of doing something like that, and not the mechanics of actually doing it.
so this would mean, placing…
///class level
static var xToTheZ : boolean = true;
function Start()
{}
//instance level
function Start()
{
static var xToTheZ : boolean = true;
}
Then by doing either or, I can see no difference if they both existed in different versions of scriptXYZ. I can understand it being a bit of an issue on Update or in some other function that is called later in game. But there is no issue, as a programmer to do it like that is there? If so, why? This is just addressing what @kelsoMRK said and my understanding of Class level and instance level.
@Diviner I think so too, but this will help me. Solidify class and instance. For instance, ( no pun intended)…
An instance could be…
a script, object, var, function, array
A class could be anything? As all instances are children of a Class?
No, the two levels above are global and local, not class and instance. Instance level is the level that exists only when we instantiate an object of that class. You can tell instance level variables in the inspector by the fact that you can actually see them (class level variables are never shown in the inspector). The second part of your code (instance) would throw an error since we cannot declare static variables at the local level.
I can already see your brain ready to explode from so many terms thrown at you at the same time. My suggestion : don’t bother with terms. Let me clear up things for you answering this :
Think of a class as a prototype. Imagine that a class is a song in iTunes. There’s only one version of that song uploaded on iTunes and you can’t do anything to it directly. If I download that song on my iPhone however, i get a copy of that song. That’s the equivalent of an instance. As soon as I get a copy of that song, I can do anything to it (duplicate it, edit it, transfer it, etc) but any changes I do to it do not affect the original prototype uploaded on iTunes. That’s the difference between a Class and an Instance.
However, since we’re programmers, the language can’t really tell us we can’t do something. We’re programmers. We can do whatever the hell we want. That’s why languages like C# and Java give us Static members. And through static members, we can affect the prototype. Going back to my example above, imagine if you will that that uploaded song on iTunes had its volume as a static variable. That would mean that any user could edit that value directly without having to download the song first. And by editing the prototype’s volume, it would cause all subsequent downloaded songs to have reduced values as well.
That’s exactly what a static property is. It is a property assigned at the class (prototype) level that can be directly accessed without having to reference an instance of it, and which in turn, affects all instances that derive from it.
That’s why I said that a Class is a generic term. It’s not just a template that holds variables. It’s a ton of different things. In UnityScript though, a Class by definition is the prototype script (the one that exists in your Project tab, the text file) and any prototype custom class that either already exists or you create by yourself. And that’s all you should concern yourself with at the time being. Leave the terminology for after you’ve completely understood the basic concepts first. Otherwise you’ll only be more confused.