Live Compiling in Unreal Projects

Compiling with the Editor Open

Updated over 3 years ago

As great as Hot Reload can be, it does not come without setbacks. While it can be sufficient for projects that do not utilize any custom c++ code nor c++ functionality at a blueprint level, the reality of most projects likely contains a fair share of c++ and blueprint content, where, more often than not, blueprints and in-editor assets serve as an extension of the classes and features developed in code.

Before we continue, let's state once again that for projects with no In-Editor assets referencing project-code (say Blueprints, DataTables, DataAssets, etc), Hot Reloading is mostly without drawbacks. Furthermore, following the rules of Hot reload does exempt most issues and corruption. Check Healthy Hot Reloading below.

How do I know if I'm Hot Reloading?

Summarized, Hot Reload is usually referred to as:

  • Compiling from the IDE with Editor Open. This counts with ANY Editor from any project!

  • Creating c++ classes inside the Editor with the "Automatically compile newly added c++ classes" option enabled in Editor Settings -> General -> Hot Reload.

  • Compiling via the Compile Button on the toolbar when Live coding is not enabled.

A tad of Info

Let's touch base on how the Engine loads and handles assets. On Editor Startup, classes and assets load with the CDO (Class Default Objects) settings. Generally summarized, these are the following:

  • Class, Member, and Function Declarations

  • Constructors, Destructors, and instruction sets.

Please note that any changes to the two above must ALWAYS be compiled from the IDE with the editor closed for any project with In-editor assets referencing project-code classes.

Healthy Hot Reloading / Live Compiling

With the above mentioned, here's go over the cases in which Hot Reload does work, and that is with any changes that do not modify any content wrapped by UMacros and their CDOs.

In this wiki article, we suggest using Live Coding over Hot Reloading as Live Coding acts as a protective barrier against potential Hot Reloading Corruption. Both of these systems face the same limitations for updating CDO-related generated code.

Why does corruption occur?

Since Assets cannot be fully reloaded with the Editor Open, asset masks are temporarily created. This is where things can break. If you Hot reload an asset, then save it, the asset directory, credentials, and content will be changed with Hot-reloaded content.

Limitations of Hot Reload

If you make changes to UE4 Macros/Classes, and then Hot Reload, the generated code itself should be fine. The Editor Assets referencing said classes, however, don't get loaded from scratch. As a result, assets deriving from/referencing the changed classes can potentially:

  • Lose values -They get reset to the c++'s classes defaults

  • Get corrupted functions/pins inside BP Editor

  • Get Corrupted Pointer Variables

  • Get HOTRELOADED_Classes. If the file does not get corrupted, this can sometimes be resolved by restarting the editor.

  • End up Corrupted altogether, in which VCS/Remaking the asset are the only way out.

What then? Live Coding!

The benefit of Hot Reload was not having to close the editor, compile from IDE, then reopen every time changes were made. If Hot Reload is to not be used anymore, how do we avoid this massive loss in time? Luckily, starting from Unreal Engine 4.22, Live Coding was introduced into the Engine!

However, it is not perfect. Here is some important information about working with Live Coding:

  • It does not override the CDO loading defaults.

  • It doesn't actually compile code. Instead, it creates a memory patch. If you were to close a project with which you used Live Coding on and pressed compile inside your IDE, it will actually compile the code changes.

  • For UE4 Types/macros, it is limited to changes in the .cpp files only with the exception of Constructors and Destructor instruction sets. For that, reference the HasFlags() above.

With that said, there definitely are vast benefits from it!

  • When enabled, it prevents your IDE from accidentally Hot Reloading when building using the Default Ctrl+LShift+B / Run / Debug.

  • If you make changes to your Headers involving UE4 types/macros, it doesn't fully process them. While this can lead to weird bugs, it does not cause Data Corruption. To fix it, close the editor, compile from IDE, and relaunch!

Troubleshooting

For proper building after Hot-Reloading,

  • Close the Engine, and in your IDE, run the Clean Command followed by Build.

For dealing with Corruption, first, run a proper re-build.

HOTRELOADED_ Classes / Invalid Variable Corruption / Invalid Class Corruption

  • First, try restarting the Editor. Sometimes, this will be enough for the Linker to correct it.

  • For Invalid Variable Corruptions, there have been instances when commenting the variable out, compiling, opening the engine, closing, commenting out, and recompiling has been sufficient.

  • In some instances, dealing with this issue may be equivalent to Corrupted UAssets.

Corrupted Uassets,

  • Unfortunately, for broken UAssets, there are usually only two ways to go about it: Restore a previous version from Source Control or remake the class.

It is common for HotReloaded assets to crash, especially blueprints. An easy way for detecting when a Blueprint Class has been HotRelaoded beyond repair is that it will crash with "this" being the nullptr. To troubleshoot this, Launch the engine from your IDE in DebugMode.

Workflow

For projects that do mix development approaches, here is the suggested workflow:

  • For any changes potentially involving CDO modifications, close the Editor, compile from IDE, and Restart.

  • For small iterative changes to non-CDO pertaining code, Live Coding is there for you!