However, these setter functions (e.g., SetMaterialInstanceTextureParameterValue) currently always return false, even when the parameter update is successful. This may mislead users into thinking the operation failed.

A user initially reported this behavior for one function, but upon further inspection, this issue affects multiple setter functions across UMaterialEditingLibrary.

It would be helpful to review and correct the return logic for these functions to reflect whether the parameter update was successfully applied, and optionally provide more diagnostic output in case of failure.

This also do happen for the following functions:

• SetMaterialInstanceScalarParameterValue
• SetMaterialInstanceTextureParameterValue
• SetMaterialInstanceRuntimeVirtualTextureParameterValue
• SetMaterialInstanceSparseVolumeTextureParameterValue
• SetMaterialInstanceVectorParameterValue
• SetMaterialInstanceStaticSwitchParameterValue
• SetMaterialInstanceEnumerationParameterValue

The crash is not in the image writer. It occurs in FNiagaraGpuComputeDispatch::ProcessPendingTicksFlush() — a safety-valve path that runs queued GPU simulation ticks against a fabricated dummy view outside the scene renderer. A Data Interface supplies a resource pointer that is not valid in that context; the D3D12 backend then makes a virtual call on it and jumps to address 0x1.

The output format matters only because of write latency. EXR (float, ~16 MB/frame) and 16-bit PNG stall the pipeline long enough for world ticks to accumulate without a corresponding scene render, crossing the tick-flush threshold. JPG finalizes fast enough to stay under it.

Environment

Note: MRQ logs Using the default MovieGraphPipeline; the pipeline specified in Project Settings (MoviePipeline) is not compatible with graphs — the project-configured pipeline class is being silently ignored. Probably unrelated, but worth a look.

Exception

From the minidump exception stream:

ExceptionCode    : 0xC0000005   EXCEPTION_ACCESS_VIOLATION
ExceptionAddress : 0x0000000000000001
Info[0]          : 8            -> EXECUTE (DEP)
Info[1]          : 0x0000000000000001

AccessType 8 is the important detail — this is an executed jump to 0x1, not a bad read. The address lies in no loaded module. That is an indirect call through a corrupt vtable pointer, i.e. a virtual call on a freed or never-initialised object.

RHI breadcrumbs (both configurations):

Breadcrumbs 'RDGExecute_RenderThread'
 - NiagaraGpuComputeDispatch
 - RenderGraphExecute
 - WorldTick

Nsight Aftermath was enabled (RHI.Aftermath true) and produced no GPU crash dump, confirming a CPU-side fault rather than a GPU fault or TDR. MemoryStats.bIsOOM = 0. Driver not denylisted.

Callstack

Default configuration crashes on RHIThread, which loses the recording context and makes the bug very hard to attribute — the only Niagara frame is a template instantiated in the Niagara module:

D3D12RHI!SetShaderParametersOnContext()                        D3D12Commands.cpp:698
D3D12RHI!FD3D12CommandContext::RHISetShaderParameters()        D3D12Commands.cpp:759
RHI!FRHICommandSetShaderParameters<FRHIComputeShader>::Execute()
Niagara!FRHICommand<...SetShaderParameters<FRHIComputeShader>...>::ExecuteAndDestruct()
RHI!FRHICommandListBase::Execute()
RHI!FRHICommandListExecutor::FTranslateState::Translate_ExecuteCommandList()
RenderCore!FRHIThread::Run()

Re-running with -norhithread -forcerhibypass moves the fault to RenderThread and exposes the recording site:

D3D12RHI!SetShaderParametersOnContext()                             D3D12Commands.cpp:698
D3D12RHI!FD3D12CommandContext::RHISetShaderParameters()             D3D12Commands.cpp:759
Niagara!FRHIComputeCommandList::SetBatchedShaderParameters()        RHICommandList.h:2631
Niagara!FNiagaraGpuComputeDispatch::DispatchStage'::<lambda_2>()    NiagaraGpuComputeDispatch.cpp:1871
Niagara!TRDGLambdaPass<...>::Execute()                              RenderGraphPass.h:704
RenderCore!FRDGBuilder::ExecutePass()                               RenderGraphBuilder.cpp:3525
RenderCore!FRDGBuilder::ExecuteSerialPass()                         RenderGraphBuilder.cpp:3549
RenderCore!FRDGBuilder::Execute()                                   RenderGraphBuilder.cpp:2157
Niagara!FNiagaraGpuComputeDispatch::ProcessPendingTicksFlush()      NiagaraGpuComputeDispatch.cpp:521
Niagara!FNiagaraGpuComputeDispatch::Tick'::<lambda_1>
RenderCore!ExecuteCommand()                                         RenderingThread.cpp:1533
RenderCore!RenderingThreadMain()                                    RenderingThread.cpp:261

Line attribution caveat: the lambda frame reports :1871 (DispatchComputeShader), but under bypass the preceding RHICmdList.SetBatchedShaderParameters(...) at :1869 is inlined into the same frame. The D3D12 frames confirm the fault is in the parameter set, not the dispatch.

Root cause

FNiagaraGpuComputeDispatch::ProcessPendingTicksFlush() — NiagaraGpuComputeDispatch.cpp:385

When GPU ticks queue up without being consumed by a scene render, Tick fires a flush whose behaviour is selected by fx.Niagara.Batcher.TickFlush.Mode (default 1). The CVar's own help text documents the hazard:

fx.Niagara.Batcher.TickFlush.Mode   (default 1)
  0 = Keep ticks queued, can result in a long pause when gaining focus again.
  1 = (Default) Process all queued ticks with dummy view / buffer data,
      may result in incorrect simulation due to missing depth collisions, etc.
  2 = Kill all pending ticks, may result in incorrect simulation due to
      missing frames of data, i.e. a particle reset.

Mode 1 fabricates a view with a null render target (:474):

cpp

FSceneViewFamilyContext ViewFamily(
    FSceneViewFamily::ConstructionValues(nullptr, GetSceneInterface(), FEngineShowFlags(ESFIM_Game))
    .SetTime(CachedViewInitOptions.GameTime));
...
GetRendererModule().CreateAndInitSingleView(RHICmdList, &ViewFamily, &ViewInitOptions);
TConstStridedView<FSceneView> DummyViews = MakeStridedView<const FSceneView>(0, ViewFamily.Views[0], 1);

bIsOutsideSceneRenderer = true;   // "Allow downstream logic to detect we are
                                  //  running pending ticks outside the scene renderer"

It then drives the full PreInitViews / PostInitViews / PostRenderOpaque chain against that dummy view. DispatchStage populates the batched parameters via SetShaderParameters(...) (:1866), which walks the shader parameter metadata including every Data Interface binding, and submits them at :1869. One of those bindings is invalid in the dummy-view context, and SetShaderParametersOnContext dereferences it.

The core defect: bIsOutsideSceneRenderer is only consulted in two places in the entire file (:1981 and :2143). It is never plumbed through to Data Interfaces, so a DI that binds a scene texture, depth buffer, or distance field has no way to detect the dummy-view context and bail out. The comment on :496 states the flag exists precisely so "downstream logic" can detect this — but downstream DI parameter population does not check it. The result is a corrupt pointer rather than the merely-incorrect simulation the CVar comment leads you to expect.

Trigger thresholds

fx.Niagara.Batcher.TickFlush.MaxQueuedFrames   default 3
fx.Niagara.Batcher.TickFlush.MaxPendingTicks   default 10

Either crossing trips the flush (:405, :418). The MaxQueuedFrames help text says it is "generally only a concern when the application does not have focus" — the path was designed for a minimised editor, not for MRQ, which legitimately ticks the world without rendering every tick (warm-up frames, temporal sub-samples, and finalization).

Why the output format correlates

Not alpha, and not bit depth — finalize/write duration. EXR and 16-bit PNG hold the pipeline long enough for ≥3 world ticks to elapse with no scene render, crossing MaxQueuedFrames. JPG does not. This also explains why the first crash landed exactly at MRQ's Moving to Finalize to finish writing items to disk — MRQ stops rendering the scene there while the world keeps ticking, so the threshold is crossed within a few frames.

Frequency

10 for 10 on 2026-08-18 between 10:59 and 11:40, all with an identical signature. Crash GUIDs in Flossing/Saved/Crashes:

0BF6DEB74DCE9C7AB3F1528D7896E696    RHIThread
7D28BEFC49E34ABB06214E92DFDD13B8    RHIThread
CA32B18048CB92979C8949B4F1D8B80F    RHIThread
493E616E4BD781DFE0F03095951E1E4F    RHIThread
6623D4FA464F18F9CED47EA9575F85D5    RHIThread
12BDB7D44C1E68A13674C48FA4370000    RHIThread
4E2B020A448915A91F9EF28233C0A07B    RHIThread
7156B1F74D6994B31C5AA99A25EB1540    RHIThread
DAB4A6DF4DB07931347BBBB81FD5C428    RHIThread
B8737D1445050FC93078BBA71C33A599    RenderThread  (-norhithread -forcerhibypass)

