Description
    1. Summary

When using the Level Instance Property Override system, overrides applied to `AActor::Tags` are silently lost for Blueprint actors whose Construction Script assigns or appends to `Tags`. The override is applied correctly before the CS runs, but `RerunConstructionScripts()` then overwrites it, and there is no post-CS re-application for actor-level properties.

    1. Steps to Reproduce

1. Enable `bEnableLevelInstancePropertyOverrides`.
2. Create a Blueprint actor whose Construction Script sets `Tags` (e.g., `Tags = ["Default"]`).
3. Place the Blueprint actor inside a Level Instance.
4. Use the Level Instance Property Override asset to override `Tags` to a different value (e.g., `["Overridden"]`).
5. Load the Level Instance in-editor.
6. Inspect `Tags` on the actor at runtime — it contains the CS value, not the override value.

    1. Expected Behavior

The overridden `Tags` value should be present on the actor after the Level Instance loads, matching what was set in the Property Override asset.

    1. Actual Behavior

The actor's `Tags` value matches what the Construction Script set, not the override. The override is silently discarded.

    1. Root Cause

The apply sequence in `LevelInstanceEditorPropertyOverrideLevelStreaming.cpp` is:

1. `ApplyPropertyOverrides(Actor, bConstructionScriptProperties=false)` — actor-level props including `Tags` are written ✓
2. `Actor->RerunConstructionScripts()` — Blueprint CS runs and overwrites `Tags` ✗
3. `ApplyPropertyOverrides(Actor, bConstructionScriptProperties=true)` — only CS-created components re-applied; actor-level props are *explicitly skipped* by this guard in `WorldPartitionPropertyOverride.cpp`:

```cpp
if (!ActorComponent && bConstructionScriptProperties)
continue; // actor-level properties skipped in post-CS phase
```

After step 3, the CS-written value wins with no recovery path.

Note: `Tags` is NOT excluded by policy. It passes all `CanOverrideProperty` checks in `ULevelInstancePropertyOverridePolicy` (EditAnywhere, not transient, TArray<FName> contains no instanced objects, no `DisableLevelInstancePropertyOverride` meta).

    1. Why Components Work But Actor Props Don't

CS-created components are destroyed and recreated by `RerunConstructionScripts`, hence the post-CS phase exists to re-apply their overrides. Actor-level properties survive the CS call on the persistent actor object, so no re-application was designed — but this breaks for `BlueprintReadWrite` actor properties that a CS actively writes.

    1. Suggested Fix

After `RerunConstructionScripts()`, re-apply actor-level (non-component) property overrides in an additional pass. This can be done by removing the `if (!ActorComponent && bConstructionScriptProperties) continue;` guard, or adding a dedicated third pass for actor-level properties post-CS.

    1. Affected Files
  • `Engine/Source/Runtime/Engine/Private/WorldPartition/WorldPartitionPropertyOverride.cpp` — `ApplyPropertyOverrides`, the skipping guard
  • `Engine/Source/Runtime/Engine/Private/LevelInstance/LevelInstanceEditorPropertyOverrideLevelStreaming.cpp` — pre-CS → CS → post-CS orchestration
  • `Engine/Source/Runtime/Engine/Private/LevelInstance/LevelInstancePropertyOverridePolicy.cpp` — `CanOverrideProperty` (Tags passes correctly)
    1. Additional Note

The property override feature is currently editor-only (`IsEditorWorldMode()` gate in `LevelStreamingLevelInstance.cpp`, policy never set in non-editor builds). This bug is limited to the editor-time loading path.

Have Comments or More Details?

There's no existing public thread on this issue, so head over to Questions & Answers just mention UE-377760 in the post.

0
Login to Vote

Backlogged
CreatedMay 4, 2026
UpdatedMay 28, 2026
View Jira Issue