Initialized components are null during gameplay

I am having a troubling issue with null components during runtime. I have declared 3 FMOD Audio Components exactly the same way, and initialized them exactly the same way, however at runtime the only valid component is the ItemAudioComp.

Is there some kind of limitation in FMOD that stops me from creating multiple audio components on the same actor? Is this an engine limitation? I’ve never run into anything like this before.

.h:

	UPROPERTY(BlueprintReadWrite, EditAnywhere)
		UFMODAudioComponent* DialogueAudioComp;

	UPROPERTY(BlueprintReadWrite, EditAnywhere)
		UFMODAudioComponent* ItemAudioComp;

	UPROPERTY(BlueprintReadWrite, EditAnywhere)
		UFMODAudioComponent* BarkComponent;

.cpp:

 BarkComponent = CreateDefaultSubobject<UFMODAudioComponent>(TEXT("BarkAudioComp"));
    	BarkComponent->SetupAttachment(RootComponent);
    
    	DialogueAudioComp = CreateDefaultSubobject<UFMODAudioComponent>(TEXT("DialogueAudioComp"));
    	DialogueAudioComp->SetupAttachment(RootComponent);
    
    	ItemAudioComp = CreateDefaultSubobject<UFMODAudioComponent>(TEXT("ItemAudioComp"));
    	ItemAudioComp->SetupAttachment(RootComponent);

EDIT: In an attempt to determine whether the issue was a limitation of the number of components I removed the ItemAudioComponent. Instead of seeing one of the others I see none.

Another test: The other two components (null ones) were used elsewhere in CPP (not destroyed anywhere) So I added a simple call to play on BeginPlay for the ItemAudioComponent and it was still valid within the editor.

So it turns out to be some kinda Blueprint error. I recreated the base BP for all of my characters and the components are initialized and accessible.

So, solution is to just recreate the blueprints… Which is an absolute pain in the ■■■. I have heard of something like this happening before, some kind of BP metadata not updating to match CPP base classes when changed. I wish the team at Epic would address this, the only fix requires hours of busy work resetting hundreds of fields in duplicate blueprints.

1 Like

I know this is an old post, but this is the first result in Google. For anybody experiencing this issue, I fixed this by renaming my component’s variable in C++ then rebuilding the project. That component will be reset to default values, so you’ll need to set any variables that the Blueprint was originally overriding, but the rest of the Blueprint will stay intact.

7 Likes

I can confirm I had the exact same issue, and this fixed it for me too! you’re a life safe saviour.

Working with C++ and Blueprint together as a hybrid approach has some real advantages but it really does lead to these kind of bizarre, and practically impossible to debug, issues. You wonder what you’ve done wrong, only to find it’s an engine problem.

Thanks for the solution!