Currently, for any blueprint subclass of Actor, you are forced to have a default scene component as the root component of said class if you do not create any components. Creating further subclasses of said subclass forces you to use the same scene component as the root with no straightforward, easy, UI-compatible or honestly even safe route to change that.
There are a quite a few situations where I would’ve preferred to not go the long way around, for example:
- Vast amounts of shared logic for potentially physics-enabled static or skeletal meshes, where the root component should be the mesh component.
- Shared logic for actors with different root collision shapes.
Right now, the go-to way to solve this is, rather than using inheritance, is to create a component that uses bloated logic to figure out what is actually going on in the parent actor using getters implemented in those actors to keep code duplication to a bare minimum. This is extremely inconvenient, when in code, the most logical way to implement this would be an abstract base class defining the logic.
The two ways forward I see to ease the life of developers without demanding less than optimal code cleanliness from blueprint developers is to either:
- Allow the creation of abstract Actor subclasses with zero components. The first actor in the inheritance tree that needs a default scene root should be the first one to not be marked abstract. This allows for continuing to explicitly prevent the replacement of components in subclasses. We already have an abstract flag for classes under advanced class settings - why is this not as simple as preventing the creation of the default scene root if said checkbox is ticked?
- Or allow the replacement of the DefaultSceneRoot component in subclasses with any component of the developer’s choice. I recognize this may be difficult as it creates an exception for the explicit prevention of replacing superclass components, which is why I’d see the abstract route as the way to go forward.
Alternatively, a potential solution I could see to alleviate some of the issues with inheritance is to allow for abstract components (UShapeComponent, UMeshComponent, etc.) to be root components of abstract Actor subclasses. Such classes would be implicitly marked as abstract in the inheritance chain until a subclass replaces the root component with a derived, non-abstract component. Again, this would create an exception where the root component of the class could be replaced, but with less of an issue, as the replacing component is a derived class of the original component, thus the logic cannot break anywhere.
As a final footnote, I’d like to reiterate how much this issue creates an environment where blueprint code either bloats, or creates insane amounts of code duplication. Pseudo-multiple inheritance or class composition through non-scene components does not adequately address this issue, it’s merely swept under the rug.
1 post - 1 participant