IterativeCook UPROPERTY Issue

Environment:

- Unreal Engine Version: 5.5.4 (source build)

- Project Type: Large-scale multiplayer project, uses World Partition

- Cooking: Iterative Cooking (-iterate)

- Serialization: Default Unversioned Property Serialization (UPS)

- Assets: Thousands of DataAssets referencing USTRUCT and UCLASS

- Platform: Windows / Android (same issue on both)

- CI: Automated BuildCookRun pipeline

Steps to Reproduce:

1. Create a USTRUCT and a UDataAsset referencing it.

2. Save the DataAsset and perform a full cook.

3. Add a new UPROPERTY to the struct and compile.

4. Run BuildCookRun with -iterate (iterative cooking).

5. Launch the cooked build.

Actual Result:

- Iterative cook does NOT re-save or re-cook the DataAsset.

- Cooked data still contains the old schema (missing the new property).

- At runtime, UPS attempts to deserialize using the new schema and crashes:

- Serial size mismatch

- Bad export index

Expected Result:

- Iterative cook should detect schema/class layout changes and either:

* Mark dependent assets as dirty and re-cook them

* OR at least emit a warning that the asset schema is outdated and must be re-saved

Questions for Epic:

1. Is there a recommended way to make iterative cooking detect UPROPERTY schema changes and re-cook dependent assets?

2. Can the cooker emit a warning or error when a package’s serialized layout does not match the current class CRC?

3. Are there plans to improve dependency tracking so that C++ property changes invalidate assets automatically?

Legacy iterative cooking does not support detecting class schema changes. It also does not detect hidden package dependencies (dependencies not declared as imports in the saved editor package) and dependencies on external files such as shader files. We only recommend it when working locally without syncing large sets of changes, and with the caveat that you will need to try a full cook if any unexpected crashes happen after cooking iteratively.

We have been working on a new version of iterative cooking which detects those types of changes. We call the new version incremental cooking to distinguish it from the legacy iterative cooking.

Incremental cooking is experimental in 5.6 and we are raising it to beta in the upcoming 5.7. It is not available in 5.5 and earlier. In 5.7 it still suffers from some missing dependencies in a few engine types and it comes with caveats (most notably, it will not incrementally skip any packages with types from your project unless you enable that behavior in config). We will be publishing a document about what to expect from the beta incremental cooking feature when we release 5.7. In the meantime you can try it out in 5.6, by passing -cookincremental (WITHOUT -iterate or -iterative) on commandline. (Note that this setting to enable it will change in 5.7).