Diagnosis aid

The default RHIThread stack is effectively undebuggable for this class of bug — the resource is bound on the render thread and dereferenced later on the RHI thread, so the recording context is gone. Relaunching with the following moves the fault to the recording site and was what made this diagnosable:

UnrealEditor.exe <Project>.uproject -norhithread -forcerhibypass

(-forcerhibypass — RHICommandList.cpp:1886. r.RHICmdBypass alone is a silent no-op while the RHI thread runs, because LatchBypass() at :1897 requires !IsRunningRHIInSeparateThread().)

Workarounds

Recommended — prevents the flush from firing during a render, keeps GPU particles and correct simulation:

fx.Niagara.Batcher.TickFlush.MaxQueuedFrames 100000
fx.Niagara.Batcher.TickFlush.MaxPendingTicks 100000

Confirms the diagnosis — avoids the dummy-view path entirely:

fx.Niagara.Batcher.TickFlush.Mode 0     # keep ticks queued
fx.Niagara.Batcher.TickFlush.Mode 2     # discard pending ticks (visible particle reset)

Blunt — fx.NiagaraAllowGPUParticles 0. Avoids the crash but removes the GPU-simulated effect from the render entirely, so it is not viable for delivery.

Suggested fix

1. Plumb IsOutsideSceneRenderer() into Data Interface shader-parameter population so DIs depending on scene textures, depth, or distance fields can substitute a safe fallback binding. The flag already exists and is documented as being for exactly this purpose, but is only read in two places.
2. Validate resource pointers before binding in ProcessPendingTicksFlush's dispatch path, or skip stages whose DI bindings cannot be satisfied outside the scene renderer. Degrading to an incorrect simulation — which the CVar comment already sanctions — is strictly better than an access violation.
3. Consider having MRQ suppress or raise the Niagara tick-flush thresholds for the duration of a render job. MRQ intentionally ticks the world without rendering every tick, so it will always be liable to trip a heuristic tuned for an unfocused editor.
4. checkf(Handle.IsValid(), ...) at D3D12Commands.cpp:673 catches this class of problem in the bindless path. The non-bindless path immediately below (:679 onward) has no equivalent guard and dereferences straight away.

[Link Removed]
[Link Removed]
[Link Removed]
[Link Removed]
[Link Removed]

UReplicationSystem::NetUpdate will skip calling FDeltaCompressionBaselineManager::PreSendUpdate (which calls FDeltaCompressionBaselineManager::UpdateScope) until a valid connection is present; however, the actor's index will still be set in PrevFrameScopableInternalIndices. Because of this, when a valid connection is present, FDeltaCompressionBaselineManager::UpdateScope will not allocate object info for the actor due to it not being considered an object that was just added.

The issue does not occur with bAllowMinimalUpdateIfNoConnections set to false, as this causes FDeltaCompressionBaselineManager::PreSendUpdate to be called from UReplicationSystem::NetUpdate regardless of whether a connection is present.

`FZipArchiveCompressTest::RunTest` constructs `FZipArchiveReader`, which is editor only, but that section of the test is not wrapped in `WITH_EDITOR`.

This is a recurrence of [Link Removed] Closed . That issue was the same defect in `FZipArchiveTest`, fixed in 5.6 by wrapping the reader section in `WITH_EDITOR`. `FZipArchiveCompressTest` was added shortly afterwards with the same problem.

PausedTime = Context.World()>RealTimeSeconds - Context.World()>AudioTimeSeconds;

double CurrentSequenceTimeSeconds = UndilatedDeltaTime + AccumulatedDilation - PausedTime;

RealTimeSeconds - AudioTimeSeconds is the total time the world has been paused since it started, not since playback started. If the world was paused at any point before Play(), the first ticks return a time before the start frame.

ShouldStopOrLoop only checks the upper bound in forward playback, so the player evaluates at that negative time. Everything active at frame 0 is unlinked right after being linked. For example, IMovieSceneEvaluationHook::End fires one frame after Begin. The sequence then holds before its start until the elapsed time catches up with the total paused time.

This affects the Audio, Platform and RelativeTimecode clocks.

POST BODY:

• Summary
  The editor crashes when Media Viewer is viewing/capturing a Level Editor Viewport and the Level Editor viewport type is switched from Default Viewport to Cinematic Viewport. This is not caused by selecting a CineCameraActor itself; the crash happens specifically when switching the viewport type to Cinematic Viewport while Media Viewer is active.

• What Type of Bug are you experiencing?
  Rendering (Graphics / Niagara)

• Steps to Reproduce
  1. Open a UE 5.8 project.
  2. Enable/open the Media Viewer plugin.
  3. In Media Viewer, add or view a Level Editor Viewport.
  4. In the Level Editor viewport dropdown, keep the camera as needed, then change Viewport Type from Default Viewport to Cinematic Viewport.
  5. The editor crashes.

• Expected Result
  Media Viewer should display the Cinematic Viewport, or safely skip rendering/capturing that frame if the viewport render target is unavailable.

• Observed Result
  The editor crashes with an assertion in RenderTargetPool.cpp:

Assertion failed: Texture
File: Engine/Source/Runtime/RenderCore/Private/RenderTargetPool.cpp
Line: 95

• Affects Versions
  5.8

• Platform(s)
  Windows

• Upload an image
  Unable to render embedded object: File (attachment_1.png) not found.

• For crash reports, include your callstack
  UnrealEditor_Core
  UnrealEditor_RenderCore
  UnrealEditor_RenderCore
  UnrealEditor_Engine
  UnrealEditor_Engine
  UnrealEditor_Engine
  UnrealEditor_Engine
  UnrealEditor_MediaViewer
  UnrealEditor_MediaViewer
  UnrealEditor_MediaViewer
  UnrealEditor
  UnrealEditor
  UnrealEditor_RenderCore
  UnrealEditor_RenderCore
  UnrealEditor_RenderCore
  UnrealEditor_RenderCore
  UnrealEditor_Core
  UnrealEditor_Core
  UnrealEditor_Core
  UnrealEditor_RenderCore
  UnrealEditor_RenderCore
  UnrealEditor_Core
  UnrealEditor_Core
  kernel32
  ntdll

• Additional Notes
  Environment:

• Unreal Engine: 5.8.0-55116800+++UE5+Release-5.8
• Platform: Windows 11 25H2
• GPU: NVIDIA GeForce RTX 4060 Laptop GPU
• GPU driver: 581.57
• RHI: D3D12
• Dedicated VRAM reported by UE: 7957 MB

Notes from the crash log:

• MediaViewer is enabled and loaded.
• The crash is an Assert, not an out-of-memory crash.
• MemoryStats.bIsOOM is 0 in CrashContext.runtime-xml.
• Crash occurs in a Slate Paint context while MediaViewer is in the call stack.
• Original crash log contains user/session identifiers, so this report includes only the relevant sanitized details.

POST AUTHOR: danny6

CREATED AT: 08/30/2026 12:02 PM EDT

UPDATED AT: 10/19/2026 12:48 PM EDT

Root cause

PostProcessFFTBloom.cpp computes SurveyGroupGridSize from ViewTexelRadiusInKernelTexels (R):

2 * DivideAndRoundUp(CeilToInt(R) + 4, SurveyTileSize)(source)

so the survey grid spans texel offsets -4*G .. 4*G-1, roughly R+4.

BloomSurveyMaxScatterDispersion.usf however defines its center zone with 2R + 1 and edge zone with 2R + 4, i.e. it surveys texels out to ~2R+4. For radii where little rounding up happens, the entire grid lies inside the center zone, the survey is empty and the max scatter dispersion is 0, which makes the bloom vanish.

Fix

Size the grid from 2R:

2 * DivideAndRoundUp(CeilToInt(2.0f * R) + 4, SurveyTileSize)

This guarantees 4*G-1 >= CeilToInt(2R) + 3, the last texel the shader can survey. BloomSurveyKernelCenterEnergy.usf masks by R and is unaffected by the larger grid.

• This shader permutation has SUBSTRATE_INLINE_SHADING=1 and SUBSTRATE_DEFERRED_SHADING=0, the header/BSDF unpack from the payload is compiled out.
• SubstrateGetBSDFSharedBasis takes the inline path and returns the zero-initialized SharedLocalBases, so the hit normal is 0 and the light contribution is 0.
• The LF material's SUBSTRATE_FASTPATH / SINGLEPATH / CLAMPED_CLOSURE_COUNT and the default SUBSTRATE_USES_FORCED_COMPLEXITY=1 also drive how the hit surface is unpacked (the payload writer RayTracingMaterialHitShaders.usf:16-19 uses SUBSTRATE_USES_FORCED_COMPLEXITY 0).

