Class ?

Greetings,

my eyes met the following code here :

private var playerList = new ArrayList();
class PlayerNode {
	var playerName : String;
	var networkPlayer : NetworkPlayer;
}

private var chatEntries = new ArrayList();
class ChatEntry
{
	var name : String= "";
	var text : String= "";	
}

Is it the exact same thing as making .js files called PlayerNode and ChatEntry ? Or are they some nuances ?

what are you trying to achieve ?

no a class is just like a normal var
like

var number : int = 4;

the same for a custom class

var Class = new chatEntry; 
Class.name = "jeff";
Class.text = "hallo";

it is like making a var in two pieces

Reverse engineering. I am still looking carefully at the M2H tutorial, it was there. And few lines later, there is :

	var newEntry : PlayerNode = new PlayerNode();
	newEntry.playerName=playerName;
	newEntry.networkPlayer=Network.player;

I thought a gameObject was required when instantiating a component (array and such things are not component and do not require gameObjects), so it bother me.

Must I understand it is not the same thing ? (writing in code class SpecialName, and creating a SpecialName.js file)

I read your answer demonicmetal.cs, I will do some tests. Thanx you both !

array’s are not componets of gameobjects no
and making a custom class is mot lijke a new .js file

what are you making tell me so I can help

I am not trying to make you tell me something anymore, you already answered :wink:

oke

In a first .js file

class Card{
	var value : int;
	var skin : String;
}

In a second .js file

function Start () {
	var newCard : Card = new Card ();
	newCard.value = 5;
	newCard.skin = "hearts";
	print (newCard.value);
	print (newCard.skin);
}

Output in console :

Pretty powerful !

You can declare public classes in files containing (and named for) other classes in both JS and C#. Remember that Javascript files are essentially wrapped by

class MyClassName extends MonoBehaviour {
    //The contents of your file
}

So the short answer is, yes, in that code you posted, it’s like having separate files like so:

PlayerNode.js

var playerName : String;
var networkPlayer : NetworkPlayer;

ChatEntry.js

var name : String= "";
var text : String= "";

ChatManager.js

private var playerList = new ArrayList();
prvate var chatEntries = new ArrayList();
//etc.

It’s helpful in Javascript for things like a chat system where you want a separate class containing message information (sender, message, etc). Since you can’t make structs in JS, it can be convenient to place this class with your chat manager class. I wouldn’t recommend putting more than one larger class in the same file mostly because it makes it harder to debug problems.

Reading your answer, burnumd, I got some additional thoughts, thank you.

I tried something :

class ClassTest {
	var sentence : String = "Sentence from script reached";

	function RelatedFunction () {
		print ("Related function reached");
	}
}

function Start () {
	var instance : ClassTest = new ClassTest ();
	print ("instantiated");
	print (instance.sentence);
	instance.RelatedFunction ();
}

Everything goes smoothly except the function RelatedFunction is not called.

In the case I write :

class ClassTest extends MonoBehaviour

The function is called with the rest but before that, I get a warning message :

I guess using the word “class” to define some exotics kind of container (like an entry chat, or a player node, or a card) is ok, but is not appropriate for functions ?

The function gets reached, it’s just that print is a method of MonoBehaviour. So that’s why it works when your inner class extends MonoBehaviour (see here for more info). Replace “print” with “Debug.Log” and it works as is. You should consider using Debug all the time anyway for debugging purposes, as it allows you to specify the context for the message as well as set different levels (Log, LogWarning, and LogError). As for the warning you mention, you’re not supposed to use “new” to create MB’s, as there’s a lot of set-up done internally by Unity with those. If you want to create a MB in a scene, here’s is the preferred way:

var holder : GameObject = new GameObject ("MonoBehaviourHolder");
var instance : MyClass = holder.AddComponent(MyClass);

It seems it was reached, finally, Debug.Log worked.

Acknowledged, but I did not use print for debugging purpose, but to see whether I could define functions in addition to variables inside these class. :wink:

So, in the end, making a gameObject is required ?

I guess class can help defining additional variables types, as long as they don’t extend MonoBahaviour. Thank you !

It was always getting reached, it’s just that print wasn’t doing anything.

Not necessarily. If you want to create the MonoBehaviour from another MonoBehaviour, you can just use var instance : MyClass = gameObject.AddComponent(MyClass); to add it to the GO the existing MB is already on.

So, in the end, a gameObject is required ?

But adding plenty similar component on the same gameObject can be a pain ? How to retrieve the right component when wanted ?

I keep in mind all those precious information for the future :wink:

For MonoBehaviours, yes.

It’s roughly the same amount of typing:

var instance : MyClass = new MyClass ();
var instance : MyClass = AddComponent (MyClass);

You can either store the instance as a public variable in the originating class or use GameObject.GetComponent

If the gameObject has 100 components MyClass, I doubt it will give us the right component :?:

gameObject.GetComponents get all components of that type, so you can do a For loop and find the one you need.
Its Slow so you might as well have just made an array of MyClass if you have 100! (or references to them)

Yes, I was talking about uncommon situations for my…culture. I take all tips, stories, and advices. I will think about it :wink: