Can't instantiate user defined classes (non-conobject)

#1 I tried again with this code:
-----------------------------------------

new SimObject(inicializadorDeJogo){}

-----------------------------------------

And it worked!

So... the name defines the type of the object??? The documentation said a completely different thing!

#2 No, the name doesn't define the type of object--but the root problem is that you cannot create a true class to instantiate in TorqueScript.

The "new" operator only allows you to instantiate c++ classes (such as ScriptObject, SimObject, t2dAnimatedSprite) and so forth. To create completely new classes in the true "object oriented" sense, you need to have a source code license, and implement them in c++.

There are many alternative techniques, and well thought out use of namespaces accomplishes most of the things you need in a "new class", but TorqueScript is not a true object oriented language, and you cannot create completely new (true) classes dynamically with it.

#3 Thanks Stephen! And, can you cite one of the alternative techniques? ... the one you think is the most adequate? Or point me to some doc? All I want is to create something that holds variables and methods...

And why does that line of code (new SimObject(TYPEOFTHEOBJECT){};) works? The object created is of the exact type I wanted (all methods are present...)

When I decided to use TGB and not TGX it was because I though scripting would be more productive than strongly typed, compiled languages... I still believe that is the case, but what do you think? Torque X is more adequate for OO programmers (since it supports C#)?

Another big question: what is the real purpose of TorqueScript? It seems to me that it was created to be just be a "caller" of the "real game objects" created in C++ (and by game objects I mean my user defined classes)... if that is so, I need to upgrade my license, because I'm using TorqueScript to the wrong purpose... I was trying to create a full game using only TS...

#4 You can define namespaces for your script functions, eg,
function Class1::method1(%this)
{}

Now If you create an type of torque object you can assign its class field to "class1", eg,
%obj = new T2DStaticSprite()
{
class = "Class1";
}

now you may call the function with,
%obj.method1();

You may also specify a superclass (which is like the parent class), this allows you one level of inheritence in script. That function can also be called explicitly like,
class1::method1();

But the %this parameter in that case will be an empty string (""), if you do call it from a class object the %this parameter will be the object id and is supplied automatically. This is the only use of the class field, it does not allow inhereted class variables or anything like that. To initialize your simobject fields you can use config datablocks, which you can derive from one another.

Heres a thread on config datablocks.
www.garagegames.com/mg/forums/result.thread.php?qt=66492

#5 James, now it works... the problem was that I was trying to create a direct subclass of SimObject (as you can see in my first post), wich doesn't seems to be possible...

Using t2DStaticSprite as my base class worked allright:

%obj = new T2DStaticSprite()
{
class = "Class1";
}

But... for performance issues and code readability, I think we should derive only from "real" base classes...
I mean, in Java every object derives from "Object"...

Is there a more "generic" class that my objects could derive from?
For example, I have a class named "EventManager"... if I start to write things like this...

%obj = new T2DStaticSprite()
{
class = "EventManager";
}

...my code could start to get very confusing, as this "EventManager" was never meant to be a sprite...

#6 As soon as I finished writing the previous post I found it...

ScriptObject is the guy we were looking for ^_^
It seems to be the right choice to be our base class!

Found it on a totally non correlated topic: http://www.garagegames.com/mg/forums/result.thread.php?qt=39899

Blessed end-of-night-sintax-error! =)

#7 Also check out SimSets and SimGroups (which are the same as simsets but adding an object to one removes it from all others). I have SimSets of ScriptObjects all over the place in one of my projects for keeping track of game data. For instance if your event manager needs to keep a queue of events you could make your event manager a simset or just have a simset as a field within your eventmanager. Or you could find a similar use of simsets within your eventmanager for dealing with "subscriptions" and "eventtypes". Now I'm curious, what type of events will your event manager be dealing with?

#8 Just to some provide insight, both ScriptObject "inheritance" and the normal TGB method of using the correct underlying c++ class, and then assigning the "class" persistent field to mimic your derived class are actually the same thing. You don't really gain anything at all from using a ScriptObject any longer--it's better to just use the class/superclass persistent fields.

TGB deprecated needing to use ScriptObject by allowing the use of the "class" and "superclass" persistent fields on any Torque object. Neither is true inheritance like Java has, because TorqueScript is not in fact a fully object oriented language--it just mimics key and useful features of object oriented programming.

#9 You said "You don't really gain anything at all from using a ScriptObject any longer--it's better to just use the class/superclass persistent fields."

Well... what I wanted to gain by using ScriptObject is "readability" (not performance), and I think I achieved that, don't you think?...

And I don't understand what you mean by "it's better to just use the class/superclass persistent fields". My code is like this:

%obj = new ScriptObject()
{
class = "EventManager";
}

So, I supose I am actually using the class' persistent field, right?

If I use this type of code...:

%obj = new T2DStaticSprite()
{
class = "EventManager";
}

...I supose I'm not overriding the T2DStaticSprite functions, but "merging" those classes... I mean, all T2DStaticSprite functions will be available to my instance, even if I don't need them, they doesn't make sense to my object. That being said, the best practice would be to use ScriptObject, right?

You also quoted the use of a "correct underlying c++ class", but my question was about what to do when there is no "correct underlying class", you see? Like my "EventManager" class (or a "ScoreKeeper" class etc), that has no underlying class to use...

#James

Sorry for my late answer, the event I was managing was the "Missile Fired" (so that the enemies in range could avoid being hit). Now I know I didn't needed a new class to handle this event: I could an existing callback. But I think there are situations were there will be no built in callback to handle the event...

PS: now I'm using SimSets to store them (and the "subscribers" of the event) ;)

#10 You are correct, if the "class" (again, we need to make sure that you understand that there are no true object oriented classes in TorqueScript--it's not a fully object oriented language like Java) you want to implement does not directly relate to something like a SceneObject, or AnimatedSprite, or other "core" objects in a scene, then ScriptObject is fine.

The case where a ScriptObject does not make sense would be something like an Asteroids game, where you want "classes" for BigAsteroid, MediumAsteroid, and SmallAsteroid.

All of those should simply be t2dAnimatedSprite (or t2dStaticSprite if you wish), with a class = "BigAsteroid"; style line in the instantiation.

Sorry for skipping over the second explanation you mentioned, I saw the "class1" and answered that immediately.