Any way to verify previously cooked blueprints are still compatible with newer underlying C++ code?

Development Pipeline & Plugins
, ,
1

We currently have the ability to mount cooked paks at runtime and are organizing our paks into a set of assets that are loadable to run a specific map along with all its referenced secondary assets so that we can load a level at runtime with those cooked paks (on Windows, Linux, and Android). We would like to reuse the blueprint and assets from a previously cooked set of assets in a newer version of our C++ built code. Is there any way at runtime or at editor time (with commandlets) to verify that a previously cooked blueprint will still be compatible with a newer version of our C++ code?

We know that currently we can do this by compiling blueprints either through the blueprint editor or using the CompileAllBlueprints commandlet, but we’re not quite sure how this would work with already cooked blueprint assets. Is there maybe a way to re-compile cooked blueprint assets to verify that the C++ calls that blueprint has access to are still available and compatible with that compilation? Or is there a way to verify this some other way using the virtual machine that runs these blueprints at runtime? We’re happy to do this either at editor time or at runtime via a Gauntlet test.

Please advise on how we can check for forward compatibility of our previously cooked blueprints. Thank you.

2

Steps to Reproduce

3

Hi [mention removed]​,

Once assets are cooked, they are converted from editable .uasset files into a platform-specific, optimized binary format. As a result, they cannot be recompiled against a new version of your C++ code, neither through the Editor nor using commandlets like CompileAllBlueprints. For example:

- Blueprints are converted to bytecode for the Blueprint Virtual Machine (VM)

- Materials are compiled into platform-specific shader bytecode

- Meshes are converted to platform-specific vertex and index buffer data

To verify that previously cooked assets remain compatible with your new C++ code, you can try the following:

1- Gauntlet or Standalone Runtime Test:

As you mentioned, you can generate a Gauntlet test that mounts your specific pak file with the old cooked data and generate the specific tests to check all the Blueprint logic. If you need help on how to generate these tests let me know. If any expected data or bindings (e.g., C++ functions, properties) are missing or incompatible, Unreal will raise runtime errors during execution.

2- Test cooked assets in Editor

Unreal also has the ability to load cooked assets back again to the Editor for validation. The good part is that you can import them directly without the need of rebuilding the project. For being able to do this, you need to enable the following variable inside your DefaultEngine.ini:

[/Script/UnrealEd.CookerSettings] cook.AllowCookedDataInEditorBuilds=True s.AllowUnversionedContentInEditor=1

And lastly, you need to enable Engine->Cooker->AllowCookedContentInTheEditor,

[Image Removed]

These runtime/editor compatibility checks are typically applicable to:

Textures Materials Static Meshes Sound waves Cascade Particles Animation Sequences Skeletal Meshes Level Sequences AnimBPs BP_EnumsAnd the following have known issues, and are not guaranteed they will work:

Niagara BlueprintsTo import the assets into the editor, you need to import all there related files. And example could be a .uasset and its .exp file. As it is bytecode already, you are not allowed to open the editor or modify again the asset, but you can use it for testing.

Epic documentation: https://dev.epicgames.com/documentation/en\-us/unreal\-engine/working\-with\-cooked\-content\-in\-the\-unreal\-engine

3- Using cooked loose files:

Last option that I understand that does not fit with your system is using cooked loose files (.assets, .uexp, and .ubulk) instead of packaging them into pakfiles. If the files retain the exact same relative path, you can replace cooked assets or use the old one.

These are the options I can think of that could be close to what you are trying to achieve. Let me know if any of these help with your case.

Best,

Joan