Attaching SpringArm+Camera to an independently moving child actor

TLDR: How to attach a SpringArm+Camera to a ChildActor that moves independently of the parent actor (without using an invisible mesh).

I want to make a missile-building game, in which I have multiple parts, which are combined to make the resulting missile. Each part is an actor, but I want to have a pawn that represents the missile as a whole (as well as serving as a proxy for input commands). For this reason, the Pawn doesn’t have any meshes of it’s own, only child actors + a camera on a spring arm.

The problem, is that I need a way to attach the spring arm to the ‘core’ part, so that when the missile flies off, the camera would follow it. As a bonus, it would also be nice if the location of the pawn would also match the location of the core part.

Currently, I have the following solution, which uses a sphere mesh, that:

  • Has no mass
  • Has no collision
  • Hidden in game
  • Is tied to the core part with physics constraint

This is a viable option, but feels very hacky and likely has some hidden problems. I was wondering if there is a way to achieve a similar effect, without resorting to a “magical ball”.

1 Like

Try:

Apply any transform rules that make sense, ofc.


Note: components have ownership which the above does not alter - the original actor still owns the Springarm. If the Child Actor becomes Destroyed, the Springarm component will persist - this may be desired, ofc.

1 Like

Disclaimer: this is somewhat unrelated to the main ask.

I want to make a missile-building game, in which I have multiple parts, which are combined to make the resulting missile.

Depending on the scope & complexity of what you’re making, there may be a more subtle and elegant way to achieve it. Rather that using Child Actor Components (which are somewhat rigid and unwieldy at times), consider overriding Static Mesh Components - you get a graph, functions, variables and support for inheritance. This is a great solution for truly modular design which is also much lighter on resources since each missile part is just an SMC rather than a full-blown actor.


Micro crash-course on what I mean:

  • a base SMC:

  • we create children of:

  • in order to end up with with:

image

  • you can then build an actor out of those comps - each capable of showing a mesh and running their own (or inheriting) logic:

image

Not sure if feasible here but the above works pretty well in more complex scenarios. This is fully dynamic - components can be added / removed run-time, detached, welded and simulated independently. And, most importantly, no one must suffer Child Actor Components. :melting_face:

Thank for the Attach Component to Component solution - the missing sauce was to reference the root component, rather than the child actor itself.

1 Like

As with regards to your suggestion for using SMCs, I’ve actually made a question about the viability of this approach in general. I think its better to continue this topic there.

I’ve given up on trying to use Child Actors. Adding physics constrains between them proved to be extremely difficult and error-prone. At this point, I’ve actually realized that I’ve been using SMCs in my actors already, I just didn’t know they could have tick/begin play functions of their own.
The only thing I’m curious about is how could one approach making a ‘craft editor’ using SMCs? You can’t spawn them directly, so how would I ‘populate’ my craft pawn with these SMCs in editor mode?
(I understand I can just save parts/positions to a config to spawn a craft later, but I’m curious how to make a ‘drag and drop’ style of editor for initial configuration)

You can spawn them with the Add Component by Class node in the actor’s Construct; exposing instance editable variables works, too. However, since the component cannot assign a mesh asset itself dynamically (no comp Construct in BP), you may need to have the actor who instantiates them do it instead - for that instant visual viewport editor feedback.

There are drawbacks to using SMCs, too - ofc - they cannot own Timelines since components cannot own components. You may need make do with timers and sampling a curve - poor man’s timeline.

This works in blueprints, but if I add a C++ class in a similar way, I can’t add it to the blueprint (it shows only the blueprint classes derived in this way)