understanding IDs, Behavior tutorial
by Brian Carlson · in Torque 2D Beginner · 08/16/2015 (8:07 am) · 4 replies
Hello,
I'm having trouble understanding how IDs are assigned to Sprite objects. I'm currently working on the Behavior tutorial.
In the Deadly Reef main.cs file, the player fish and food are created:
I'm using the echos to track objects throughout the program and am carefully reading the console.log file output. Here, the IDs are listed off from the code above:
Why are the sprite IDs only odd? Or, put another way, what are the even numbers? I have to assume 1136 or 1138 exists and has something to do with the fish sprite created. Additionally, 1139 was "skipped over."
Later, in the function LifeTimeBehavior::die(%this), I used the following code...
fcn LTB::die() called
%this = 1139
%this.class =
An explanation or link to a resource that covers this would be very much much appreciate.
Thanks!
I'm having trouble understanding how IDs are assigned to Sprite objects. I'm currently working on the Behavior tutorial.
In the Deadly Reef main.cs file, the player fish and food are created:
function DeadlyReef::create( %this )
{
new Scene(mainScene);
...
DeadlyReef.spawnPlayerFish();
for (%i = 0; %i < 3; %i++)
DeadlyReef.spawnFishFood();
}
function DeadlyReef::spawnPlayerFish(%this)
{
%fish = new Sprite()
{
...
class = "Fish_class";
...
};
echo("fish sprite created");
echo(" %fish = " @ %fish);
}
function DeadlyReef::spawnFishFood(%this, %count)
{
%food = new Sprite()
{
...
class = "FishFood_class";
...
};
...
echo("sprite created: " @ %food @ ";");
}I'm using the echos to track objects throughout the program and am carefully reading the console.log file output. Here, the IDs are listed off from the code above:
fish sprite created %fish = 1137 sprite created: 1141; sprite created: 1143; sprite created: 1145;
Why are the sprite IDs only odd? Or, put another way, what are the even numbers? I have to assume 1136 or 1138 exists and has something to do with the fish sprite created. Additionally, 1139 was "skipped over."
Later, in the function LifeTimeBehavior::die(%this), I used the following code...
function LifeTimerBehavior::die(%this)
{
echo("fcn LTB::die() called");
echo("%this = " @ %this);
echo("%this.class = " @ %this.class);
...
}...and got this in the log:fcn LTB::die() called
%this = 1139
%this.class =
An explanation or link to a resource that covers this would be very much much appreciate.
Thanks!
#2
Thanks for getting back to me so quickly.
It's good to find out the preference for odd numbers doesn't mean anything.
As for the LTB::die(%this) question, I thought %this would be the sprite calling the function - the fish with ID 1137.
08/16/2015 (12:48 pm)
Richard,Thanks for getting back to me so quickly.
It's good to find out the preference for odd numbers doesn't mean anything.
As for the LTB::die(%this) question, I thought %this would be the sprite calling the function - the fish with ID 1137.
#3
This should get you Fish_class or FishFood_class. If it returns blank, try getClassName instead.
08/16/2015 (1:34 pm)
@Brian : %this always refers to the object calling the function, in this case, the instance of LifeTimerBehavior. If you use "owner", you can get the object which hosts the behavior.function LifeTimerBehavior::die(%this)
{
echo("fcn LTB::die() called");
echo("owner = " @ %this.owner);
echo("owner class = " @ %owner.class);
...
}This should get you Fish_class or FishFood_class. If it returns blank, try getClassName instead.
#4
08/17/2015 (8:02 pm)
Thanks Simon! That's very helpful
Torque Owner Richard Ranft
Roostertail Games
Now, having not read the tutorial in years, my first guess as to why LTB::die() says it's class is blank is because it is never assigned a class - it's a behavior instance and doesn't need one. LifeTimeBehavior is the name of a behavior template, when you assign a behavior to an object a behavior instance is created from that template and attached to the object. The instance has no name and no class - it's just an anonymous object attached to the other SimObject. The behavior system handles ensuring that the behavior acts like a script class, but it's smoke and mirrors.
A script class is a good way to build common functionality into a group of objects. By the same token, you could use a "factory" function that assigns the same set of behaviors to all objects it creates to achieve the same outcome - or a combination of the two approaches as you see fit.
As for "how" or "why" - you're going to have to start digging into the engine source and stepping through stuff with the debugger. You'll be able to follow the process step by step then and watch it happen.