Here is a work around:

[Link Removed]

When importing a .skp model into Twinmotion 2026.2 Preview as Geoemtry, using the Collapse all mode will cause materials to be displayed incorrectly, replacing most materials with a placeholder material.

This does not occur with the Keep Hierarchy collapse mode. Datasmith imports are also not affected.

In a non-World-Partition map with streamed sublevels, PCG Editor Mode interactive tools (Draw Spline / SpacingTool, Area, Paint, Volume, ...) spawn their new tool actor in the PersistentLevel instead of the current level (World->GetCurrentLevel()). This only happens when no compatible actor is selected when the tool is activated. Standard editor actor placement uses the current level (EditorActorSubsystem.cpp, ULevel* DesiredLevel = World->GetCurrentLevel();).

Reported by a licensee (EPS / SF case 27094155).

Expected

The tool actor is created in the current level (e.g. SubLevel_01).

Actual

The tool actor (e.g. "PCG Area Tool Actor") is created in the PersistentLevel and stays there after Accept.

Root cause

1. UPCGInteractiveToolSettings::InitActorAndComponent (PCGInteractiveToolSettings.cpp) reuses a selected compatible actor if there is one; otherwise it calls UE::PCG::EditorMode::Actor::SpawnWorking(World, ...). Every PCG Mode tool goes through this path.
2. Actor::Spawn / Actor::SpawnWorking (PCGEdModeActorHelpers.cpp) don't set FActorSpawnParameters::OverrideLevel. In Main (after [Link Removed]) SpawnWorking also hard-codes ULevel* Level = World->PersistentLevel; for the unique name and the external-actor decision.
3. UPCGActorHelpers::SpawnDefaultActor(const FSpawnDefaultActorParams&) (PCGActorHelpers.cpp) falls back to SpawnParams.OverrideLevel = Params.World->PersistentLevel; when no override is given (since CL 33654117), so UWorld::SpawnActor never reaches its own CurrentLevel default.
4. On Apply, the actor only has RF_Transient cleared and is never moved.

Not a regression. [Link Removed] touches the same function (WP external packaging) but does not change the level.

Proposed fix

In PCGEdModeActorHelpers.cpp, add a GetSpawnLevel(World) helper returning World->GetCurrentLevel() (falling back to PersistentLevel), set SpawnParams.OverrideLevel from it in Spawn and SpawnWorking, and use it for the existing ULevel* Level in SpawnWorking so name, external packaging and level stay consistent. SpawnDefaultActor's fallback is left alone because it's shared with runtime/generation spawning. In WP maps the current level is the persistent level, so behaviour there is unchanged. Fix verified locally on 5.8.3.

Workarounds

• Select a compatible actor that already lives in the target sublevel before activating the tool.
• After Accept, use Levels > Move Selected Actors to Level, then regenerate.

Original message

The UE5 Interchange GLTF importer appears to truncate skeletal mesh bone influences to a maximum of 4 influences per vertex, even when the source glTF asset contains additional valid JOINTS_n / WEIGHTS_n attribute sets representing more than four influences.

As a result, importing a glTF skeletal mesh through the Interchange GLTF pipeline can produce a skeletal mesh whose skinning data differs from the source asset, with additional bone influences being silently discarded.

Only the first 4 bone influences per vertex are imported. Additional influences present in the source glTF are discarded, resulting in incorrect skinning compared to the original asset.

Flavien reply

Flavien argue that this is what the spec said but the user said I misread the spec

It is the glTF specification that limits mesh bone influences to 4 per vertex. UE is aligned on the format spec.

Where do you get your glTF from? Are you exporting it from a specific DCC?

[Link Removed]

User reply

The glTF spec limits each JOINTS_n / WEIGHTS_n attribute to 4 joints/weights, but it does not necessarily limit a vertex to 4 total influences. Additional influences can be stored in additional attribute sets, for example:

• JOINTS_0 / WEIGHTS_0 → influences 0–3
• JOINTS_1 / WEIGHTS_1 → influences 4–7
• and so on…

The spec explicitly describes this mechanism for vertices influenced by more than four joints.

The asset was exported from Blender 5.2 using its built-in glTF 2.0 exporter.

• a World Partition cell that unloads and is reactivated before GC runs
• a global re-register from a cvar sink such as r.CustomDepth or r.RayTracing.Geometry.InstancedStaticMeshes.EvaluateWPO

