Can I add a prexisting component to a gameobject?

Unity Engine
1

Hi,
I’m kinda new to this, but:
gameObject.AddComponent(); // that works

but that doesn’t
var stupidManager = new SomeManager();
gameObject.AddComponent(stupidManager); // won’t work

I guess the basic question behind is: Can I reuse a component and move it between gameobjects? Or maybe even let single component affect several gameobjects?

2

As far as I know, no. Components are tightly integrated with the underlying GameObject they are .AddComponent()ed to and hence cannot just be switched around to somewhere else.

What exactly are you trying to do? There is likely an easy way to organize your project to work without switching Components around like that.

3

I’m trying to get box2d world get updated in a separate thread that would render it’s objects into gameobject it is attached to, i thought i’d just store the component somewhere while it’s particular gameobject is not used and then when i will need it again just reattach it back onto gameobject and let it get back to render where it stopped. I guess i can do that with 1 more step in between.

4

Nope!

You can’t do that. Everything you do that interacts directly with the engine has to happen on the main thread*. If you want to run Box2D on a different thread, you’ll have to run your own Box2D world and use that, ignoring the built-in Physics2D system.

  • Unity’s a two-part engine - there’s the C# user script part, and the C++ engine part. All GameObjects and Components (everything that inherits from UnityEngine.Object) has a representation on both sides of that engine. Those have to be kept in sync, so multi-threading one of those parts would be a major headache.
5

I’m not sure where this “separate thread” fetish comes from but I see it an awful lot, and generally it leads to disastrous choices that cause projects to slip and fail and have instability problems.

First, I have to ask: do you have your game 100% working already? If you do not and you are speculatively moving tasks to other threads now just because you think it might be a future bottleneck, you really are not spending your engineering effort wisely.

Step 1 is “finish the game.”

Step 1a is “optimize but ONLY if necessary.” This most likely will mean “do less,” or “do it differently,” and it will LEAST likely mean “put it in a different thread.” Threads are not powered by the magical feverish dreams of CIS majors (hat tip to Mike Acton!)… code runs on real CPUs.

Step 2 is “ship your game out”

Don’t get bogged down in step 1a if you don’t need to.

6

ohh the game is not done, i did a version few years back in actionsctipt, but got into a real issues with performance for ai and other background things slowing the main thread down. So now I’m trying again to get my game remade. I need few 2d simulations running at the same time and box2d is just fine with running there and letting main thread to simply read the x,y of bodies from it.

I just know that if I don’t take your 1a into consideration at the start then if it becomes necessary later on it will basically make me rewrite the whole thing. I do know the traps of multi-threading and i believe in my case it’s actually ok, as i’m basically doing samething as unity does only on more then single 2d simulation at once.

As for “the main thread” I think it’s been solved here so many times that it’s not really an issue, just need to remember that it’s easy to mess things with threads.

7

Kinda. You can create a new component on the object you want it on and use reflection to copy the fields over to it.

https://answers.unity.com/questions/530178/how-to-get-a-component-from-an-object-and-add-it-t.html