Why does my TArray> get cleared on project open?

I have declared a blueprintable class of configuration data:

UCLASS(Blueprintable, Category=CharacterSheet, EditInlineNew)
class SCAPES_API UStatDefinition : public UObject

I have an actor component that makes use of this class:

UCLASS(Blueprintable, ClassGroup=(CharacterSheet), meta=(BlueprintSpawnableComponent))
class SCAPES_API UCharacterSheet : public UActorComponent, public ISymbolValue
	UPROPERTY(EditAnywhere, Category = "Stats and Skills|Configuration", NoClear)
		TArray<TSubclassOf<UStatDefinition>> StatDefinitions;

In the editor this works fine. I can create an instance of my CharacterSheet component on my Character blueprint. I can create blueprint subclasses of the native C++ UStatDefinition class…
I can also press the “+” button in the editor, create items in the TArray<>, and drag/choose the created blueprintable classes in the popup menu.
So far, so good!

When I compile/save this blueprint, and build/save/save all the level, quit the editor, re-open the editor, and re-open this blueprint, the array is back to size 0, and the configured class items are no longer there.

What am I doing wrong; why is the array empty after closing/re-opening the editor?

code looks fine,
the NoClear should have actually no effect on what you want to achieve

NoClear - Prevents this Object reference from being set to none from the editor. Hides clear (and browse) button in the editor.

Try recreating the Blueprint, sometimes blueprints can get corrupted.
other idea would be to remove the NoClear might do weird things on non Object references

It’s true that NoClear doesn’t actually remove the “None” option and the “X” option from the entry, so I agree it’s not doing what I want :slight_smile:
I’ll try re-creating the blueprint, even though it’s a pain to do that, as it has tons of logic in it for animation and movement.

Yeah, it seemed to be that the blueprint marshaling had somehow gotten “stuck.”
I didn’t need to re-build the full blueprint, just give the component a new name and re-configure it, and then change all blueprints that access that component to call a function to get it – that way, if I need to change the component name again, nothing external will break.
(I imagine this would be a best practice anyway, but calling “get X component” from an actor is … expedient at the time.)

I hate to blame the tools, but in this case, the problem really was that the blueprint marshaling had gotten stuck, as I had kept re-using the same component name across versions.
Removing the component, adding a new instance of the component with a different name, and configuring that, seems to work, and properly keep the configuration after quitting/re-starting the editor.
Note that I had removed the component before to try to debug this, but then added it back with the same name :-/

Thanks @Lardo Deepdelver for pushing me to actually try a different name (which I should have known to do already!)