UPROPERTY values within Component lost after new c++ compilation

Hi,

I can set references of other components in the editor as values of components, but when I modify the C++ code this changes get lost.

For instance:

class MY_API USwitchComponent : public UActorComponent
{
	GENERATED_BODY()
public:

	UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = SwitchComponent)
	USwitchableComponent* SwitchableComponent;
...
}


UCLASS(ClassGroup = (Custom), meta = (BlueprintSpawnableComponent))
class MY_API USwitchableComponent : public UActorComponent
{
	GENERATED_BODY()	
public:

	UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = Disturber)
	TArray<USwitchComponent*> SwitchComponents;
}

I guess that the editor checks that there’s a new version of the component or actor, replaces them with the new version and tries to sets the values of the old version with the new version. Only happens when I change either the component itself or the actor that owns that component. It might fail since it’s a component referencing another component, but it works until I modify code of the owner actor or the components.

How can I solve this? Is there a walkaround? Does anybody know the exact piece of code where the editor does this?

Thanks,
FL

Are you using hot reload?
Hot reload discards old DLLs and generate then link to new ones.

Hey there, that might be a known bug that you have in 4.18. If you have a variable defined in c++ and you set it’s value in blueprints on a child class, when you hot reload it reverts back to the original value from c++, which is usually empty. Hopefully that will be fixed in 4.19. Right now the only workaround is to restart the engine after making a change in the c++ header.

It might be related, but I don’t use blueprints, it’s pure C++, Actors and Components.

Thanks it’s the hotreload.

The funny thing is that the actors and components were pure C++, no blueprints involved.

Yes, you were right it’s the Hot Reload! Thanks!!

Hopefully epic will fix this in 4.19 :slight_smile:

Doesn’t seem fixed in 4.19

Oh boy, this still isnt fixed? Wtf. Now in 4.26. This problem exists since… waaaay back.