Datablock question
by Anthony C · in Torque Game Engine · 05/17/2007 (2:28 pm) · 6 replies
No real code to look at here but i do have a question
So far ive looked at a lot of datablock samples, just to get an idea of whats in them. So naturally im assuming that a datablock is torque's C++ equivalent to class objects
So my question would be, is there predefined variables or do i just create a datablock like i would say "frisky the cat"?
could i do this..
datablock GoblinData(MonsterBase)
{
HP = 1000;
strength = 20;
garbageVar = true
}
I'm very confused with the setup of datablocks and whether or not there is already *data* that i must include
Any replies are appreciated in advance, ty :)
-tony
So far ive looked at a lot of datablock samples, just to get an idea of whats in them. So naturally im assuming that a datablock is torque's C++ equivalent to class objects
So my question would be, is there predefined variables or do i just create a datablock like i would say "frisky the cat"?
could i do this..
datablock GoblinData(MonsterBase)
{
HP = 1000;
strength = 20;
garbageVar = true
}
I'm very confused with the setup of datablocks and whether or not there is already *data* that i must include
Any replies are appreciated in advance, ty :)
-tony
About the author
#2
05/17/2007 (2:35 pm)
Unless GoblinData was written in C++, your example wouldn't work. However, a SimObject would work quite well for that.
#3
I CAN do this..
datablock PlayerData(Goblin)
{
//all of the mumbo jumbo thats in an example here
//my variables such as HP, strength, etc afterwards
}
yay, nay?
05/17/2007 (4:58 pm)
I read more, let me see if i understand..I CAN do this..
datablock PlayerData(Goblin)
{
//all of the mumbo jumbo thats in an example here
//my variables such as HP, strength, etc afterwards
}
yay, nay?
#4
All of the examples of datablocks that you see in the engine are a mechanism designed to allow scripters to modify and adjust the behavior of the underlying classes. The way this happens is something called persistent fields, which are basically variables for a class that both TorqueScript and c++ code can modify and use.
Within the source code, each datablock class has a series of member variables that are used within the source code to define various functionalities and capabilities of the class...for example, maxRunSpeed is the maximum player velocity an object of the class Player can have, and it can be defined by a scripter to be different for different types of players due to the use of datablocks. You could, for example, make a "LongDistanceMarathonData" player datablock with a medium maxRunSpeed, and a "SprinterData" player datablock with a very high maxRunSpeed.
What you have to keep in mind however is that all of the variables within the datablocks are defined by c++, and you cannot create new persistent fields in script--you can only change the values of the ones that are exposed by the c++ developer. Of course, since you have the source code (if you are licensed), you can add any c++ member fields you like, change the class implementation to use those variables, and then expose them to TorqueScript as persistent fields so scripters can modify them.
Now the second version of fields are dynamic fields, and these are fields that a scripter can create on an object at any time, for any reason. However, it's quite important to realize that the underlying c++ implementation is never aware of the existence or values of dynamic fields, and therefore the only way dynamic fields will impact the behavior of your object is if you write TorqueScript that accesses those values.
So long story short, while you can do what you say above (add dynamic fields to your Goblin playerdata datablock, the underlying code isn't going to see them or use them--you would have to write TorqueScript (or go into the c++ class itself and re-write portions of it) to actually use the new data.
We don't normally add in dynamic fields to datablocks like that however, because datablocks are shared amongst many objects--you may have 20 people in your game using the Goblin playerdata datablock--and they are all using the same copy. If you change a dynamic field on that datablock (or a persistent field for that matter), it would affect all players using that datablock.
05/17/2007 (6:39 pm)
Ok, just to jump in here a bit:All of the examples of datablocks that you see in the engine are a mechanism designed to allow scripters to modify and adjust the behavior of the underlying classes. The way this happens is something called persistent fields, which are basically variables for a class that both TorqueScript and c++ code can modify and use.
Within the source code, each datablock class has a series of member variables that are used within the source code to define various functionalities and capabilities of the class...for example, maxRunSpeed is the maximum player velocity an object of the class Player can have, and it can be defined by a scripter to be different for different types of players due to the use of datablocks. You could, for example, make a "LongDistanceMarathonData" player datablock with a medium maxRunSpeed, and a "SprinterData" player datablock with a very high maxRunSpeed.
What you have to keep in mind however is that all of the variables within the datablocks are defined by c++, and you cannot create new persistent fields in script--you can only change the values of the ones that are exposed by the c++ developer. Of course, since you have the source code (if you are licensed), you can add any c++ member fields you like, change the class implementation to use those variables, and then expose them to TorqueScript as persistent fields so scripters can modify them.
Now the second version of fields are dynamic fields, and these are fields that a scripter can create on an object at any time, for any reason. However, it's quite important to realize that the underlying c++ implementation is never aware of the existence or values of dynamic fields, and therefore the only way dynamic fields will impact the behavior of your object is if you write TorqueScript that accesses those values.
So long story short, while you can do what you say above (add dynamic fields to your Goblin playerdata datablock, the underlying code isn't going to see them or use them--you would have to write TorqueScript (or go into the c++ class itself and re-write portions of it) to actually use the new data.
We don't normally add in dynamic fields to datablocks like that however, because datablocks are shared amongst many objects--you may have 20 people in your game using the Goblin playerdata datablock--and they are all using the same copy. If you change a dynamic field on that datablock (or a persistent field for that matter), it would affect all players using that datablock.
#5
05/18/2007 (8:30 am)
Thank you Stephen for the very informative reply. It clears up a lot of questions I probably would have come up with down the line while explaining a little more about how torque works.
#6
no youre not required to specify anything other than the mesh model reference name for an object datablock, but understand that if you don't specify any data, the datablock will be initialized to default values. either specify only the properties that you need to be different, or just initialize every datablock property with a value.
05/18/2007 (9:59 am)
Quote:
I'm very confused with the setup of datablocks and whether or not there is already *data* that i must include
no youre not required to specify anything other than the mesh model reference name for an object datablock, but understand that if you don't specify any data, the datablock will be initialized to default values. either specify only the properties that you need to be different, or just initialize every datablock property with a value.
Torque Owner Ronald J Nelson
Code Hammer Games