Please note that this behavior appears to be influenced by the state of the DDC and will only manifest when building the mesh the first time or after modifying the sculpt to need a new mesh

A Level Sequence Actor in a Level Instance points to a Level Sequence Asset that has an Event Track that creates the Director when scrubbed over. If Sequencer is open at the same time as the Level Instance is open for edit, a strong reference is created to the Director which uses the Level Sequence Actor in the Level Instance as its outer. When the Level Instance is closed, the level is kept alive by sequencer. Tearing down the level triggers GC which finds the leak and fatal errors.

To mitigate, the signature initialisation can be moved inside a static lambda.

 		static const FNiagaraFunctionSignature OutSig = []
		{
			FNiagaraFunctionSignature Sig;
			static FNiagaraVariable EmitVar(FNiagaraTypeDefinition::GetBoolDef(), TEXT("Emit"));
			EmitVar.SetValue(FNiagaraBool(true));
			Sig.Name = TEXT("Write");
#if WITH_EDITORONLY_DATA
			NIAGARA_ADD_FUNCTION_SOURCE_INFO(Sig)
			Sig.Description = LOCTEXT("WriteFunctionDescription", "Writes data into the Data Channel at a specific index. Values in the DataChannel that are not written here are set to their defaults. Returns success if the index was valid and data was written into the Data Channel.");
#endif
			Sig.bMemberFunction = true;
			Sig.bRequiresExecPin = true;
			Sig.bWriteFunction = true;
			Sig.bSupportsGPU = false;//Cannot use direct index writes on GPU as we write into one shared buffer with all DIs using the same NDC data.
			Sig.AddInput(FNiagaraVariable(FNiagaraTypeDefinition(UNiagaraDataInterfaceDataChannelWrite::StaticClass()), TEXT("DataChannel interface")));
			Sig.AddInput(EmitVar, LOCTEXT("ExecuteWriteFlagTooltip", "If true then the write is executed, if false then this call is ignored and no write occurs."));
			Sig.AddInput(FNiagaraVariable(FNiagaraTypeDefinition::GetIntDef(), TEXT("Index")));
			Sig.AddOutput(FNiagaraVariable(FNiagaraTypeDefinition::GetBoolDef(), TEXT("Success")));
			Sig.RequiredInputs = IntCastChecked<int16>(Sig.Inputs.Num());//The user defines what we write in the graph.
			return Sig;
		}();
		return OutSig;

Fortnite and some licensees have requested this feature, but it is a nice to have and has not yet been high enough priority to implement.

Many teams rely on Primary Asset Labels to determine what gets cooked and into which chunk. The decisions for which chunks assets can be put into can become quite complicated, and the id for each chunk is an integer. On large projects this necessitates some shared document recording the mapping from content to chunk. This would be less necessary if we could label the chunks.

Implement a field in PrimaryAssets that specifies an alphanumeric label for the chunk. If multiple conflicting labels contribute to the same chunk, give a warning and pick one arbitrarily. Name the pakfile based on the label rather than the integer chunkid.

Estimate and notes:
02hr Add label to PrimaryAsset.
04hr Add calculation of the label for a chunk based on the PrimaryAssets using that chunk (error out if there is a conflict)
06hr Change FAssetRegistryGenerator to read the label from the AssetManager and write it into the manifest.
16hr Change CopyBuildToStagingDirectory.cs to read the label from the manifest and use it to name the file.
08hr Fix edge case bugs when they come up.
36hr Total: 4.5 days

