Unreal Engine 5.8 Preview

Not even in a blank project can I package it. Has anyone managed to package successfully?

Yeah I’m in windows 11 and I have done shipping build several times.

2 Likes

When I hold Alt and right mouse click and move the mouse in the viewport. There is 50% chnace that the asset will get selected in the viewport and the menu will pop up.

It’s really a frustrating issue. I can’t work properly because of this stupid feature. Please either disable the right-click selection when holding the Alt key. Right now, it doesn’t matter how long I keep holding Alt-click. If I just press right click while holding the Alt key, it will select any mesh behind the cursor.

Working on preview version..?

Crash on Linux with preview and latest 5.8 branch

Signal 11 caught.
Malloc Size=262146 LargeMemoryPoolOffset=262162
Alignment > 16 is not supported
CommonUnixCrashHandler: Signal=11
Malloc Size=262146 LargeMemoryPoolOffset=524338
[2026.05.29-09.36.52:300][  2]LogCore: === Critical error: ===
Unhandled Exception: SIGSEGV: invalid attempt to read memory at address 0x00007f9fb8083fd8

[2026.05.29-09.36.52:300][  2]LogCore: Fatal error!
Additional Crash Context (Key=“Breadcrumbs_Parallel_0”, Value="Breadcrumbs ‘Parallel’

Radiosity

LumenSceneLighting

Scene

RenderGraphExecute - /ViewFamilies

SceneRender - ViewFamilies

Frame 2
")[2026.05.29-09.36.52:315][  2]LogRHI: Error: Breadcrumbs ‘Parallel’

Radiosity

LumenSceneLighting

Scene

RenderGraphExecute - /ViewFamilies

SceneRender - ViewFamilies

Frame 2

Additional Crash Context (Key=“Breadcrumbs_Parallel_1”, Value="Breadcrumbs ‘Parallel’

FXAA

PostProcessing

Scene

RenderGraphExecute - /ViewFamilies

SceneRender - ViewFamilies

Frame 2
")[2026.05.29-09.36.52:317][  2]LogRHI: Error: Breadcrumbs ‘Parallel’

FXAA

PostProcessing

Scene

RenderGraphExecute - /ViewFamilies

SceneRender - ViewFamilies

Frame 2

Additional Crash Context (Key=“VKhashes”, Value=“Vertex=D600737B1B121E7E, Pixel=25A40D72244320A0 (tid:559645, pt 0)”)[2026.05.29-09.36.52:318][  2]LogVulkanRHI: CreatePipeline: Vertex=D600737B1B121E7E, Pixel=25A40D72244320A0 (tid:559645, pt 0)

LogInit: Running DelayedAutoRegister Phase IniSystemReady
LogInit: Running DelayedAutoRegister Phase EarliestPossiblePluginsLoaded
LogInit: ExecutableName: CrashReportClientEditor
LogInit: Build: UE5-CL-0
LogInit: Platform=Linux
LogInit: MachineId=a6d5304c4eab4c14a98f8c97a3c9f883-000003e8
LogInit: DeviceId=
LogInit: Engine Version: 5.8.0-0+UE5
LogInit: Compatible Engine Version: 5.8.0-0+UE5
LogInit: Net CL: 0
LogInit: OS: Fedora Linux 43 (Workstation Edition) (7.0.9-105.fc43.x86_64), CPU: Intel(R) Core™ i9-14900KS, GPU: UnknownVendor
LogInit: CPU Model ID: 6b71, microcode revision: 133
LogInit: Compiled (64-bit): May 29 2026 11:00:17
LogInit: Architecture: x64

GPU says unknown vendor but it’s

AMD Radeon™ RX 7900 XT

Mesa version: Mesa 25.3.6

While your fixing things, please look into your Advanced Water plugin. Because none of it’s shallow water simulations actually work in Builds.

Why does 5.8 Mess up imported Foliages from Megascans ? It seems to be the Billboard messing up.

1 Like

Hello! I would be happy to know can i stick with MegaLights feature for my future projects, so no worrying it will get deleted, because its only thing that makes my game run 70 fps with 1000 lights.

No, I am working 5.6. But this issue has been in the engine for a long time, and it’s still there even in 5.8. So, I am mentioning in the preview thread because that is the only way to get this noticed quickly. Maybe it might get fixed when the UE team releases the 5.8’s stable version.

Title: MCP plugin (Experimental) — tool calls crash/wedge the editor; can’t create geometry in 5.8 Preview 1 (Linux)

Body:

Trying out the new Experimental Model Context Protocol plugin in 5.8 Preview 1 and wanted to report a reproducible problem with the tool-call path, plus ask whether anyone’s gotten geometry creation working through it.

Setup

  • Ubuntu 22.04, UE 5.8.0 Preview 1 (Linux), Third Person template project

  • ModelContextProtocol + ToolsetRegistry plugins enabled

  • MCP server: Auto Start on, http://localhost:8000/mcp

  • Driving it over raw HTTP (curl) to rule out any client-side issues

What works Read/introspection is solid. initialize, tools/list, and the three meta-tools (list_toolsets, describe_toolset, load_toolset) all return correctly. I can enumerate all 18 toolsets and get full schemas via describe_toolset — e.g. SceneTools with add_to_scene_from_asset, find_actors, etc.

What fails Any actual tools/call to an action tool (after load_toolset to register it) either wedges the server or crashes the editor. Each request is a single clean, fully-closed connection with the session id from initialize — one call at a time, no concurrency.

Symptoms:

  • The HTTP listen socket starts accumulating unaccepted connections (Recv-Q climbs on :8000), after which even a fresh initialize times out — the server stops responding while the editor process stays alive.

  • In one run it hard-crashed with this assertion:

Assertion failed: EHttpConnectionState::AwaitingProcessing == SharedThisPtr->GetState()
[HttpConnection.cpp:184]

Stack goes through FModelContextProtocolServer::ProcessToolCallJsonRpcCall (ModelContextProtocolServer.cpp:873) → ProcessJsonRpcCall → the HTTPServer CompleteRead. (Already submitted via the crash reporter.)

So the failure is specifically in the tool-call response path, not the read path.

Questions

  1. Has anyone successfully executed an action tool (e.g. spawned an actor / created geometry via SceneTools) through this plugin on 5.8 Preview 1, on any platform? Trying to tell whether this is Linux-specific or general to Preview 1.

  2. Is there a recommended transport/handshake for the tool-call path I might be getting wrong — anything beyond initialize → notifications/initialized → load_toolset → tools/call?

  3. Is the SSE/keep-alive behavior on /mcp documented anywhere? I suspect the connection-state assertion relates to how the streamed response is completed.

Loving that this is built in first-party — just trying to get past the tool-call wall so I can actually drive editor geometry from an agent. Any pointers appreciated.

1 Like

:heart_eyes: 5.8挺好的.同样场景下比5.7节省1.5ms

2 Likes

Haha, it’s hilarious :laughing:

2 Likes

Every new release disappoints me more and more. Performance in Unreal Engine 5.7 and 5.8 is terrible. They only managed to improve it by about 5%, but at the cost of stability in many areas that used to work extremely well.

Every update introduces a huge number of problems, breaks features that were working perfectly, and those issues often never get fixed. They add one good new tool, but end up damaging ten others that worked flawlessly.

Preview updates 1, 2, and 3 used to arrive much more frequently. Now they take months. This really feels like Unreal Engine’s decline, which is a shame.

And it all seems to stem from the obsession with adding features for filmmaking and virtual production. They have neglected, or simply forgotten, that this engine was originally built for games, not for making movies. In the process, they’re sacrificing optimization for the very thing the engine was designed to do: …GAMES.

6 Likes

I know the 5.8 is just days away, But UE Water with the Mesh Terrain needs work. On a 30K by 30K terrain, I could not get the Ocean working properly. And the Advanced Water plugin is not doing the shallow water simulations anymore. We have the same world in 5.7 and all these things work. Thanks

If you guys are serious about trying to get issues fixed then you should probably try to be more specific about what you’re encountering

1 Like

I don’t think that they have neglected anything. It has always been like this, even in UE4. The engine and the editor are getting more and more complicated and feature-rich, so more bugs are expected, unfortunately.

But if you just complain and don’t say anything exploitable about the issues you encountered, or create bug reports, it doesn’t help.

It makes sense to evolve the engine to support virtual filmmaking production, since most of the stuff required was already there and it’s something that can be worked on and added in parallel.

On the contrary, I think they are on the right track lately. Since 5.5, they have addressed many performance issues each release, even if we all wish we had fewer features breaking and fewer bugs.

Apparts from bugs the major issues currently for me are :

  • CPU performances
  • TSR that still have major ghosting issues (DLSS, FSR and XeSS are a must today anyway)
  • The Lumen denoiser that seems to be subpar (but they made some progress)
1 Like

Probably something like an extra 30 FPS for a project that’s pushing my GPU to the max. Forward shading on, lumen on, nanite on for most meshes. I haven’t done extensive comparisons but it changed my mind on needing to upgrade a GPU.

4060ti 16gb :sob:

Lumen and Nanite don’t work in Forward Shading, so if you’re in forward, both of them are disabled.

Another thing I hope to see happen in 5.8, is changing GASP. The UEFN skeleton is a waste of time. This ENTIRE PROJECT needs to be converted to the Manny skeleton. No one uses UEFN except for maybe the Fortnite devs. And they are less then 1% of the developers using Unreal. The engine already has a reputation of being a stuttering mess with gamers, We don’t need to be wasting CPU cycles on Live Retargeting for all of the humanoids in our game.