How to switch component's parent from ActorA to ActorB?

Hello, I am trying to switch a Audio-Component’s parent Actor from ActorA (current) to ActorB (target). I have tried many things by using “AttachComponentToComponent”, “AttachActorToComponent”, tryed using “Detach” before attaching and also without detaching, and so on, without success…

I wil provide some screenshots, but I would like to know:

  • Why does the Component not attach to the new Actor’s Root-Component?
  • Is that even possible?
  • Is there something special I need to consider when switching the component’s Actor?

Some more detailed informations:

  • I create ActorB on runtime and try to attach the Audio-Component later on to that actor
  • ActorB is currently a premade Actor with a Scene-Component as Root-Component
  • ActorA gets destroyed after switching the parent of the Audio-Component, but I also tried it without destroying the Actor
  • The Audio-Component is “playing sound” at the time I try to attach it to another component/actor

Here some screenshots:

  • ActorA logic:

Hi There,

So in the very base when you attach a component to a component or actor. It does change its transform

Ex: Your Component starts following B rather than A

However this doesn’t really change the ownership of the component. Ownership and registration is done at the ActorA level. You can check this for their lifecycles overal.

So when you destroy A that owns the component, its garbage collected with the component that is just following the B.

Solution and Some insights.

There are many ways to do what you want to do and you can encounter the solutions in the forums a lot. Depending on what you try to do it can change. Since you are giving an example with audio. I feel that there is a something playing that needs to follow another actor.

  • You can create a new component and write some logic to correctly destroy one and start playing at the same location of audio in the new.
  • You can detach, try change its ownership in C++ (Outer).
  • Or as common practice you can threat your audiocomponent (or any other thing) as a NewActor.

When you have a new actor in the world, whatever component or functionality it holds its parent and registrar is always the actor. Simply you can have AudioActorDynamic which has an audio component that you can attach A or B or anything and it has its own lifecycle,logic.

You can do things like, OnAttached do something. If OnOwnerDestroyed() free yourself or fallback to last actor attached etc.

Let us know if its helpfull.

1 Like

Switch component from actor a to actor b after 2 seconds

Make sure that the reference to the new parent actor is valid.
I used get actor of class but would suggest exposing the reference and setting it from a manager if this is a game mechanic.

That’s interesting.

So in fact, when I attach the component to another component (even if it is the component of ActorB), this wouldn’t show up in the Details-Panel (click on the ActorB and look into its Component-View) at runtime? Because, by what you say, the component would just follow the ActorB’s location instead of changing ownership…

This explains why it seems like it doesn’t work when I checked if it worked… that’s sad. As a dev, I really would profit from such a functionality where components can change “ownership”.

But so far, this might be the answer I was serching for. Thank you.

My pleasure,

Yes can be nice to have that however its already doable but not in bp level.

It is good to think and make a seperation “what lives in the world” vs “what lives in actor”
Everything you see in the game is fundamentally an actor, even characters are just type of actor that has some other functionality. Think actors are like wrappers (some engines call it entity), it’s the most simple unit of representation.

When you are representing a gameplay aspect lets say a baseball, in very base we should handle them actual entities of representation. That’s why actually components are not standalone but a part of actor.

Some components can have only logic, that doesn’t reallly exist in the world.
Some of them can have like audio of vfx.
Some of them can create components in its owner, which unlocks dev to do many reusable code and gameplay features.

Thus when you throw a ball, you want to throw the encapsulated entity which is the ActorBall consists of StaticMesh, Audio, VFX, Movement. Even unreal has a ready go base class for it called projectile which is an Actor also :slight_smile:

We try neglect detaching all audio,vfx etc from the Character attaching to a moving projectile all those aspects. It’s costly, inefficient and opens room for bugs and human error.

These things can be required sometimes in poolling for the sake of easthetics or in vehicles most of the time but not always. Generally on the things that needs transferring. Even that so if you build your architecture in the first place and what needs to be encapsulated would unlock a lot of things.

Ball In Hand (Can be Actor or just a SM that we can threat like Weapon)
Ball flying (Is Projectile which is a moving actor with sound vfx logic)
Ball Impact (Is another actor which contains, decal, sound etc)

if you really need to change component owner not sure but this rename and register should do it.
AudioComponent->Rename(nullptr, NewActorB);

1 Like