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:
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”.
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.
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.
you can then build an actor out of those comps - each capable of showing a mesh and running their own (or inheriting) logic:
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.
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)
