Blueprint Type unable to be updated on Blueprint Class assets if the parent type changes

When a Blueprint Class is created from a C++ Blueprintable parent class the asset is set to a certain Blueprint Type based on the UCLASS specifiers. If you set the const specifier it will set the associated Const Blueprint Type.

But if you refactor the parent class and remove the const specifier only the new Blueprint Class assets created with the parent class will have the updated Normal Type. The old Blueprint assets will continue to function (depending on the refactor) but they’ll follow the Const type rules which means they cannot have an Event graph or set the value of Instanced variables.

The best option at this point seems to be to create new versions of your Blueprint Classes, copy over the Logic and Variables as best you can and then update all the references to the old assets.

Is there a Blueprint Type conversion tool I’m missing since this seems like it could potentially end up being a lot of work if you were deep in development with hundreds of assets created before you realized you had to refactor.

Steps to Reproduce

  1. Add a C++ class to the project
  2. In the UClass definition add const and Blueprintable specifiers
  3. Add at least one blueprint editable UProperty
  4. Add a const UFunction with either the BlueprintNativeEvent specifier
  5. Build and launch the uproject
  6. Create a new Blueprint Class and select the parent Class we created
  7. Open the new Blueprint and override the UFunction, note that the Property cannot be set since it has been created as Const type
  8. Save the project and close
  9. Remove the const specifier from our UClass
  10. Build and launch the uproject
  11. Create a new Blueprint Class and select the parent Class we created
  12. Open the new asset and override the UFunction, try setting the Property which should work in this new class
  13. Mouse over the two Blueprint Classes we’ve created and note that the Blueprint Type on the first one is still Const while the second one is Normal

Result:

While the Const Type Blueprint can still function after the parent class change it is still limited by the Const Type rules and seemingly cannot be updated to Normal type without creating a new Blueprint Class and manually copying over the Logic and Variables.

The included Repro Project contains two Blueprint Classes under the Content/Blueprints folder which were created with the same Blueprint Parent class in the way described above. Running the ExampleLevel will run a Level Blueprint which will call the RunTest C++ function on object instances of those two classes.

Hey there, apologies for the slow response on this one. We don’t have a Blueprint-type conversion tool despite that it would be useful for refactoring purposes. Changing UBlueprint properties or changing an asset’s UBlueprint subclass are fragile actions, since we’re dealing with engine code that may currently only be evaluated when an asset is created.

For your specific scenario though, I did a local test and believe that manipulating the Blueprint->BlueprintType on your existing assets is relatively safe to do. You can expand this into an editor utility function for mass fixup of existing assets:

UCLASS()
class BPASSETTYPE57_API UConstTestFunctionLibrary : public UBlueprintFunctionLibrary
{
	GENERATED_BODY()
	
public:
	UFUNCTION(BlueprintCallable, CallInEditor)
	static void MakeBlueprintNonConst(class UBlueprint* BP);
 
};
 
void UConstTestFunctionLibrary::MakeBlueprintNonConst(UBlueprint* BP)
{
	if (BP && BP->BlueprintType == EBlueprintType::BPTYPE_Const)
	{
		UClass* ParentClass = BP->ParentClass.Get();
		if (ParentClass && (ParentClass->ClassFlags & CLASS_Const) != 0)
		{
			BP->BlueprintType = BPTYPE_Normal;
			UE_LOG(LogTemp, Warning, TEXT("Fixed up BP: %s"), *BP->GetPathName());
		}
	}
}

After calling that function for a blueprint asset that has been saved as Const, but shouldn’t be Const anymore given its parent class, after recompiling it the type will be normal and you can start removing the const property on existing function graphs. That last step can just be done using the BP editor.

So, writing a custom utility would be our recommendation. Hope that helps.