FClassFinder works in editor, but always crashes my packaged builds

[vbg_caleb]

I have a working project for this lesson where I include the menu classes by setting them in a Blueprint-derived class (and that works in both editor and packaged version). However, if I try to use the method in the course of setting classes via ConstructorHelpers::FClassFinder, it works in the editor, but the packaged builds always crash (and based on UE_LOGs before and after the call, it crashes when doing the FClassFinder call).

ConstructorHelpers::FClassFinder<UUserWidget> ConnectionMenu(TEXT("/Game/MenuSystem/WBP_InGameMenu"));

The error says: Assertion Failed: Level ==1 [File:D:\build++UE5\Sync\Engine\Source\Runtime\CoreUObjects\Private\Serialization\AsyncLoading2.cpp] [Line:4495]

I’m wondering if maybe the metadata that FClassFinder uses is somehow stripped from packaged builds. Is there perhaps a setting I need to toggle to be able to use that method in a packaged build? Or, maybe the path to use with FClassFinder changes for packaged builds?

Googling for the error, I see this separate thread on gamedev.tv, but it references a different line number and BindWidget is working fine for me (even on packaged builds):
Potential risks with the BindWidget meta tag

[vbg_caleb]

Also, I’m using UE 5.0.1 on Windows.

[beegeedee]

That was going to be my first question - which version are you using. I can’t imagine how this happens but I have seen things that work in debug mode and not in release. I’ll take a look.

[beegeedee]

Follow-up. I had a couple of issues packaging (unrelated) but when I resolved them it is working just fine. I’m not seeing the issue you’re describing. Have you checked your code against the lecture code? Try cloning this code - it should work fine with UE5 and try packaging that and see if it works.

Let me know how you get on.

[vbg_caleb]

I found this link where people were having essentially the same issue as me with just the standard ThirdPerson template in Unreal 5 (i.e. FClassFinder causing crashes in packaged executables):

UE5 C ++ Packaged Projects Not Playable

I’m going to circle back to this after I finish going through the course since I can just set my widget references via the Blueprint version, and this seems like the kind of thing I might end up wasting a few days on…

[beegeedee]

Well, that may explain a few things. I took the UE4 project and upgraded it to UE5 without issue. There have been reports of a number of issues with UE5 but it is brand new so we have to expect these teething problems.

[vbg_caleb]

Now, I’m getting a new issue that only happens in packaged builds after I started into the OnlineSubsystem sections (even if I remove anything calling the OnlineSubsystem code)… It was failing right at startup, so I used the registry keys to get Visual Studio debugger to attach right away via vsjitdebugger.exe.
(see windows - Can't use vsjitdebugger anymore to debug processes at startup - Stack Overflow)

I’m getting a read access violation at ScriptDelegates.h, line 324, inside TMulticastScriptDelegate::Add(somewhere in CompactInvocationList), where it’s just trying to do something internally while processing this in my code during Initialization:

ButtonHost->OnClicked.AddDynamic(this, &UMainMenu::HandleButtonHostClicked);

and I can see in debugger that ButtonHost is pointing to the button widget.

Here’s where the error is. It’s trying to dereference rcx register which has 578 as the value, but I can’t see where rcx value is coming from. And, who knows how well PDB symbols are actually lining with assembly code, but seems reasonable giving that my code was just trying to wire up a click event.

So, at this point, I’m thinking I need to either wait for 5.0.2, downgrade to 4.27 for this course, or maybe try to compile Unreal from source and see if I can figure out what’s going on… but I really just wanted to get to the part where I could test out Steam… oh well. So close, yet so far.

[beegeedee]

You could create a project in UE4, upgrade to 5 and then migrate the assets from your existing project. This might solve the issues.

[vbg_caleb]

I created an UE4 Third Person project and converted it to UE5. I confirmed that I could run the base project as a packaged project.

Then I did the following:

• Copied all of my C++ classes from my original project over.
• Closed editor and recompiled VS project.
• Reopened editor.
• Confirmed I could still run the base project as a packaged project.
• Migrated just my menu blueprints and my main menu level (and accompanying images and fonts) from my original project.
• Pretty sure I clicked “Save All”.
• I tried to run that in editor, and this time it crashed Unreal when doing AddDynamic on the menu button (inside editor this time).
• I reopened Unreal editor, and my imported menus/fonts/images were missing… I redid the migration, and now it’s telling me I can’t open WBP_MainMenu because the base class is missing (I can see that’s still there though).
  • Is there a way to reparent a Blueprint class without being able to open the Blueprint, so I can try to reassociate it?

[vbg_caleb]

Found a bunch of messages from Unreal 4 days where people wanted to reparent Blueprint classes where parent class couldn’t be found. It didn’t seem like there was a solution except to use an ini file config option to redirect classes (which wouldn’t help me since base class is still the same and at same relative path as it was before).

I’m just going to rebuild my Blueprint menus from scratch.

Other UE5 quirk I’ve run into:

• Live Coding builds don’t seem to persist between runs of Unreal Editor.
  • i.e. If I change C++ class, go to Unreal Editor, then:
    • live code rebuild
    • make changes to Blueprint based on that (such as reference a Blueprint callable function or parent class)
    • Things will work at this point.
    • Close editor, and re-open editor.
    • Things are broken here. Unreal is using some old version of the code until I do Live Code rebuild again. (things such as calls to Blueprint callable methods are broken and have to be re-done, etc).
    • Packaging seems to have same issues. The packaged code is not using the latest Live Coding rebuild.

Workaround: Always do rebuild of C++ project in Visual Studio before opening the Unreal project. And, if wanting a packaged build, always close editor then build in Visual Studio then reopen editor and package.

I’m coming from Unity and am relatively new to Unreal, so not sure if above quirk is expected or not (certainly not desirable…).

[beegeedee]

You shouldn’t have to do this. UE5 looks great but it’s new and buggy. Never had these issues with 4.27 although there are some quirks you need to know about.

Unity has a faster build process I admit. I’ve been retaking the 3d course and coding is so much faster, but it just isn’t as elegant an environment. Plus, UE just looks better and blueprint, while also like prefabs, can save so much time and are plenty fast.

[vbg_caleb]

Ok… I’m pretty much back to where I can follow along again now. I got some extra practice in on making UI widgets and doing a little debugging of Unreal project with Visual Studio, so, all-in-all, probably a worthwhile detour for me. Every now and then, one must bash one’s head against a wall until the wall crumbles (or one realizes that one should just walk around it this one time). I ended up just wiring up my button click handlers in Blueprint and having them call a BlueprintCallable function on the C++ side.

It seemed like Unreal on my computer didn’t like reflection-type stuff in the packaged builds (FClassFinder and AddDynamic on the buttons in particular), but like you said, I’m sure they’ll sort it out eventually. Overall, I’m pretty impressed with UE5.

[beegeedee]

I have to say, I would generally implement menus using Blueprint anyway. They are not computationally expensive. It just makes it easier to manage. That’s not to say you can’t have BlueprintCallable functions for handling the more intensive stuff. So, yeah, this is a good solution.