1.7.1/1.8-b1 inspector scalability bug
by Kirk Longendyke · in Torque Game Engine Advanced · 11/15/2008 (4:08 pm) · 0 replies
While the new creator/inspector editing system introduced last rev does it's job quite well given the engines current constraints, extending it beyond listing singular datablock entries has proved problematic. as an example:
While more than a bit ugly to longhand, does in fact allow for multidatablock entries (after suitable back end modifications to add the entry capabiities to initpersistfields of course) the problem unfortunately arises when it comes time for the level designer to revisit a given datablock listing set via inspector, at which point they would be greeted with a set or dropdowns only listing, in this case, SpawnTriggerData.
long-windedness aside, a bit too pressed for time at present to properly track down just why mDesiredClass isn't checking the proper field, so for now (with apologies for the half-*cough*-edness of this one):
datablockfield.cpp:
Strips out the filtering, putting it back in a full-datablock listing state. Will note that while this one was a production blocker this end, it's also a cornercase most folks won't ever have to deal with, so simply documenting it here for completeness.
function ObjectBuilderGui::buildSpawnTrigger(%this)
{
%this.className = "SpawnTrigger";
%this.addField("TripCondition", "TypeString", "TripCondition", "");
%this.addField("Command", "TypeString", "Command", "");
%this.addField("TripOnce", "TypeBool", "TripOnce?", "true");
%this.addField("dataBlock", "TypeDataBlock", "Data Block", "SpawnTriggerData DefaultSpawnTrigger");
%this.addField("polyhedron", "TypeTriggerPolyhedron", "Polyhedron", "-0.5 0.5 -0.5 1 0 0 0 -1 0 0 0 1");
%this.addField("spawnRadius", "TypeInt", "Spawn Radius", "");
%this.addField("AutoAttackTarget", "TypeString", "AutoAttackTarget", "");
%this.addField("object[0]", "TypeDataBlock", "object[0]", "FlyingVehicleData");
%this.addField("SpawnCount[1]", "TypeInt", "SpawnCount[0]", "0");
%this.addField("object[1]", "TypeDataBlock", "object[1]", "FlyingVehicleData");
%this.addField("SpawnCount[1]", "TypeInt", "SpawnCount[1]", "0");
%this.addField("object[2]", "TypeDataBlock", "object[2]", "FlyingVehicleData");
%this.addField("SpawnCount[2]", "TypeInt", "SpawnCount[2]", "0");
%this.addField("weapon[0]", "TypeDataBlock", "weapon[0]", "ItemData");
%this.addField("UseProb[0]", "TypeInt", "UseProb[0]", "0");
%this.addField("weapon[1]", "TypeDataBlock", "weapon[1]", "ItemData");
%this.addField("UseProb[1]", "TypeInt", "UseProb[1]", "0");
%this.addField("weapon[2]", "TypeDataBlock", "weapon[2]", "ItemData");
%this.addField("UseProb[2]", "TypeInt", "UseProb[2]", "0");
%this.process();
}While more than a bit ugly to longhand, does in fact allow for multidatablock entries (after suitable back end modifications to add the entry capabiities to initpersistfields of course) the problem unfortunately arises when it comes time for the level designer to revisit a given datablock listing set via inspector, at which point they would be greeted with a set or dropdowns only listing, in this case, SpawnTriggerData.
long-windedness aside, a bit too pressed for time at present to properly track down just why mDesiredClass isn't checking the proper field, so for now (with apologies for the half-*cough*-edness of this one):
datablockfield.cpp:
GuiControl* GuiInspectorDatablockField::constructEditControl()
{
...
if( datablock && datablock->getClassRep()->isClass(mDesiredClass) )
...
}toGuiControl* GuiInspectorDatablockField::constructEditControl()
{
...
if( datablock)// && datablock->getClassRep()->isClass(mDesiredClass) )
...
}Strips out the filtering, putting it back in a full-datablock listing state. Will note that while this one was a production blocker this end, it's also a cornercase most folks won't ever have to deal with, so simply documenting it here for completeness.