I have a bit of code in the header file uint8 bInitialOwnerVelocityFromActor : 1 = true;
But it returns Error C7582 : ‘bInitialOwnerVelocityFromActor’: default member initializers for bit-fields requires at least ‘/std:c++20’.
Is there a way to initialize this variable in the header file without getting this error?
Check you project properties to ensure you have c++20 set
/std:c++20 /DSAL_NO_ATTRIBUTE_DECLARATIONS=1 /permissive- /Zc:strictStrings- /Zc:__cplusplus
It compiles ok here. No errors.
Your project is either not generated correctly or you forgot to select your project name and it was in the solution properties.
Here is a broken version (missing .vs and binaries, intermediate and saved folders)
How to regenerate => Right click your Uproject file
It should start generating and rebuilding folders
Upon loading the solution unfold the Games directory and choose your project name, then go to project => Properties
Huh, I tried rebuilding my whole project, but now the property window doesn’t open at all. All I get is this
The solution explorer is the more important panel. You need to set the lyra project as the default startup project.
What does the solution explorer look like in your case? (Your project file and folder structure)
Hi,
It looks something like this.
I am also struggling with this. Despite telling NMake to use std:c++20 i cant have UBT actually use it to build the solution. Really not sure what to do. As a workaround you can edit the engine source and remove the defaults. That will let the solution compile. But would like to know how to properly fix this.
I would check if you have the latest updates to vs and dot net. If you are using VS does your install have the c++ 2022 resdist. Do you have the Game devolpement with c++ package & Desktop development for c++ installed?
Yes, I went through the whole list yesterday and updated all the tooling in Visual Studio Installer. I tried to regenerate solution and use rider (always deleting Intermediate/Saved/(even DerivedDataCache, even if i dont think it should matter). But all to no avail.
So, there are a few things going wrong trying to upgrade to 5.4 from 5.3.2 on my end but I managed to find a temporary solution for all.
These are all hacky workarounds, I do not recommend using them as definitive fix but they should allow your project to build with 5.4 while we try to find a proper solution.
FOverlapResult is not declared: you can add #include Engine/OverlapResult.h to your file to sort this one out.IndexSize in BufferArchive.h causes “cannot access private member”. This is a weird one but seems like there is some internal confusion between 2 variables and some part of the engine is trying to access this variable instead of another variable somewhere else that is supposedly public. As a workaround I renamed the IndexSize to anything else in BufferArchive.h (it’s private so it’s only used there).std:c++ 20 error of this thread. Some header files in the engine have been updated to use default member initializer for bit-fields which is a C++ 20 feature apparently. As per thread, despite trying to make use of C++ 20 I wasn’t able to fix this. The solution was to remove the default initializer (so, for example, bool bDetectEnemies : 1 = false; becomes bool bDetectEnemies = false;)If anyone knows better, please let us know 
I’ve manage to find the solution
Just go to your Target.cs file and check if you are using the corrent BuildSettingsVersion, i was using V2 and i change it to V5 and works
I have Latest (which is V5) by default and it does not make a difference here.
Working off of JavierLarraz’s solution, I had to update the Target.cs file AND the Editor.Target.cs file to V5 and then our project was able to build and open properly.
@collederas Yeah I had tried fixing the bugs with the hacky workarounds, but I was afraid that it might break my project after I pull from the upstream again.
Would love to know if there is a better solution for this without changing the code.
Surely on next pull you’d have to do the same because changes will be overwritten unless you selectively merge
I went to those files it was complaining about and then added a space and removed it and then resaved it. It still didn’t work with the V5 change. I, then, deleted Engine/Intermediate and GameNAME/Intermediate, regen project files, and rebuilt, it then worked. Annoying, but it is what it is.
I have done some more purely empirical experiments on this. I personally managed to compile my previous 5.3 project in 5.4 by setting:
CppStandard = CppStandardVersion.Cpp20;
in .Build.cs
This was not needed when creating a project directly in UE5.4. I even ported my whole 5.3 C++ Source to the project created in UE5.4 and was able to compile it without the need for this addition in the Build.cs file.
Despite fixing this in a nicer way by avoiding all source code modifications, I still have no clue what’s going on 
Hope this helps someone.
This is the only solution that worked for me.
Hey there I was hitting this in the engine code and took me a hot minute to figure out why. Given that I’m running BuildSettingsVersion.V5 and Cpp20 at the Target level.
ubt> F:\Redacted\Engine\Source\Runtime\Engine\Public\NaniteSceneProxy.h(513): error C7582: 'bHasRayTracingInstances': default member initializers for bit-fields requires at least '/std:c++20'
ubt> F:\Redacted\Engine\Source\Runtime\Engine\Public\NaniteSceneProxy.h(514): error C7582: 'bNeedsDynamicRayTracingGeometries': default member initializers for bit-fields requires at least '/std:c++20'
ubt> F:\Redacted\Engine\Source\Runtime\Renderer\Private\ScenePrivate.h(2938): error C7589: defaulting comparison operators requires at least '/std:c++20'
Turns out what was happening was I had Nvidia’s DLSS plugin installed, I had fixed a couple errors to get it working with 5.4; but in StreamlineCore.Build.cs it was explicitly building with CppStandard = CppStandardVersion.Cpp17, so it was causing the parts of the engine that it was referencing to build with that too. Just commenting out that line so it builds with Cpp20 as specified by the Target.cs.
The way I discovered this was in VCToolChain.cs I dropped this line
Log.TraceWarningOnce($"rlabrecque - {CompileEnvironment.CppStandard} - {string.Join(" ", Arguments)}"); where it handles CppStandard. Then the log pointed me to any modules that were building with Cpp17. There’s a couple in the engine that do – but they don’t reference any code that breaks without Cpp20+.
Hope this helps.