Game Development Community

T3D 1.1 Beta 3 - PlayerDropPoints are not added to their SimGroup automatically - LOGGED

by Flashback · in Torque 3D Professional · 03/01/2011 (8:19 am) · 13 replies

Build: 1.1 Beta 3 Pro

Platform: Windows XP (doesn't matter, though)

Target: World Editor

Issue: When created in World Edtor, level objects aren't added to their respective simgroups after being created. For example, new PlayerDropPoint doesn't get added to PlayerDrpopPoints group.

Steps to Repeat:
1. Launch the game
2. Start world editor
3. Go to Library tab -> Level tab
4. Double-click "Player Drop Point" item
5. Press "Create New" button in following dialog window
6. Go to Scene Tree and make sure that newly created object is not in "PlayerDropPoints", but in the root of "MissionGroup".

Suggested Fix:
The problem is with "ObjectBuilderGui.newObjectCallback" code that was added sometimes since 1.0.1. Not sure what for, but in objectBuilderGui.ed.gui, ObjectBuilderGui::processNewObject, around line 539 it will call "EWCreatorWindow.onFinishCreateObject", which has the following body:

function EWCreatorWindow::onFinishCreateObject( %this, %objId )
{
   %this.objectGroup.add( %objId );
   if( %objId.isMemberOfClass( "SceneObject" ) )
   {
      %objId.position = %this.getCreateObjectPosition();
      //flush new position
      %objId.setTransform( %objId.getTransform() );
   }
   %this.onObjectCreated( %objId );
}

In the first line, it adds our new object to EWCreatorWindow's objectGroup. Which is MissionGroup by default. And this happens after ObjectBuilderGui has already correctly added the object to its appropriate group (see ObjectBuilderGui::processNewObject, around line 526).

This harmful callback is set in creator.ed.cs, EWCreatorWindow::addMissionObjectIcon function, around line 676:

%ctrl.altCommand = "ObjectBuilderGui.newObjectCallback = "EWCreatorWindow.onFinishCreateObject"; EWCreatorWindow.createObject( "" @ %cmd @ "" );";

In 1.0.1 it looked like this, so didn't cause any problems:

%ctrl.altCommand = "EWCreatorWindow.createObject( "" @ %cmd @ "" );";

Possible solution is obvious (returning this line of code to the state of 1.0.1), but I guess this callback thing was added for something.
NextNext Thread
PrevPrevious Thread
More from Torque 3D Professional


Torque 3D Owner Flashback
#1
03/01/2011 (9:11 am)
UPD: Actually, possible obvious solution is not a very good one, since object positioning is now done via EWCreatorWindow::onFinishCreateObject, so calling it is a must.
So, another hacky but this time working solution would be to set some kind of flag, to let EWCreatorWindow know that ObjectBuilderGui took care of setting parent group for our object:

In ObjectBuilderGui::reset add line:

%this.objectGroupSet = false;

In ObjectBuilderGui::processNewObject add bolded lines:

function ObjectBuilderGui::processNewObject(%this, %obj)
{
   if ( %this.createCallback !$= "" )
      eval( %this.createCallback );
   
   // Skip out if nothing was created.   
   if ( !isObject( %obj ) )
      return;
      
   // Add the object to the group.
   if( %this.objectGroup !$= "" )
   {
      %this.objectGroup.add( %obj );
      [b]%this.objectGroupSet = true;[/b]
   }
   else
      EWCreatorWindow.objectGroup.add( %obj );
      
   // If we were given a callback to call after the
   // object has been created, do so now.  Also clear
   // the callback to make sure it's valid only for
   // a single invocation.

   %callback = %this.newObjectCallback;
   %this.newObjectCallback = "";
   
   if( %callback !$= "" )
      eval( %callback @ "( " @ %obj @ " );" );
   [b]%this.objectGroupSet = false;[/b]
}

In EWCreatorWindow::onFinishCreateObject, add a condition before the first line, like this:

if(ObjectBuilderGui.objectGroupSet == false)
   %this.objectGroup.add( %objId );

Torque Owner Nathan Martin
TRON 2001 Network
#2
03/01/2011 (9:17 am)
What you are seeing is that the MissionGroup is the default destination for new objects because it is the top most level SimGroup available. To know which SimGroup that new objects will be placed into by the open folder icon that is yellowish in color in the scene tree view. To select which SimGroup that new objects should be placed under you should right-click on the SimGroup and select Add New Objects Here.

I don't know the real reasons for the change, but I have a feeling it was causing more trouble for those who like to have custom SimGroups for various objects like player spawn points when you're creating a world for multiple teams for example like real players vs AI bots.

Now there is one bug that I believe they're aware of is that when you close out of the world editor to test out the changes and return back to the world editor the scene tree view "forgot" which SimGroup you had the Add New Objects Here set to.

Torque 3D Owner Flashback
#3
03/01/2011 (9:23 am)
I see your point, Nathan, but it is really a bug, imo, since lots of code still implies auto-assigning certain types of objects to their SimGroups. For example, see this:

function ObjectBuilderGui::buildPlayerDropPoint(%this)
{
   %this.objectClassName = "SpawnSphere";
   %this.addField("dataBlock",    "TypeDataBlock", "dataBlock",   "MissionMarkerData SpawnSphereMarker");
   %this.addField("radius",       "TypeFloat",     "Radius",        1);
   %this.addField("sphereWeight", "TypeFloat",     "Sphere Weight", 1);

   %this.addField("spawnClass",     "TypeString",    "Spawn Class", "Player");
   %this.addField("spawnDatablock", "TypeDataBlock", "Spawn Data", "PlayerData DefaultPlayerData");

   if( EWCreatorWindow.objectGroup.getID() == MissionGroup.getID() )
   {
      if( !isObject("PlayerDropPoints") )
         MissionGroup.add( new SimGroup("PlayerDropPoints") );
      %this.objectGroup = "PlayerDropPoints";
   }

   %this.process();
}

See the "if" part. SimGroup "PlayerDropPoints" is still created, and Torque users still expect PDPs to go there. Not speaking of all the custom game classes that use this functionality.

P.S. Any "Add New Object Here" issues, if there are any, are not related to this thread.

Associate Scott Burns
GG Alumni
#4
03/01/2011 (9:41 am)
This is not a bug, it's as designed. Like Nathan said, you have to select the SimGroup for objects to be added to when creating them otherwise they will default to being added to the MissionGroup. Objects in the tree can also be drag and dropped into a SimGroup after the fact in the tree.

SimGroups are a SimSet that's entirely user defined while building levels. The only default SimGroup, and uncustomizable, SimGroup is the MissionGroup. PlayerDropPoints only exists in the FPS Example and not in the templates.

Torque 3D Owner Flashback
#5
03/01/2011 (9:46 am)
If it's so, then there is plenty of code that does nothing in the world editor scripts. Code snippet from my previous post is from Empty Template, so ObserverDropPoints and PlayerDropPoints *are* in templates.

I see the thread got renamed already, and the problem will be ignored, most likely. Well, I got it fixed anyway, and everyone who needs functionality that is in, but broken, can find a solution in the first reply post.

Torque Owner Nathan Martin
TRON 2001 Network
#6
03/01/2011 (11:10 am)
No I was wrong and Flashback was actually correct. The code block he pasted in response to my comment shows that if MissionGroup is currently selected SimGroup for new objects then it'll try to place the Player Spawn Sphere into PlayerDropPoints SimGroup.

I went in and did my own research into the problem, and I agree with Flashback's assessment it's the %this.objectGroup.add( %objId ); in function ObjectBuilderGui::processNewObject(%this, %obj) that causes the object to get moved to MissionGroup SimGroup because %this.ObjectGroup is being changed after function ObjectBuilderGui::buildPlayerDropPoint() is called.

I'm currently trying to figure out why and where %this.ObjectGroup is being reset back to MissionGroup's ObjectID.

Torque 3D Owner Flashback
#7
03/01/2011 (11:19 am)
Quote:I went in and did my own research into the problem, and I agree with Flashback's assessment it's the %this.objectGroup.add( %objId ); in function ObjectBuilderGui::processNewObject(%this, %obj) that causes the object to get moved to MissionGroup SimGroup because %this.ObjectGroup is being changed after function ObjectBuilderGui::buildPlayerDropPoint() is called.

I'm currently trying to figure out why and where %this.ObjectGroup is being reset back to MissionGroup's ObjectID.

My investigation showed that ObjectBuilderGui.objectGroup is fine, it's not overridden anywhere. It's just that later on, when eval(%callback...) is executed in processNewObject, EWCreatorWindow::onFinishCreateObject gets called. And EWCreatorWindow has own objectGroup field (pretty confusing). And since EWCreatorWindow.objectGroup is MissionGroup, objects snap back to MissionGroup, no matter where they had to go previously.

Torque Owner Nathan Martin
TRON 2001 Network
#8
03/01/2011 (12:26 pm)
Ah, I missed that. I guess I really should start looking into using a real torque script debugger instead of just echo() placing in various functions trying to debug this. After thinking and playing around with various methods of resolving the problem I think this modification should solve the problem as a quickfix:

UPDATE: Do NOT use this bugfix as it will prevent you from being able to delete world objects like Path Nodes in the editor, for now simply use the method described above (Add New Objects Here) to place new objects into a specified SimGroup.

function EWCreatorWindow::onFinishCreateObject( %this, %objId )
{
   // BugFix: add created object to a SimGroup only if not parented
   if(%objID.parentGroup $= "MissionCleanup")
      %this.objectGroup.add( %objId );

   if( %objId.isMemberOfClass( "SceneObject" ) )
   {
      %objId.position = %this.getCreateObjectPosition();

      //flush new position
      %objId.setTransform( %objId.getTransform() );
   }

   %this.onObjectCreated( %objId );
}

Of course the real bug is that we've got issues of two different classes calling each other and each having their own ObjectGroup dynamic variable. Somebody needs to rethink the whole thing.

Torque Owner Nathan Martin
TRON 2001 Network
#9
03/07/2011 (8:42 am)
Ignore my suggested bugfix above as it is causing objects like Path Node prevented from being deleted in the world editor. I'll try to come up with another solution later on in the week.

Associate Scott Burns
GG Alumni
#10
03/18/2011 (11:14 am)
Finally had a chance to come back around to this one. I was actually thinking of the early betas before. There was a lot of back and forth between GG and those of us in the community then on what groups should exist by default and what should get added to them.

According to the script, yes this is a bug. I've gone ahead and logged it for investigation. It wouldn't surprise if this was short circuited somehow.

Logged as THREED-1490, title updated to match bug report.

Torque 3D Owner ITS_Nick
#11
03/18/2011 (11:21 am)
Yay! So this is going to be working in future releases - nice to know.

Associate Scott Burns
GG Alumni
#12
03/18/2011 (11:23 am)
That's not necessarily the case. It's been logged to be looked in to, but there are many more higher priority issues above it.

Torque 3D Owner ITS_Nick
#13
03/18/2011 (11:32 am)
Understandable - but "LOGGED" somehow made me think that someone, sometimes, in future releases is going to look at it and do something.

I want to believe. (c) =)