Cloned object has no namespace: onRemoveFromScene
by Saiko · in Torque Game Builder · 11/05/2007 (12:09 pm) · 8 replies
Hi there,
I've been using clone(true) in TGB 1.5.1 recently in a project and the following warning keeps popping up in the console log.
Con::execute - 0 has no namespace: onRemoveFromScene
I basically have a projectile with a class (script based) of ExplodingProjectile. When my player shoots I use clone(true) to clone a new copy of the original projectile in order to maintain its class functionality. The clone call here throws the warning. I've tried pretty much everything I can think of except building the class into the engine itself.
So, I was wondering if there is any way to stop this happening. It's not a major issue as all the code works as expected but you know the warning is just a bit annoying and I prefer things to work correctly.
Any suggestions?
I've been using clone(true) in TGB 1.5.1 recently in a project and the following warning keeps popping up in the console log.
Con::execute - 0 has no namespace: onRemoveFromScene
I basically have a projectile with a class (script based) of ExplodingProjectile. When my player shoots I use clone(true) to clone a new copy of the original projectile in order to maintain its class functionality. The clone call here throws the warning. I've tried pretty much everything I can think of except building the class into the engine itself.
So, I was wondering if there is any way to stop this happening. It's not a major issue as all the code works as expected but you know the warning is just a bit annoying and I prefer things to work correctly.
Any suggestions?
About the author
#2
I think my issue might be more to to with the clone function and they way it sequences the copying. Everything works as expected apart from the warning and a diff between the object dumps (original : clone) are the same.
The 0 has no namespace thing is what really bugs me as I would expect a proper id instead of the 0. Its probably just something I've missed though it still bugs me. If I get any further with this issue I'll let you guys know.
11/09/2007 (2:40 am)
Thanks Chaim, I had a good look through the docs and it didn't really solve the issue for me. One thing I did learn though it that the namespace is script is not a true namespace. I think my issue might be more to to with the clone function and they way it sequences the copying. Everything works as expected apart from the warning and a diff between the object dumps (original : clone) are the same.
The 0 has no namespace thing is what really bugs me as I would expect a proper id instead of the 0. Its probably just something I've missed though it still bugs me. If I get any further with this issue I'll let you guys know.
#3
cloneWithBehaviors does not copy the class to the new object so I had to move that code to be implemented as a behavior. This was acceptable to me because the work done in the class was very small.
11/14/2007 (1:10 pm)
I do not know the underlying issue, but I had the same warning and replaced clone with cloneWithBehaviors to get rid of it. cloneWithBehaviors does not copy the class to the new object so I had to move that code to be implemented as a behavior. This was acceptable to me because the work done in the class was very small.
#4
PS, you shouldn't clone your bullets when the player fires. Rather, clone 50 bullets when the level loads, and store them in a simset. Then use the simset calls to get bullets as you need them, and set them inactive when you don't. This will greatly improve the performance of your game.
11/18/2007 (5:26 pm)
I've found that despite the warning, clone seems to work fine.PS, you shouldn't clone your bullets when the player fires. Rather, clone 50 bullets when the level loads, and store them in a simset. Then use the simset calls to get bullets as you need them, and set them inactive when you don't. This will greatly improve the performance of your game.
#5
I spent a little time on the problem tonight and ended up doing it 100% in behaviours as Tom did with his issue. I had a few issues with the callbacks I needed but with a little head scratching they were solved.
@Conor - I agree a sim set is a good way to go for that. Currently, my little project is just a prototype but it would be good to optimise where I can early on. I'll have a look into going the sim set route as I can see the overhead with constant cloning. Would be useful for explosions and anything that spawns. I'll put a sim set based fire behaviour on my todo list over xmas. Should be an interesting exercise.
Any way, thanks again guys and have a good xmas.
12/21/2007 (6:31 pm)
Thanks for the responses guys. Sorry its taken me a while to get back on this one. Been swamped @ work with pre xmas rush jobs. Got some time to slack now though and play around with TGB some more. I spent a little time on the problem tonight and ended up doing it 100% in behaviours as Tom did with his issue. I had a few issues with the callbacks I needed but with a little head scratching they were solved.
@Conor - I agree a sim set is a good way to go for that. Currently, my little project is just a prototype but it would be good to optimise where I can early on. I'll have a look into going the sim set route as I can see the overhead with constant cloning. Would be useful for explosions and anything that spawns. I'll put a sim set based fire behaviour on my todo list over xmas. Should be an interesting exercise.
Any way, thanks again guys and have a good xmas.
#6
10/11/2008 (8:22 pm)
I'm going to bump this thread because I've been experiencing this error for a while and it's just annoying because it spams the console to death. Has anyone seen a resolution to this problem?
#7
While the underlying cause has not been fully corrected as of the latest version of TGB, there is now a preference in TGB 1.7.3 that allows you to remove the console spam:
$pref::T2D::warnSceneOccupancy = false;
This -should- remove the console spam, but you should be aware that it will also silence any valid warnings about scene occupancy should they occur (rare, but can happen).
10/12/2008 (10:00 am)
This is an incorrect report from the console due to the technique used when an object is created with clone/cloneWithBehaviors.While the underlying cause has not been fully corrected as of the latest version of TGB, there is now a preference in TGB 1.7.3 that allows you to remove the console spam:
$pref::T2D::warnSceneOccupancy = false;
This -should- remove the console spam, but you should be aware that it will also silence any valid warnings about scene occupancy should they occur (rare, but can happen).
#8
Con::execute - 0 has no namespace: onRemoveFromScene
Con::execute - 0 has no namespace: onCollision
I'm using TGB 1.7.4
I was just wondering if a solution had been reached. I think I may write my own clone that uses copy but that's just a thought I had now and haven't explored that possibility.
10/12/2008 (11:17 pm)
I modified that preference in defaultPrefs.cs and the error still spams the console whenever clone is called. Connor O Kane has instructed me to do all my clones at the start up of the game to get better performance and dodge this issue, but all that did was delay the start of my game while the console is spammed. Now the way my script is set up I'm getting two errors per clone:Con::execute - 0 has no namespace: onRemoveFromScene
Con::execute - 0 has no namespace: onCollision
I'm using TGB 1.7.4
I was just wondering if a solution had been reached. I think I may write my own clone that uses copy but that's just a thought I had now and haven't explored that possibility.
Chaim Krause
Chaim Gang
Understand that if you want to maintain class functionality you can/should use Datablocks.