Editing properties of subcomponents does nothing

I’ve got a USceneComponent subclass that attaches another USceneComponent subclass in its constructor. The child component has a bunch of properties, all of which are defined with UPROPERTY(EditAnywhere, BlueprintReadWrite).

When I attach the parent component to a Blueprint Actor, I can modify the properties of the child component without an issue. When I look at the properties on a placed instance, the values are carried over from the Blueprint.

When I run the game, none of the changes I have made to the child’s properties have taken effect. All values are whatever I set back in the C++ base class.

  • Engine version: 4.7.6
  • Platform: Windows 8.1 x64

Did you try right clicking on the object in the World Outliner (typically top right) can “Keep Simulation Changes”?

Components are instanced when created in actors, their values are then unique to that instance (and there can be many copies - instances - with many different values).

Sorry - I think I misread - your blueprint values are not turning up in game?

I’m aware of this setting and the distinction between instance properties and their blueprint counterparts.

Your comment is accurate - it doesn’t matter whether I change the properties on the instance, the blueprint, or both. Neither has any effect when I run the game.

Hey -

I created two scene component classes (ParentSceneComponent and ChildSceneComponent). In the ParentSceneComponent class I added a pointer to a ChildSceneComponent variable. In the ChildSceneComponent class I added a number of variables (floats, bools, int32). After compiling I created a blueprint based on Actor and added the ParentSceneComponent to it. With the following blueprint setup I was able to make changes to the default values of the variables inside the ChildSceneComponent and have them reflected in game. Let me know if this helps you access the properties of your component inside the blueprint.

Cheers

Hi ,

My hierarchy is nested one level deeper than that - My AActor subclass sets its RootComponent to a regular USceneComponent, then attaches ParentSceneComponent to that, which in turn attaches ChildSceneComponent to itself.

MyActor
    |-- USceneComponent
            |-- ParentComponent
                    |-- ChildComponent

This might seem like an unnecessary amount of nesting, but for my project it definitely makes sense to have things organised this way.

I’ve attached a sample project that demonstrates this bug, as well as the hot-reload bug described in this question.

Hey -

Something I hadn’t considered, is the ChildComponent of the ParentComponent? If so you shouldn’t need to add both to the blueprint, the child will have all of the information in the parent as well as what is unique to the child. If there is not a parent/child relationship between the components (ex. two classes that are both scene components with one having a pointer variable to the other) then the above method would still work, you simply need to cast from one level down to the next. The return of the first cast (as parent) should have the pointer variable of the other that you use as the object of the next cast.

Hi ,

ChildComponent is not a subclass of ParentComponent. It has a completely different purpose and wouldn’t make sense as such.

Did you take a look at the sample project I attached?

Hey -

As mentioned in your other post I was able to reproduce this with the assets currently in the project however using a new actor I was able to change the default of the variable inside TestComponentB. I would use the method of adding each component to the Actor class itself rather than to each other and then use AttachTo() to create the hierarchy in the blueprint.

Cheers

Hi ,

Although your workaround does fix the issue, it removes the ability to define generic subtrees that can be arbitrarily attached into Actor hierarchies, which is something that vastly simplifies my design. Without it, I either have to define a new Actor subclass for every permutation of components (impractical); introduce constructor parameters to instruct the base class on which subcomponents to instantiate (messy), or have components operate on pointers to “subcomponents” that designers have to add manually and remember to hook up in the construction script of every Blueprint (error-prone).

Are “true” subcomponents (i.e. components owned/attached by components) something that will be supported at any time in the future, or should I just forget it and choose the least worst option above? It seems like the support is 99% there apart from these few small (but game-breaking) bugs.

As I mentioned in your other post (Subcomponents don't appear in Blueprint hierarchy - Blueprint - Epic Developer Community Forums) I’ve submitted a bug about the components not appearing in the hierarchy (UE-15271). As these issues all seem to stem from the same root I’ve included information for the different issues you’re experiencing with the original issue.

No worries , thanks for your help.