Hot Reload and Live Coding

Compiling with the Editor Open Do's and Don'ts

Updated almost 3 years ago Edit Page Revisions
C++Programming

Common Guidance

What is "Hot Reloading"?

Hot Reloading is the process of compiling new DLL files while the editor is open and loading them. While Hot Reload often works for a while, it is unreliable and frequently causes blueprint corruption or other issues (more info below). Most users recommend avoiding Hot Reloading entirely, which means you need to close the editor to compile safely.

By default, a Hot Reload is initiated if you:

  • Compile from your IDE with your project/Unreal Editor open

  • Compile using the Compile button within Unreal Editor

  • Create new C++ classes inside Unreal Editor

    • You can stop this from occurring by disabling this setting in Editor Preferences: Automatically Compile Newly Added C++ Classes

If you initiate a Hot Reload, don't panic. Just make sure to close the editor without saving anything, run Build in your IDE, and carry on.

What is "Live Coding"?

Live Coding is a feature introduced 4.22 which is intended to eventually replace Hot Reload. It is disabled by default. You can enable Live Coding by clicking the dropdown arrow beside the Compile button in Unreal Editor and turning on the Live Coding checkbox.

As of this writing, Live Coding is only available on Windows.

You can initiate a Live Coding build by pressing Ctrl + Alt + F11. This shortcut works from anywhere (with your IDE in focus or Unreal Editor in focus).

Live Coding is still listed as an "Experimental" feature and still has some limitations:

  • You should typically close Unreal Editor to edit anything in .h files

  • You should close Unreal Editor to edit Constructor functions in .cpp files

Live Coding is reliable for modifying most other functions within .cpp files and is even safe to use during gameplay (during Play In Editor). Is also does not cause Blueprints to go corrupt upon saving like Hot Reload does.

Going Deeper - Technical Discussion

Additional technical information follows - this may assist you in understanding problems you're having, or help you to decide how to use Hot Reload if you cannot use Live Coding.

On Editor Startup, classes, and assets load with the CDO (Class Default Objects) settings at a UMACRO Level (UCLASS, UPROPERTY, UFUNCTION, USTRUCT, UENUM). This includes:

  • Class, Member, and Function Declarations

  • Constructors, Destructors, and instruction sets.

Changes in non-macro wrapped elements, such as non-U functions, non-U properties, and non-U classes can sometimes be reloaded with either Hot Reload or Live Coding.

With the above mentioned, there are valid workflows for Hot Reload with projects that mix c++ and blueprints, and that is with any changes that do not modify any content wrapped by UMacros and their CDOs.

Changes to header files which are scanned by UHT should be avoided. As such, any changes made to UCLASS/USTRUCT/UENUM type layout/signature should not currently be handled by these systems. Changes that are implementation only (.cpp) are usually okay. Changes to UCLASS/USTRUCT constructors do not apply retroactively to any already constructed instances (CDO is not re-instanced), so it is recommended to close the editor and perform a full recompile as well.

In this wiki article, we suggest using Live Coding as it acts as a protective barrier against potential Corruption. Furthermore, Hot Reload is considered to be a Legacy Feature. Both of these systems face the same limitations for updating CDO-related generated code.

Why Does Corruption Occur with Hot Reload?

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 definitions inside Unreal Engine Macros, 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.

Alternatives? Live Coding!

The benefit of Hot Reload was not having to close the editor, compile from IDE, then reopen every time changes were made. Starting from Unreal Engine 4.22, Live Coding was introduced into the Engine for Windows platforms!

Here is some important information about working with Live Coding:

  • It does not override the CDO loading defaults.

  • It iterates changes through a memory patch. If you were to close a project with which you used Live Coding and pressed compile inside your IDE, it will actually compile the code changes.

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

  • When enabled, it prevents your IDE from initiating a Hot Reload.

  • 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 HotReloaded 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!