Multiple Data Blocks?
by Jim Rowley · in Torque Game Engine · 07/29/2003 (11:44 am) · 6 replies
I've been stewing over how I dislike that torque copies the whole datablock when you use the syntax
datablock DataBlockType(newdatablock : parentdatablock).
I have a an idea where I want perhaps many types of a large datablock but with say one or two data variables set differently from eachother, and it seems wasteful that torque needs to copy the whole thing for each different data type if I have many.
First, I'm wondering if you create datablocks using this 'inheritance' syntax, does that make the loading phase where the datablocks are sent to the clients take any longer? Perhaps the code is written such that only the alterations to each inherited datablock are sent to the client before the new copy is built?
If not, then it might be possible to code a C++ datablock type which simply references an array of different datablocks to be used together to make up each object's persistent data.
I suppose the C++ syntax which references those datablocks would have to do so through indirection such as F32 field = mDataBlock->datablock[i]->field;
Has anybody tried such a thing, or is this even very beneficial?
datablock DataBlockType(newdatablock : parentdatablock).
I have a an idea where I want perhaps many types of a large datablock but with say one or two data variables set differently from eachother, and it seems wasteful that torque needs to copy the whole thing for each different data type if I have many.
First, I'm wondering if you create datablocks using this 'inheritance' syntax, does that make the loading phase where the datablocks are sent to the clients take any longer? Perhaps the code is written such that only the alterations to each inherited datablock are sent to the client before the new copy is built?
If not, then it might be possible to code a C++ datablock type which simply references an array of different datablocks to be used together to make up each object's persistent data.
I suppose the C++ syntax which references those datablocks would have to do so through indirection such as F32 field = mDataBlock->datablock[i]->field;
Has anybody tried such a thing, or is this even very beneficial?
#2
07/29/2003 (2:54 pm)
Quote:The data copy is performed by the scripting engine, so there is no optimization of the network bandwidth.
First, I'm wondering if you create datablocks using this 'inheritance' syntax, does that make the loading phase where the datablocks are sent to the clients take any longer? Perhaps the code is written such that only the alterations to each inherited datablock are sent to the client before the new copy is built?
Quote:By this do you mean datablocks where the fields that vary are the same or different? E.g if you had datablocks with fields a-z, would a & b vary in one datablock, c & d in the next, or would it always be a & b?
I have a an idea where I want perhaps many types of a large datablock but with say one or two data variables set differently from eachother, and it seems wasteful that torque needs to copy the whole thing for each different data type if I have many.
#3
Usually, if the variable you're controlling is going to be unique or nearly unique, it's better to just set it on the object.
(I agree that datablocks ought to inherit over the network, but for now, it's better not to try to change such low-level functionality... :))
07/29/2003 (3:04 pm)
Perhaps you should just move the variables you're manipulating into the individual objects?Usually, if the variable you're controlling is going to be unique or nearly unique, it's better to just set it on the object.
(I agree that datablocks ought to inherit over the network, but for now, it's better not to try to change such low-level functionality... :))
#4
But anyway ... I can see that it would be helpful to have a setup where say mass, and a few other fields were retreived from their own little datablocks. I guess the object instances would have to be pointing to multiple datablocks, so I'm now thinking this might be the way to go. ShapeData, SteeringData, PhysicsData, etc. They could then be loaded into the client once each, at startup, and the mission file could even set the object fields to point to the correct datablock for each object instantiated. I'm wondering if this is as simple as adding a few new persistent fields to the vehicle object which are datablock pointers.
I'm guessing that load time will be larger the way things are now, if the game has to download 25 copies of the whole vehicle datablock for such a small change in the vehicle types. Any more thoughts?
07/29/2003 (3:40 pm)
Well, for example I may have 25 different vehicle types that are all alike except for their mass is different. I have already taken Ben's approach and I'm using a mass field as part of the object rather than using the mass from the vehicle datablock for now. Thats been a little weird too because I need my client objects to have access to their mass field, and so it has been added through C++ rather than script. I've also had to modify some of the onNewDataBlock code to alter how vehicles set mRigid.mass from the datablock mass because I want the option of setting object instances mass in the mission file.But anyway ... I can see that it would be helpful to have a setup where say mass, and a few other fields were retreived from their own little datablocks. I guess the object instances would have to be pointing to multiple datablocks, so I'm now thinking this might be the way to go. ShapeData, SteeringData, PhysicsData, etc. They could then be loaded into the client once each, at startup, and the mission file could even set the object fields to point to the correct datablock for each object instantiated. I'm wondering if this is as simple as adding a few new persistent fields to the vehicle object which are datablock pointers.
I'm guessing that load time will be larger the way things are now, if the game has to download 25 copies of the whole vehicle datablock for such a small change in the vehicle types. Any more thoughts?
#5
I think you're overestimating the download requirements here; a datablock is maybe a kilobyte of data to transfer, tops, so you're adding a few seconds of network transfer time, even for a modem user...
And right now you just have one datablock, right, with different masses?
07/29/2003 (4:20 pm)
Why do you have so many different masses...?I think you're overestimating the download requirements here; a datablock is maybe a kilobyte of data to transfer, tops, so you're adding a few seconds of network transfer time, even for a modem user...
And right now you just have one datablock, right, with different masses?
#6
07/29/2003 (4:24 pm)
I want many different masses because my ship types each have different masses and I'm also currently using vehicles for my dynamic gravity wells which require a mass setting. Yes, I know a vehicle is a bit overkill for this, but I want planets which have a shape, exert gravity and move and collide so it was a good fit uless I decide to write my own Planet object. I'm also thinking that staticshapes which follow a path might be a way to do the planets. Thanks for the info on the download requirement though, perhaps I'll just use the old inheritance method to create my many datablock types afterall then.
Torque Owner Josh Albrecht
You want, for example, to have 10 different kinds of race cars, but the only differences are in a small number of the variables, and you dont want to have to duplicate all that data so many times.
If that's what you are wondering about, it's a good question. :) Check out the existing datablocks and see if there are any existing instances of some kind of inheritance. If there arent, I too am at a loss over what you should do.
However, unless you have 100s of datablocks, you should be ok just duplicating the data.