It only happens in cooked/game builds, because component PSO precaching is disabled in the editor.

Fix: cherry-pick CL 55798320 (//UE6/Main) to //UE5/Dev-Release-5.8. It adds a guarded PrecachePSOs() at the end of both components' OnRegister, skipped when IsPSOPrecacheCalled() is still set. Pending CL 59512334 in Dev-Release-5.8.

Validation: cooked Development Win64 builds from Dev-Release-5.8.

• WP landscape map, player moves far away (cells unload) and back before GC: ensure fires in ULandscapeComponent::CreateSceneProxy without the fix, and doesn't with it.
• r.RayTracing.Geometry.InstancedStaticMeshes.EvaluateWPO 1: same result.
• EngineTest Project.Functional Tests.Tests.Rendering.DebugViewModes.DebugViewModes.BufferCustomStencil on Vulkan SM6 ([Link Removed]): Fail without the fix (groom ensure), Success with it.

Not covered: UGeometryCollectionComponent has the same gap (it precaches in PostLoad only).

Symptom: characters spawn at a crude LOD and can never stream up for the lifetime of the proxy.

FSkeletalMeshSceneProxy copies ForceStreamedLOD from FSkinnedMeshSceneProxyDesc at construction and encodes it as a negative TexelFactor in GetStreamableRenderAssetInfo, which only runs when the proxy is created. USkinnedMeshComponent::SetForceStreamedLOD reports later changes through IStreamingManager::NotifyPrimitiveUpdated, but FRenderAssetStreamingManager::NotifyPrimitiveUpdated

early-returns unconditionally when SSAM is enabled. Nothing else triggers a re-gather, so the streamer stays pinned to whatever LOD happened to be in effect at proxy creation.

This looks like a consequence of CL 53550964 (Main: 53550977 ) moving the gather from IPrimitiveComponent, which was deprecated there, onto the proxy. The component path was re-queried on

NotifyPrimitiveUpdated; the proxy path is a one-time snapshot.

Impact for us: an instrumented run showed 33 of 276 skeletal mesh registrations permanently pinned worse than requested. It is most visible on unique meshes such as named-character heads, since

residency is per asset via Max(LODNum - ForceStreamedLOD) and shared meshes get rescued by whichever requester wants the best LOD.

Local workaround: call MarkRenderStateDirty() in SetForceStreamedLOD (Engine\Source\Runtime\Engine\Private\Components\SkinnedMeshComponent.cpp)when SSAM is enabled and SceneProxy is non-null, forcing a re-gather.

Question: full proxy recreation is heavier than necessary. Would you prefer a targeted proxy-side update plus SSAM re-registration, or should SSAM expose a refresh entry point for this case?

Also verified present in //UE5/Release-5.8, //UE5/Dev-Release-5.8, //UE5/Main and //UE6/Main.

There are two issues:

1) When some verts are culled from the cloth mesh section, cloth explodes in editor. When this happens in package it can crash

2) If we cull the entire Tshirt so that the mesh underneath the jacket is removed, in editor the transient skeletal mesh shows no clothing data. But in packaged build we get a crash because the mesh section has zero vertices but there cloth data still exists.

We have one background worker evaluating an animation, holding the RigHierarchy's ElementsLock and waiting for the global GC lock

And one Background worker inside garbage collection holding up the release of the global GC lock and calling `URigHierarchy::AddReferencedObjects(UObject *, FReferenceCollector &)`, which tries to lock ElementsLock.

This occurs basically 100% for us when playing for a reasonable amount of time, please advise on a fix.

There are cases where SpawnedActor can retain stale data from a previous call, for example when the Spawn Actor ability task node is executed repeatedly inside a Blueprint loop. This can be problematic, as licensee mentioned, during World teardown, where ShouldBroadcastAbilityTaskDelegates() may return false and the spawning branch is not executed. In this case the function may return true while SpawnedActor still contains a stale pointer from a previous execution.

A straightforward fix would be to set SpawnedActor = nullptr at the start of BeginSpawningActor, similar to other ability tasks that spawn actors (e.g. UAbilityTask_VisualizeTargeting and UAbilityTask_WaitTargetData).

This does not appear to be a regression, as the implementation of AbilityTask_SpawnActor.cpp has remained largely unchanged since UE5 introduction. Behavior reproduced in UE 5.7 and UE5-Main CL 51575875.