Adding multiple datablocks
by Mehmet Kizil · in Torque Game Engine · 09/06/2005 (8:49 pm) · 3 replies
Ok, say I have a datablock that looks something like this:
Is it possible to create a new Datablock called Drill_Point1 and change the values within it on the fly? This would be so that when I read a file and extract positioning data from it I can create a new instance and a dts associated with it.
Say i'm reading co-ordinates from an externally generated text file and each line has a new x,y,z value associated with it. Kind of like a graph
I'm used to OO design where you can just add multiple objects inheriting what you need. Is this possible in Torque Scripting? For the record also, how heavy would the load be to create say 300 or so models all part of a datablock that is different from the last?
BTW this is in a "Single Player" type simulation..
new Drill_Point()
{
position = "x,y,z";
rotation = "1 0 0 0";
scale = "1 1 1";
.
.
vector_to_end =
3D_Model = "eitherYelloworRed.dts"
};Is it possible to create a new Datablock called Drill_Point1 and change the values within it on the fly? This would be so that when I read a file and extract positioning data from it I can create a new instance and a dts associated with it.
Say i'm reading co-ordinates from an externally generated text file and each line has a new x,y,z value associated with it. Kind of like a graph
I'm used to OO design where you can just add multiple objects inheriting what you need. Is this possible in Torque Scripting? For the record also, how heavy would the load be to create say 300 or so models all part of a datablock that is different from the last?
BTW this is in a "Single Player" type simulation..
#2
There is a fundamental stumbling block for many people as to the purpose of datablocks. The best way to think of datablocks is to consider them an optimization for networking: the idea is that datablocks contain static data that is referenced by many of your game objects, and they are not intended to be modified on the fly, during runtime.
How they work is that if you implement your project around this concept, you can download to the client a lot of information at a time (mission startup/loading) to the client(s) when the human player is willing to accept a large (observationally speaking) amount of "non-interactive" time. It's pretty much human nature to expect a 30-60 second delay at the start of a game/mission, so we mass push a lot of data to the client(s) in this time. That way, when the game is actually "live", we can only network the information that is critical to the player's observations, and not worry about sending absolutely everything the client needs to let the client observe it.
A perfect example here is the "first" time you see a new, enemy player. Since we've already delivered the datablock to each client, all we need to do for the client to see this new enemy is send a quick initial update about the enemy's state: position, maybe health, etc., as well a single data element telling the observing client which datablock (already delivered) to use when rendering/modelling this enemy.
Had we not delivered all of this information in the datablock at the start of the mission, we would need to deliver each and every single piece of information about this new enemy: what dts to use to render, what it's physical characteristics are, what it's animation information is like, etc. This obviously would take quite a bit of network time/performance to do, so as an optimization strategy Torque Networking gives us datablocks and an efficient way to use them to optimize network traffic.
Moral of the story: datablocks should contain reference information that is both static, and common to many objects. Design your project with the concept in mind that datablocks (all of 'em!) are delivered to the clients during mission startup, and information that is either unique, or very dynamic, to a particular object should be part of the object itself, not the datablock.
09/06/2005 (11:12 pm)
Just to follow up on what Ben said:There is a fundamental stumbling block for many people as to the purpose of datablocks. The best way to think of datablocks is to consider them an optimization for networking: the idea is that datablocks contain static data that is referenced by many of your game objects, and they are not intended to be modified on the fly, during runtime.
How they work is that if you implement your project around this concept, you can download to the client a lot of information at a time (mission startup/loading) to the client(s) when the human player is willing to accept a large (observationally speaking) amount of "non-interactive" time. It's pretty much human nature to expect a 30-60 second delay at the start of a game/mission, so we mass push a lot of data to the client(s) in this time. That way, when the game is actually "live", we can only network the information that is critical to the player's observations, and not worry about sending absolutely everything the client needs to let the client observe it.
A perfect example here is the "first" time you see a new, enemy player. Since we've already delivered the datablock to each client, all we need to do for the client to see this new enemy is send a quick initial update about the enemy's state: position, maybe health, etc., as well a single data element telling the observing client which datablock (already delivered) to use when rendering/modelling this enemy.
Had we not delivered all of this information in the datablock at the start of the mission, we would need to deliver each and every single piece of information about this new enemy: what dts to use to render, what it's physical characteristics are, what it's animation information is like, etc. This obviously would take quite a bit of network time/performance to do, so as an optimization strategy Torque Networking gives us datablocks and an efficient way to use them to optimize network traffic.
Moral of the story: datablocks should contain reference information that is both static, and common to many objects. Design your project with the concept in mind that datablocks (all of 'em!) are delivered to the clients during mission startup, and information that is either unique, or very dynamic, to a particular object should be part of the object itself, not the datablock.
#3
09/07/2005 (6:32 am)
Thanks Ben and Stephen 
Associate Kyle Carter
All the "inheritance" that TorqueScript supports is copying parameters from another object before overriding them with new params, and also some namespace stuff.
I'd suggest reading a good TorqueScript document to help clear this stuff up in your mind. 3DGPAIO is one good bet; there are also some other excellent tutorials online. (I'd link you, but I don't really use them... I typically answer my questions about how TorqueScript works by reading the source. ;)