SimSet::iterator/SimSetIterator
by Ron Yacketta · in Torque Game Engine · 11/03/2002 (7:27 am) · 8 replies
All,
just noticed a tad bit of oddity when looping through the SimSetIterator looking for object types.
I have this little bit of code (just some test junk for now, needs clean up etc)
the output seen in the console is:
when you launch a mission and head into the editor it shows my Interior's as having objectID's from 1356 - 1362.
I am able to match up each objectID returned from the engine with one reported in the editor using the .dump() console method. This bothers me a bit, are their two objectID's for one object? could their be more?
I have also noticed that the last objectID reported from the engine lines up with the first one reported in the GUI. (1373 == 1362)
I am not sure why this is, can anyone lend some insight here?
-Ron
just noticed a tad bit of oddity when looping through the SimSetIterator looking for object types.
I have this little bit of code (just some test junk for now, needs clean up etc)
// for (SimSetIterator itr(conn); *itr; ++itr) {
for(SimSet::iterator itr = conn->begin(); itr != conn->end(); itr++) {
ShapeBase* shape = static_cast<ShapeBase*>(*itr);
if(shape->getType() & InteriorObjectType) {
Con::errorf("*** Found an InteriorObjectType [%d]", shape->getId());
}
}the output seen in the console is:
*** Found an InteriorObjectType [1367] *** Found an InteriorObjectType [1368] *** Found an InteriorObjectType [1369] *** Found an InteriorObjectType [1370] *** Found an InteriorObjectType [1371] *** Found an InteriorObjectType [1372] *** Found an InteriorObjectType [1373]
when you launch a mission and head into the editor it shows my Interior's as having objectID's from 1356 - 1362.
I am able to match up each objectID returned from the engine with one reported in the editor using the .dump() console method. This bothers me a bit, are their two objectID's for one object? could their be more?
I have also noticed that the last objectID reported from the engine lines up with the first one reported in the GUI. (1373 == 1362)
I am not sure why this is, can anyone lend some insight here?
-Ron
#2
the code presented outputs one set of ObjectID's while in the editor their is a different set of ObjectID's
I did a 1373.dump() and a 1362.dump() they are identicle. I also was able to match up each ObjectID reported by the engine to one that is seen in the editor.
This leads me to belive that the objects have more than one ObjectID.
not sure if it is possible to make it any clearer than that ;)
-Ron
11/03/2002 (8:50 am)
I thought it was pretty clear and straight forward *shrug*the code presented outputs one set of ObjectID's while in the editor their is a different set of ObjectID's
I did a 1373.dump() and a 1362.dump() they are identicle. I also was able to match up each ObjectID reported by the engine to one that is seen in the editor.
This leads me to belive that the objects have more than one ObjectID.
not sure if it is possible to make it any clearer than that ;)
-Ron
#4
I could see how a ghosted object could cause this if I were seeing dbl the number of engine reported objects then then their are reported by the editor.
Wonder if the server side keeps it's own objectID's seperate from the client? this cauld definatly explain the difference in objectID's
-Ron
11/03/2002 (9:33 am)
a bit more detail, the number of objects returned by the engine code is 7 and the number of objects shown in the editor is..... 7.I could see how a ghosted object could cause this if I were seeing dbl the number of engine reported objects then then their are reported by the editor.
Wonder if the server side keeps it's own objectID's seperate from the client? this cauld definatly explain the difference in objectID's
-Ron
#5
What I would do is do a check for isServerObject() or isClientObject() (I forget the function names...) and recount to see if perhaps this clears the issue up.
11/03/2002 (10:29 am)
I think how it works is the server manipulates the real objects, with each object recieving a particular id. They are sent to the client as ghosted objects and each of these ghosted objects recieves a particular id.What I would do is do a check for isServerObject() or isClientObject() (I forget the function names...) and recount to see if perhaps this clears the issue up.
#6
as using ShapeBase which there is no relationship ...
an Interior has no inheritance and InteriorInstance (what you see in editor) is SceneObject..
11/04/2002 (4:59 am)
... why does that even resolve to find InteriorObjectType ?as using ShapeBase which there is no relationship ...
an Interior has no inheritance and InteriorInstance (what you see in editor) is SceneObject..
#7
I have yet to dig through the why, but it does work as represented above.
One can even modify the GuiRadarCtrl to display interior objects as well as plyar objects by simply adding in the check for the interior object to both getType() checks.
-Ron
11/04/2002 (6:13 am)
BadGuy,I have yet to dig through the why, but it does work as represented above.
One can even modify the GuiRadarCtrl to display interior objects as well as plyar objects by simply adding in the check for the interior object to both getType() checks.
-Ron
#8
I think this is the answer, I have seen this with the player object, try to put a Con::errorf("Constructor called"); in the Player constructor, in the log you will see 2 of this message, but in the script you have only one call to %player = new Player ...
Davide
11/04/2002 (10:22 am)
Quote:
Wonder if the server side keeps it's own objectID's seperate from the client? this cauld definatly explain the difference in objectID's
I think this is the answer, I have seen this with the player object, try to put a Con::errorf("Constructor called"); in the Player constructor, in the log you will see 2 of this message, but in the script you have only one call to %player = new Player ...
Davide
Torque Owner D Player