Bug or Feature? Copy works after methods fire...
by Gina-Marie -Netjera- Hammer · in Torque Game Builder · 06/29/2006 (4:24 pm) · 2 replies
I've noticed something regarding the copy command, and I wonder if it's supposed to work this way or if it's a bug.
If you try to create a new item by making a copy of an old one, it gives you an error message telling you that the item isn't in the scene. However, if you make an empty object, and then copy the old object into the new empty one, all of the attributes are transferred over and everything is seemingly fine.
Here's where the problem occurs. NO ON-CREATION METHODS ARE FIRING. Because you have to create the empty object to copy into, before the copy command can be generated, all methods that are hung on an object at object creation have null values. Therefore, methods that I write myself will fire, but any that are created when the object is made, do not. (onLevelLoaded(); onWorldLimit();) No callbacks work.
Is this supposed to work this way?
EDIT: I forgot to mention that ONE callback ALWAYS works, and that's how I figured this out. onCollision(). It always works because it tries to fire AFTER the copying of values has taken place.
If you try to create a new item by making a copy of an old one, it gives you an error message telling you that the item isn't in the scene. However, if you make an empty object, and then copy the old object into the new empty one, all of the attributes are transferred over and everything is seemingly fine.
Here's where the problem occurs. NO ON-CREATION METHODS ARE FIRING. Because you have to create the empty object to copy into, before the copy command can be generated, all methods that are hung on an object at object creation have null values. Therefore, methods that I write myself will fire, but any that are created when the object is made, do not. (onLevelLoaded(); onWorldLimit();) No callbacks work.
Is this supposed to work this way?
EDIT: I forgot to mention that ONE callback ALWAYS works, and that's how I figured this out. onCollision(). It always works because it tries to fire AFTER the copying of values has taken place.
About the author
Art, Games, Life www.netjera.com See my in-progress website and game design work at: www.netjersoft.com!
#2
(A friend had helped me with the code, and I hadn't realized it but he'd set "CollisionCallback = 1;". That's what made me think to look and see if there was a way to turn World Limit Callback on. ) So, apparently, there's a work-around for certain functions. I can't seem to find one for the initial loading functions, though.
Also - and this may be unreleated - I'm not specifically activating physics anywhere, but when my objects hit the world limit they "stack", instead of ignoring one another. I don't know if this has something to do with the copy function as well, or if it's unrelated.
Thanks for the compliment. I'll try to keep you posted if I figure out anything else.
06/30/2006 (8:21 am)
I created a GemObj::onGemCreate() function and that works fine. I also noticed that if I go into my GemObj declaration (it's made as a t2dStaticSprite) that if I declare "WorldLimitCallback = 1;" I can get the world limit to fire now. But still no way to get onLevelLoaded() or onAdd() to work. :(.(A friend had helped me with the code, and I hadn't realized it but he'd set "CollisionCallback = 1;". That's what made me think to look and see if there was a way to turn World Limit Callback on. ) So, apparently, there's a work-around for certain functions. I can't seem to find one for the initial loading functions, though.
Also - and this may be unreleated - I'm not specifically activating physics anywhere, but when my objects hit the world limit they "stack", instead of ignoring one another. I don't know if this has something to do with the copy function as well, or if it's unrelated.
Thanks for the compliment. I'll try to keep you posted if I figure out anything else.
Torque 3D Owner Stephen Zepp
Yes, it's by design to work this way, but then again, it's necessarily a "use friendly" design. I myself when I first saw the command assumed that it would create an entire new object for me and return the handle, but it does not currently operate that way.
I'll pass this along to the team and see what they think--for now, you may want to abstract out what you may be doing in the ::onAdd() to a different function, and that way you can call it after the copy is done.