Did you try validating your install? I’m not seeing this issue but it could be because I tried packaging from a VR Template that was migrated from preview.
Update:
I deleted and recreated a VRTemplate project and packaged… are you sure you don’t have plugins installed or a UE5 install inside of a directory that already contained UE5 preview? … your path shows UE5/UE_5.5
Thanks, I verified the installation and created a new project, the error persists unfortunately. Next I’ll try to delete and redownload everything… that will take a while though
Edit: after deleting and downloading / reinstalling the whole engine the issue resolved itself. Thanks @Uno1982
When I activate the Metahuman plugin, I get an error:
The following modules are missing or built with a different engine version:
CaptureDataUtils
Engine modules cannot be compiled at runtime. Please build through your IDE.
I have no problem with 5.4.4. Any solution for this?
@Amanda.Schade After updating our project we received horrible HLOD build times with world partition. Build times went from a few minutes to 30+ minutes going from 5.4 to 5.5.
We created a new project and tried building HLODS there and it takes 20 minutes where it used to take 20-40 seconds on the sample open world map under “new level”. We checked the task manager and it seems in 5.5 you guys broke the ability of HLOD to use more then 2-3 cores? My CPU in 5.4 used to max out and build them really fast but now it sits around 3-4% and takes forever…
It seems locked to be 2-3 cores at max now regardless if you have more… Making builds take considerably longer on higher spec machines. We threw this on a threadripper with 128 cores and again what used to take 1-2 minutes is still running right now for 44 minutes. It used to take less then a few minutes. The CPU is barely utilizing 3-4% of its cores…
We also noticed it would build faster on a normal I9 12th gen over a threadripper because its “core” clock speed is faster then the threadripper. Something is horribly wrong. The threadripper im running is a pro 3955wx its on the top 10 best processors in the world so its not under spec by any means… We use it for workhorse tasks like HLOD/navigation work… There needs to be a fix for this ASAP!
The UE5.5 update is very powerful, but I have encountered some limitations that have made certain features unsatisfactory.
The main issue is with the Niagara system or emitter stage, specifically in CPU compilation. Occasionally, I need to write a for loop to batch write data using Custom HLSL. However, the number of iterations in the for loop must be a constant variable. If I use getArrayLength or other non-constant variables as the loop count, the compilation result becomes incorrect.
Additionally, when trying to read dataChannelRead in a GPU for loop, I found that it does not support Custom HLSL. Instead, I am only able to use node-based connections to perform the for loop, which is quite limiting.
This is a stupid way to bypass the hlsl can’t use the Datachannelread limit
Getting this crash with UE5.5, when trying to play in editor or rebuild paths, if async gathering is enabled in recast-navmesh. Anyone else with similar issue? Having 3 navmeshes if it makes difference. Can still have one of those with async enabled it seems. Couldnt find yet anything related in unreal insight.
Assertion failed: IsInGameThread() [File:D:\build++UE5\Sync\Engine\Source\Runtime\Engine\Classes\AI\Navigation\NavigationElement.h] [Line: 374]
Currenlty not allowing this to be called from non-game thread.
RayTracingDevice->CreateStateObject(&Desc, IID_PPV_ARGS(Result.GetInitReference())) failed
at D:\build\++UE5\Sync\Engine\Source\Runtime\D3D12RHI\Private\D3D12RayTracing.cpp:663
with error E_INVALIDARG
Still getting these errors when launching a DX12 SM6 packaged game for the SECOND time when HWRT(r.Lumen.HardwareRayTracing or the “Use hardware raytracing when available” in the project settings) is enabled or gets enabled during runtime.
Just to be clear: The game will launch fine on the FIRST launch, but then crashes with that error on the SECOND or any further attempts to launch it after that. The culprit is the _PCD3D_SM6.upipelinecache file located in the %localappdata%/GAMENAME/SAVED folder. If that file gets deleted, the game will launch correctly again for a first time, but will again, crash every time after that.
Windows 11 23H2
13600kf
2080FE+566.14 drivers
I also tested on a similar system with an AMD 7900xt and it did the same thing. I also tested using Vulkan SM6 and it doesn’t have this issue.
Thanks for flagging this issue! We have actually resolved this issue internally, however it still needed some additional testing. We are aiming to have the fix included in the next hotfix for 5.5. Unfortunately, I do not have a timeline for that at this time.
There have been several hotfixes and new functions implemented in UE, while the problem with this very essential feature has still not yet been resolved.
@Amanda.SchadeEpic please fix this problem: Constant and Step interpolation are no longer working properly as of 5.4 and NOW 5.5. Here I make a direct comparison to 5.2 so that it is easier to distinguish and see exactly how this has become broken.
Here is the more recent clip which goes a bit more in depth about the problem, and hopefully this gets resolved because it’s really inconvenient at this point.
Thank you for the update! Knowing that the fix is in the works is plenty enough me. I just wanted to make sure to raise awareness for it, in case it wasn’t a reported issue already.
In your linked post, the E_INVALIDARG crash on D3D12RayTracing is the one I brought up a couple posts up, with some details on the problem, and Matthew Ivey said they are working on a hotfix. It’s tied to HWRT and the PSO .upipelinecache file that gets formed in your %localappdata%/GAMENAME/SAVED folder.
This is also happening when attempting to change skeletal meshes via the Construction Script. Here is a video comparing a simple setup in 5.4 with the same setup in 5.5.
As reported in the preview forum … ue5.5 release is still experiencing call stack overflow fatal errors on projects that run fine in standalone and package fine.