FxShapeReplicator question
by John Vanderbeck · in Torque Game Engine · 04/07/2004 (6:59 am) · 11 replies
Is there some way to pass custom fields down to the actual shape that is replicated by this fx object?
#2
04/07/2004 (12:10 pm)
Was hoping there was some built-in way I was missing. I don't have any idea how the dynamic fields work, so I guess I need to do some digging and learn. I guess I could just add a regular field, I know how to do those, but that just seems like too much of a hack for me.
#3
04/16/2004 (6:26 am)
Is there a doc or snippet anywhere that explains how to use the fxShapeReplicator? I've searched the forums and don't see anything. I'm using it in the World Editor and I don't seem to be able to get any shapes to show up. I'm setting all the fields that I see (i.e. shape name, etc...).
#5
Try something like:
yourgame/data/shapes/trees/tree3.dts
Its very simple. You should see something just by setting the shapefile path.
04/16/2004 (6:45 am)
Jeff, I had the same problem, caused simply by an invalid shapefile path.Try something like:
yourgame/data/shapes/trees/tree3.dts
Its very simple. You should see something just by setting the shapefile path.
#6
04/16/2004 (7:03 am)
Yeah its pretty simple to use. Create the fxShapeReplicator in the mission editor. Enter a name, any name (I use the name of the shape file eg bldg00.dts is named bldg00). Enter the path to the shape file for example starter.fps/data/shapes/myshapes/myshape01.dts. Hit apply. Boom you got objects. Those are the only steps you NEED to take to get objects. Usually you would modify more of the behaviour but thats all you NEED to do. If you don't have objects showing up then you probably either have the wrong path to the shape file or a bad shape file.
#7
If you go to the 'fxShapeReplicatedStatic' class, you can add the following code:
You can then set the custom fields as normal in your own way. One place to set them is where they are created in 'fxShapeReplicator::CreateShapes'. Here's an example of a portion of the function setting the "testField" above.
You can enumerate them using the vector:
Hope this helps,
- Melv.
04/16/2004 (11:18 am)
John,If you go to the 'fxShapeReplicatedStatic' class, you can add the following code:
// ConObject.
static void initPersistFields()
{
// Initialise parents' persistent fields.
Parent::initPersistFields();
// Add your own persistent fields here...
addField( "testField", TypeF32, Offset( mTestField, fxShapeReplicatedStatic ) );
}You can then set the custom fields as normal in your own way. One place to set them is where they are created in 'fxShapeReplicator::CreateShapes'. Here's an example of a portion of the function setting the "testField" above.
// Create our static shape.
fxStatic = new fxShapeReplicatedStatic();
// Set the 'shapeName' field.
fxStatic->setField("shapeName", mFieldData.mShapeFile);
fxStatic->setField("testField", "123.0");You can enumerate them using the vector:
Vector<fxShapeReplicatedStatic*> mReplicatedShapes;.
Hope this helps,
- Melv.
#8
Yeah thats about what I figured i'd do for "static fields", IE fields that I know the names to. What I was _hoping_ to do though is make it more generic so everyone could take advantage of it. The editor allows you to enter "dynamic" fields. Basically fields that aren't predefined. What I was hoping to be able to do was make it so that you could define "dynamic fields" in the fxShapeReplicator datablock, and those would be "passed" down to the actual static shape instance filling in "static fields" in the shape instance.
That probably doesn't make sense, so let me try to give an example.
Let's say that your ShapeBase objects have a static field named oh I don't know, "powerStation". This is known as a static field to ShapeBase, and you use it to flag buildings that the player can use to recharge powered items. Not the best example, but its just an example.
You want to randomly scatter these amongsth the level, so you create a fxShapeReplicator object to replciate 10 of them. You add a "dyanamic field" called "powerStation" to the fxShapeReplicaotr object. This is a "Dynamic field" meaning fxShapeReplicator has no hard code to deal with it. fxShapeReplicator would, at creation of the static shapes, pass this field (and all unknown fields) down to the created object which would set it in its static field.
Now maybe i'm conpletely offbase and Torque doesn't support these "dynamic" fields, but its my understanbding from the editor that it does.
Does that make any sense? Sure I could hardcode all the fields we use for shapebase, but I was hoping to make somethign more flexible so that 1) If we add fields to shapebase, we wouldn't have to remember to add them to the replicator. Seems trivial but the more places you have to add/change the more chances for mistakes, and 2) So that others in the community could use this without having to touch the code.
04/16/2004 (11:30 am)
Melv,Yeah thats about what I figured i'd do for "static fields", IE fields that I know the names to. What I was _hoping_ to do though is make it more generic so everyone could take advantage of it. The editor allows you to enter "dynamic" fields. Basically fields that aren't predefined. What I was hoping to be able to do was make it so that you could define "dynamic fields" in the fxShapeReplicator datablock, and those would be "passed" down to the actual static shape instance filling in "static fields" in the shape instance.
That probably doesn't make sense, so let me try to give an example.
Let's say that your ShapeBase objects have a static field named oh I don't know, "powerStation". This is known as a static field to ShapeBase, and you use it to flag buildings that the player can use to recharge powered items. Not the best example, but its just an example.
You want to randomly scatter these amongsth the level, so you create a fxShapeReplicator object to replciate 10 of them. You add a "dyanamic field" called "powerStation" to the fxShapeReplicaotr object. This is a "Dynamic field" meaning fxShapeReplicator has no hard code to deal with it. fxShapeReplicator would, at creation of the static shapes, pass this field (and all unknown fields) down to the created object which would set it in its static field.
Now maybe i'm conpletely offbase and Torque doesn't support these "dynamic" fields, but its my understanbding from the editor that it does.
Does that make any sense? Sure I could hardcode all the fields we use for shapebase, but I was hoping to make somethign more flexible so that 1) If we add fields to shapebase, we wouldn't have to remember to add them to the replicator. Seems trivial but the more places you have to add/change the more chances for mistakes, and 2) So that others in the community could use this without having to touch the code.
#9
04/16/2004 (5:06 pm)
Sure, you could do that. Check out SimFieldDictionary.
#10
It didn't like that.
04/16/2004 (6:41 pm)
Thanks guys, I found out my problem. I was using the full path to the shape including the C:\TORQUE\EXAMPLE\ etc.,...It didn't like that.
#11
Not sure I completely understand the purpose of your request but Ben is correct with reference to the SimFieldDictionary. I'm probably a bit slow today. ;)
I did provide extensive functionality within my AI interface for Strategem that played around with the field dictionary of script-objects that allowed me to access/modify the dynamic fields within. The was handy because they could be created within the scripts and accessed easily within my C++ interface and vice-versa and provided a nice object transport between the two.
Although not directly related to your question, it should give you the pointer to where you need to go to look at access the field dictionaries.
- Melv.
04/17/2004 (7:00 am)
John,Not sure I completely understand the purpose of your request but Ben is correct with reference to the SimFieldDictionary. I'm probably a bit slow today. ;)
I did provide extensive functionality within my AI interface for Strategem that played around with the field dictionary of script-objects that allowed me to access/modify the dynamic fields within. The was handy because they could be created within the scripts and accessed easily within my C++ interface and vice-versa and provided a nice object transport between the two.
Although not directly related to your question, it should give you the pointer to where you need to go to look at access the field dictionaries.
bool fxAIInterface::convertFromScriptObject(S32 itemID, tStrategemItem& item)
{
// Get Script Object.
ScriptObject* fxSO = static_cast<ScriptObject*>(Sim::findObject( itemID ));
// Check for error.
if (!fxSO) return false;
// Fetch Field Dictionary.
SimFieldDictionary* dictionary = fxSO->getFieldDictionary();
// Step through item fields.
for ( typeItemFieldVector::iterator fieldItr = mItemFields.begin();
fieldItr != mItemFields.end();
fieldItr++ )
{
// Fetch Field Value.
const char* fieldValue = dictionary->getFieldValue( (*fieldItr).fieldName );
switch( (*fieldItr).fieldType )
{
// S32.
case Field_S32:
{
// Store S32 Field.
*((S32*)((*fieldItr).pData)) = dAtoi( fieldValue );
} break;
// F32.
case Field_F32:
{
// Store F32 Field.
*((F32*)((*fieldItr).pData)) = dAtof( fieldValue );
} break;
// Bool.
case Field_Bool:
{
// Store bool Field.
*((bool*)((*fieldItr).pData)) = dAtob( fieldValue );
} break;
// String.
case Field_String:
{
// Store String Field.
*((StringTableEntry*)((*fieldItr).pData)) = StringTable->insert( fieldValue );
} break;
}
}
// Store Item.
item = mItemTransfer;
// Return Okay.
return true;.- Melv.
Associate Kyle Carter
I don't think there's a builtin way.