Notes:
Shaders assume chuckids are ints. Plan is to keep the authoritative id of a chunk as an integer, and carry around the mapping from integer to label (as a field in the chunk's manifest).
The reason the exploratory work stalled was dealing with how to appropriately upgrade licensee data.

The exploratory work done so far:
[Link Removed]

POST BODY:

• Summary

A TMap where the key is an FString can be created like so:

```
TMap MyMap =

;
```

3. close unreal engine

4. compile your code

5. launch the project. The project's module will fail to load. The error message you receive will be: "The game module 'MyProject570' could not be loaded. There may be an operating system error, the module may not be properly set up, or a plugin which has been included into the build has not been turned on."

• Expected Result

Compile-time error. If that isn't possible then a check being hit would be helpful.

• Observed Result

Project module fails to load. Unhelpful error message is shown. Logs are of no help.

• Affects Versions

5.7

• Platform(s)

Windows

• Additional Notes

Tested in 5.7. I did not try 5.8.

Happens whether FString is key or value.

Causes crashes anytime the code is executed. I chose static variable initialization time because that is the most difficult to debug, to show a case that could cause some engine users to lose a lot of time trying to debug.

It would be a good idea to update that error message so that it asks users to check static variable initialization for any errors.

POST AUTHOR: Fresh_mutroom

CREATED AT: 08/30/2026 06:31 PM EDT

UPDATED AT: 09/02/2026 10:33 AM EDT

Please note that this issue only reproduces with the Gamepad Face Button Bottom and does not occur for any other gamepad buttons or keyboard keys.

Actors can be converted into Instanced Actors via the IA plugin. During runtime and in the editor, an instanced actor’s visual is generated from the collection of StaticMeshComponents on the actor blueprint.

Problem

Any non-uniform transforms of StaticMeshComps on the actor blueprint aren’t correctly previewed in the editor. Instead, the IA representation in editor shows all meshes with the identity transform, albeit the IA’s location is correct. The relative transform from actor to mesh isn’t correctly previewed. See screenshots and repro project.

Suggested Fix

The relative transform should be correctly previewed.

Problem:
The problem is that when using "Texture Backed Render Target" as the Height Patch Source Mode everything seems to be working as intended when working in the editor at first, but when closing and opening the project again, Landscape patches are not applying properly the first time the level is opened.
The current workaround is to either reopen the level or recompile the blueprint containing the Landscape patch.
Note that the licensee noticed it seems to happen when "Waiting for texture resources to be ready for landscape named:Landscape" on a map startup.

This is because Movie Render Graph does not pass the Assembly object as a context object when evaluating “cat” tokens. This context should always be passed when a user renders a Cinematic Assembly. There is no need to offer an opt-out because always including the context should be considered expected behavior from the perspective of the CAT feature.

Texture size only available for Texture2D, TextureVirtual, Texture2DArray, VolumeTexture and SparseVolumeTexture, not unknown.

This is because Texture Collections that are Bindless mask their texture type with MCT_TextureCollection and FHLSLMaterialTranslator::TextureProperty doesn't take into account that mask, it just checks equality.

When the conditions mentioned in the Steps to Reproduce happens, the following happens:

• GameThread eventually get stuck on FlushRendering

• Workers (even including standbys when option is activated) and renderthread get stuck on FShaderCodeArchive::WaitForPreload

When going for the preload, an extra task that monitor the output of the IO completion event is created. The problem is that when the workers are oversubscribed, the extra tasks are never executed which cause the deadlock even though the IO for those preload requests are probably done.

See FShaderCodeArchive::WaitForPreload and FShaderCodeArchive::PreloadShader, the latter which create a FPreloadShaderTask with the read completion events from the storage as prerequisites.

Increasing the number of standby workers only delay the problem or in the case I studied did nothing at all. Disabling preload didn't seem like a great idea considering the slowness of zen storage (in comparison to straight SSD).

In the end, the solution seemed to be to bypass the prerequisites entirely and wait on the completion event directly (and the FPreloadShaderTask afterward). This enabled the tasks to work as intended possibly due to the task being able to run directly on the same thread during the wait period without having extra coordination through the prerequisite.

In Twinmotion 2026.1, when importing certain SKP files with grouped components, materials may render incorrectly on some grouped components and will appear with a dark, metallic color instead.

This is a regression from Twinmotion 2025.

This does not occur for Datasmith imports.

This Jira is for 5.8.3 tracking

From testing, this appears to occur only when using the bilateral upsampling path (r.VolumetricRenderTarget.UpsamplingMode=4). Other upsampling modes do not produce the artifact.