Project Loading Hangs with FObjectFinder

Development Programming & Scripting Blueprint
, , , , , ,
1

Apologies if this has been asked before, but most of the questions I found about FObjectFinder were using it outside a class constructor.

I have a C++ class with a Blueprint class asset extended from it. I call FObjectFinder to get the Blueprint class from the C++ class constructor. My project compiles & runs, everything appears fine. However, when I close the project and try to reopen it, the Editor gets stuck at 70%. There’s nothing wrong in the log file, it just hangs and I have to kill it from Task Manager. If I comment out FObjectFinder and recompile my code in Visual Studio, the project will load correctly so it’s definitely those lines. I’ve found one post about this on the Unreal forums, but the only suggested fix was to do this edit every time you load the project. Is there anything else I can try?

Some example code, both approaches result in the same error. In both cases, MyClassBlueprint is declared as a TSubclassOf < class ACustomClass > variable in the class’s header file.

ACustomClass::ACustomClass()
{
    static ConstructorHelpers::FObjectFinder<UBlueprint> MyBlueprint(TEXT("Blueprint'/Game/BP_CustomClass.BP_CustomClass'"));
    if (MyBlueprint.Object != NULL)
    {
        MyClassBlueprint = (UClass*)MyBlueprint.Object->GeneratedClass;
    }
}

ACustomClass::ACustomClass()
{
    static ConstructorHelpers::FObjectFinder<UClass> MyBlueprint(TEXT("Class'/Game/BP_CustomClass.BP_CustomClass_C'"));
    if (MyBlueprint.Object != NULL)
    {
        MyClassBlueprint = MyBlueprint.Object;
    }
}

,

2

I cross-posted this in the Bug Reports section; copying Doug Wilson’s answer from there in case anyone else finds this.

Hey Leidyr-

If I understand correctly, your blueprint is a child of the class where you’re using FObjectFinder? Assuming this is the case, it appears you are running into a circular reference when the the blueprint’s constructor attempts to get a reference to the blueprint itself. The blueprint itself already has the functionality from the class it’s based on, so getting a specific reference to it should not be necessary. Depending on what you are trying to do with the blueprint reference you should be able to add a function to the class that the blueprint can call when necessary.

Cheers

Doug Wilson

And a little bit more information from me: I’d followed some older example code for setting up a C++ class with a child Blueprint that included the FObjectFinder code. However, I’ve confirmed that my class automatically has access to the child Blueprint’s variable settings (I declare a variable in the C++ class and actually set its value in the Blueprint configuration) so I don’t need that call at all.