Getting the hang of TGB Scripting
by XanthorXIII · in Torque Game Builder · 05/27/2009 (10:56 pm) · 7 replies
So after about two weeks of reading nothing but code, going through Tutorials over and over again, I think I am starting to get some basic idea on scripting with TGB. I do have a question though on a few instances and what I have noticed.
In some of the cases of %this, I'll see a variable on the object being called as this,
What does the owner portion of the code specifically handle?
My other question deals with classes. I'm still struggling some with the class portion.
When editing an object you can attach it to a name, a class or a Super Class. In the examples I have seen the majority of them use the class. I've only seen one where it specifically gives the object a name and references it by name and the other was Solitare where I saw it using all three. I was wondering in what cases I would want to use a name, a class and a super class.
I'm getting there, it's still taking me a bit.
In some of the cases of %this, I'll see a variable on the object being called as this,
%this.owner.nameOfVariable;
What does the owner portion of the code specifically handle?
My other question deals with classes. I'm still struggling some with the class portion.
When editing an object you can attach it to a name, a class or a Super Class. In the examples I have seen the majority of them use the class. I've only seen one where it specifically gives the object a name and references it by name and the other was Solitare where I saw it using all three. I was wondering in what cases I would want to use a name, a class and a super class.
I'm getting there, it's still taking me a bit.
About the author
It's alive!
#2
Torquescript doesn't really have inheritance, so you can't say that Dragon is an Enemy and therefore get both blowFire and move. If Bob can blowBubbles, you can't say Bob is a dragon and get blowBubbles and blowFire
So as a kind of cheap hack around this, you can assign an object 3 classes - name, class and superclass. They're basically 3 different groups but prioritized - class is checked before superclass
Name is special because it refers to an object, not a class. You can say Bob.moveTo(%x, %y) and Bob will move because it's a real live object somewhere on the screen. You can't say Dragon.moveTo(%x, %y) because Dragon isn't an object, it's a class, in the same way that a blueprint of a house is not a house - you can live in a house, it's harder to live in a blueprint
You can give lots and lots of objects the same class (although you can't call methods on it, despite what some people want - you can't do Dragon.setVisible(false) and have all dragons go invisible). You can't do that with Name. But people try. i believe it compiles but results in your code doing weird, random things. When my students say their programs are possessed, i normally check to see if they have two objects with the same name. Don't do that, it's bad
05/27/2009 (11:14 pm)
Your second question - i have Enemys such as Dragons and Orcs. One of those Dragons is named Bob. Enemy has the function move(), Dragon (but not Orc) has the function blowFire(). There are lots of Enemys and lots of Dragons and Orcs but only one BobTorquescript doesn't really have inheritance, so you can't say that Dragon is an Enemy and therefore get both blowFire and move. If Bob can blowBubbles, you can't say Bob is a dragon and get blowBubbles and blowFire
So as a kind of cheap hack around this, you can assign an object 3 classes - name, class and superclass. They're basically 3 different groups but prioritized - class is checked before superclass
Name is special because it refers to an object, not a class. You can say Bob.moveTo(%x, %y) and Bob will move because it's a real live object somewhere on the screen. You can't say Dragon.moveTo(%x, %y) because Dragon isn't an object, it's a class, in the same way that a blueprint of a house is not a house - you can live in a house, it's harder to live in a blueprint
You can give lots and lots of objects the same class (although you can't call methods on it, despite what some people want - you can't do Dragon.setVisible(false) and have all dragons go invisible). You can't do that with Name. But people try. i believe it compiles but results in your code doing weird, random things. When my students say their programs are possessed, i normally check to see if they have two objects with the same name. Don't do that, it's bad
#3
"owner" tells the behavior where nameOfVariable is coming from. It comes from the owner of the behavior.
%this.nameOfVariable;
The above statment gets information from what ever object "nameOfVariable" was created in.
So if you wanted to use a variable from an object in a behavior, you need to call it from its owner. Like this:
%this.owner.nameOfVariable;
If you want to create and use a variable in a behavior for internal use, you would use this:
%this.nameOfVariable;
BTW... this is also the same way you call variables from objects. It can get confusing, but using 'owner' calls can kill processing time. Imagine if each behavior called 'getPosition' every cycle. That would drain the cpu over many objects. A better way to call getPosition would be to have the object call it once and then save the info. Then you would use %this.owner.xPos to retrive the info in each behavior. This is much cleaner and more efficient.
05/29/2009 (3:30 am)
%this.owner.nameOfVariable;"owner" tells the behavior where nameOfVariable is coming from. It comes from the owner of the behavior.
%this.nameOfVariable;
The above statment gets information from what ever object "nameOfVariable" was created in.
So if you wanted to use a variable from an object in a behavior, you need to call it from its owner. Like this:
%this.owner.nameOfVariable;
If you want to create and use a variable in a behavior for internal use, you would use this:
%this.nameOfVariable;
BTW... this is also the same way you call variables from objects. It can get confusing, but using 'owner' calls can kill processing time. Imagine if each behavior called 'getPosition' every cycle. That would drain the cpu over many objects. A better way to call getPosition would be to have the object call it once and then save the info. Then you would use %this.owner.xPos to retrive the info in each behavior. This is much cleaner and more efficient.
#4
Are you basically saying that the object's behavior is an object as well, and that local (%) variables inside the behavior (object) are only for that object? And if I needed to manipulate properties of the object from inside a behavior, I have to use object.owner.variable? That would solve some issues I was having.
05/29/2009 (6:09 am)
This is a great post. I was wracking(?) my brain trying to figure out the "owner" reasoning, myself.Are you basically saying that the object's behavior is an object as well, and that local (%) variables inside the behavior (object) are only for that object? And if I needed to manipulate properties of the object from inside a behavior, I have to use object.owner.variable? That would solve some issues I was having.
#5
05/29/2009 (9:20 pm)
Thanks Steven for the info. This is information that is truely missing from the documentation. I can see why I've been having issues trying to learn how to do TGB and now I'm feeling a lot more confident.
#6
Yes, that is correct! Behaviors are objects. Each behavior instance has a parent which is referred to via the "owner" member.
05/31/2009 (8:01 pm)
Quote:Are you basically saying that the object's behavior is an object as well, and that local (%) variables inside the behavior (object) are only for that object? And if I needed to manipulate properties of the object from inside a behavior, I have to use object.owner.variable?
Yes, that is correct! Behaviors are objects. Each behavior instance has a parent which is referred to via the "owner" member.
Torque 3D Owner baylor wetzel
Your first question is presumably about behaviors. For example, i might have the object Button and it might have a behavior Strobe. That behavior is attached to the object, sort of like a variable might be, looking a bit like Button.Strobe. Let's say you want to write some code to change the transparency of the button. If your code is in the button, you can write %this.setAlpha(%x);, where %this is Button. If your code is in a behavior, you could do the same thing but %this would be Strobe, and behaviors don't really have alpha. So you walk up the chain - %this.owner.setAlpha(x);, where %this is Strobe and owner is a pointer back up to the object that owns the behavior. It's like a pointer to a parent so it knows who it's modifying
By the way, i don't think that syntax is needed - you actually could do %this.setAlpha. i'm told that shouldn't work but i did it in several projects and it always worked. Don't know if it will stay working (or even if it works in the current 1.7.4)