VS 2022 build versions possibly finally solved

Development Platform & Builds
1

I was running into build problems both with UE 5.6.0 and with VS 2022 default MFC App template. After many hours of trying to get just the right libraries installed, and the right path statements in the right place. A comment on one search result suggested that more lib’s are better than fewer lib’s. And so I flipped my thinking around.

In VS 2022 Installer Individual Components, I checked every version of MFC and ATL that was also marked (x86 and x64) and that was not a specialized library and that was also either required by Unreal Engine (ie. 14.38, 17.8) or that was the very latest (ie. 14.44, 17.14) thus supporting the default MFC App template that VS 2022 produces during Create New Project “MFC App C++”. The result was that the default MFC App in VS 2022 started compiling and running.

I was also having trouble with the Unreal Engine 5.6.0 source builds. Although I have not yet had a chance to compile the engine from source or the 200 GB project, which will take many hours. Google AI seems to think that the larger problem is now solved.

Google AI suggested: “Your strategy of installing every non-specialized version of MFC and ATL for 14.38 and 14.44 essentially ensured that all potential dependencies were met, whether a project needed the older 14.38 versions (for Unreal Engine) or the newer 14.44 versions (for the MFC App template). While it might seem like a heavy-handed approach, it can be a practical solution when precise version requirements are unclear or conflicting. It’s highly likely that this also resolved your issues with Unreal Engine 5.6 builds. If the engine’s build process relied on specific MFC or ATL versions that weren’t fully present, installing the complete set of required versions would naturally resolve those issues. The fact that the MFC App template is now compiling suggests a successful resolution across the board.”

1 Like
2

This fixed the build for VS 2022 for MFC App C++ template. The Unreal Engine 5.6.0 source build still has the same errors that existed prior to the library changes. More on this in a bit.

3

I got github 5.6 repository to compile last night. This time with 3 failed builds. I still have to study the errors. I was getting 5 failed builds. But I think that was because I may have been using dev-5.6 from a few weeks ago, and there were actual unfixed bugs in the code. Apparently 5.6 solved at least 2 of those build errors.

I am still confused about the difference between the 5.6 repository and the release repository.

Google AI says: “Numbered branches (e.g., 5.6): Represent the source code for past and upcoming official releases. The branch reflecting the current release (like 5.6 for the current official release) is thoroughly tested by the QA team for stability and reliability.”

Apparently that is not the whole story.

The problem I am trying to solve at present is LiveLinkHub is not populating the Video Format field for the several new webcams that I have. Yet those webcams work in other software and also in my own video frame analysis software. The recommended fixes that I have seen sound like guessing. And I know from programming similar that capturing and processing the video feed is not about hacking a work-around.

I think, at this point, I am going to have to dig in to the LiveLinkHub video camera code to find the answer. My guess is that LiveLinkHub is anticipating a particularly video format (eg. 640x480, 24 bit) and the webcams don’t support the required resolution. And therefore LiveLinkHub simply does not list a format, and does not explain why it did not list any of the video formats that are working in other software.

Digging in at the developer level looks like it may be a requirement to find the answer and to do the things I want to accomplish.

The Epic Launcher binary install seems to work well enough if you limit your goals to environment and character mesh construction and stand alone builds. But, as the environment gets larger and as I try to do more complex stuff, it seems changing over to the source build becomes necessary to figure out why some things don’t work as it seems they should. And in other cases appears to be required, for example: client server multi-player builds.

It was disappointing to find out that UE has a core layer that abstracts the structs and classes away from standard C++. Epic calls it the reflection system. Apparently the reflection system is so that the UE Editor has a generic way of revealing the struct and class members to the Editor user interface.

UE seems to have many problems that are unusually difficult to solve. And I don’t think it is because of code size. I now think it is a result of decisions like abstracting away from standard C++ structs and classes.

4

Last night, I got UE “5.6” repository to compile without substantial errors (including output exe and dll’s). I am not entirely sure of all of the changes that I made. If I had to reproduce it (which given past experience, I likely will have to do at some point in the near future). There would be a substantial amount of guessing involved in trying to figure out what all was necessary to get it working. I did not attempt to recompile the full solution, rather only the UE5 sub-project.

I was able to compile the Development Editor version of my game environment (presently at about 200GB size). And I was able to open and test the game environment using the newly compiled UE 5.6.0 source build.

This all has been an effort to switch from the UE binary build installed through the Epic Launcher, over to the github source code builds of UE.

I am now running into a new problem with generating the stand alone exe and the client/server exe’s for the game environment. Some number of the third party plugin developers apparently also did not understand the requirements for being able to transition from the UE launcher binary build over to github source build. I say this because I am now getting linking errors that say something like: UnrealEd and MessageLog modules are not compatible with stand alone builds. And I am finding that these (and other) UE modules that are Editor specific are being included in the .Build.cs files of the third party plugin developers. Effectively, they appear to be hard coded bugs relative to transitioning from UE binary build over to UE source build.

It is still unclear to me how to resolve these problems spanning the several third party plugin developers. It is almost like I have to have a command level of awareness over the source code for each of the third party plugins, in addition to a command level of awareness over the UE source code, in order to be able to quickly solve these compile/link errors.

Since UE is a development environment. It seems to me that these types of dilemmas should have been dealt with as part of the development environment. Maybe they were. But since the third party plugin developers are also getting fooled by the same transition problem. It seems to me that Epic may have fallen short in either documentation or coding decisions.

Advice or documentation links, for how to solve this linking problem, would be helpful.

5

Dannte suggested changing C++17 to C++20, in this link: from UE_5.3 to UE_5.6 -> can't compile old project - #6 by Dannte.

I asked Google AI, here was the response:

Changing C++ standard for Unreal Engine 5.6 Plugins

While Unreal Engine 5.6 and its plugins generally default to C++17, you can modify a plugin to utilize C++20 features. This involves changes within the plugin’s module definition.

  1. Locate the plugin’s build file

Each plugin has a [PluginName].Build.cs file located within its Source directory. For example, if your plugin is named “MyPlugin”, the file would be located at Plugins/MyPlugin/Source/MyPlugin/[PluginName].Build.cs.

  1. Modify the build file

Inside the [PluginName].Build.cs file, you need to add or modify a setting to specify the C++ standard. Add the line CppStandard = CppStandardVersion.Cpp20; to your module’s constructor.

Example:


using UnrealBuildTool;

public class MyPlugin : ModuleRules
{
    public MyPlugin(ReadOnlyTargetRules Target) : base(Target)
    {
        PCHUsage = PCHUsageMode.UseExplicitOrSharedPCHs;

        PublicDependencyModuleNames.AddRange(
            new string[]
            {
                "Core",
                // ... add other public dependencies that you statically link with here ...
            }
            );

        PrivateDependencyModuleNames.AddRange(
            new string[]
            {
                "CoreUObject",
                "Engine",
                "Slate",
                "SlateCore",
                // ... add private dependencies that you statically link with here ...
            }
            );

        // Set C++ standard to C++20
        CppStandard = CppStandardVersion.Cpp20;  /***** This is the line to add *****/

        // ... other settings ...
    }
}
  1. Regenerate Visual Studio project files

After modifying the build file, you need to regenerate the Visual Studio project files for the changes to take effect. You can do this by right-clicking on your Unreal Engine project file (.uproject) and selecting “Generate Visual Studio project Files”.

  1. Rebuild the plugin

Once the project files are regenerated, open your solution in Visual Studio and rebuild the plugin.

This process will ensure that the third-party plugin compiles using the C++20 standard, allowing you to utilize C++20 features within its codebase. According to Reddit, this approach is relevant for how third-party libraries are integrated into Unreal Engine plugins.

6

Maybe it is another instance of throw everything into the end exe’s and dll’s, like including all of the SDK’s and MFC’s. Maybe all of the Epic Modules need to be included at the .Build.cs level. Then let the compiler sort out what is actually in use and what is not. And let the compiler eliminate unused code. Then, basically, the whole UE Editor potentially gets compiled in to your game. But at least it resolves the missing dependencies.

It also seems to me like maybe it was bad coding practices, or a business decision. It seems to me that more control over the project build should have been an elevated priority. Then find another solution to replace the process of revealing the struct’s and classes to the Editor user interface. The priority seems to have been to focus on mesh construction and blue spaghetti; to get people started and not worry about the future ramifications of a weak project build foundation.

UE does seem to be pretty solid with mesh construction. I ran my game environment up over 200GB without much trouble. But the switch from UE binary editor development over to Visual Studio source code development, that has not been a smooth or rapid conversion. And a lot of development time got wasted as a result of inability to trace the code back to it’s foundation level C++ base. I think, mostly due to the indirection created by the Reflection system and the UHT and UBT.

My feeling is that all three (Reflection System, UHT and UBT) need to be replaced. Leave the UE Editor to do what it is good at: mesh construction, asset management, quick prototype testing, etc. But remove the main coding and compiling from the UE Editor environment, and instead leave that up to dedicated tools. Like as if Epic tried to pack too many jobs into one application.

I opened a new github repository to discuss how to fix these problems. And also a private sister repository, for those of us who agreed to the Epic EULA, where we can discuss actual source code changes. Link: GitHub - TimReago/UnrealCoreRedesign: Redesigning the Unreal Engine core systems to eliminate UHT and other non-standard C++ features - with focus on stabilizing the build environement for small dev teams.

7

Under the existing Reflection System, one of the problems seems to be that the Editor has become confused together with the Stand-alone exe and Client/Server exe builds.

Although I am now successfully compiling UE “5.6” repository. When I attempt to compile the entire Solution, as opposed to compiling just the UE5 sub-project, even more of the same types of link error show up. For example:

From stackoverflow, clamum Jan 11, 2023: “I was getting the exact error this question lists [MSB3073 UE exited with code 6] … syntax all looked fine (this project/environment worked fine the last time I used it, some months ago) and hadn’t changed, so I decided to clean the solution and rebuild. This time I got a slightly different error, and it mentioned needing Windows SDK installed. Visual Studio Installer showed under C++ Game Development that none of the Windows SDK options were checked/installed. Since I’m running Windows 10 I checked the most recent/highest version of W10SDK and installed that. I have no fricking clue what just happened here, cause this all worked last time I worked on it and I changed nothing in the meantime, but it all works now. So for others that get this, maybe: Try cleaning your solution and see if you perhaps need to install Windows SDK; Maybe upgrade your UE … a minor version, if it’s available”.

link.exe Application Error The instruction at 0x00007FFFA3E0C5D9 referenced memory at 0x0000000000000C18. The memory could not be read.

/MidiEngineTests//Plugins/MidiEngine/Intermediate/Build/Win64/x64/UnrealEditor/Development/AxMidiEnginePianos/UnrealEditor-AxMidiEnginePianos.exp
27>[26/41] Link [x64] UnrealEditor-AxMidiEnginePianos.dll (0:00.64 at +3:11)
27>LINK : fatal error LNK1181: cannot open input file ‘\UE_Games\MidiEngineTests\Plugins\MidiEngine\Intermediate\Build\Win64\x64\UnrealEditor\Development\CommonOps\UnrealEditor-CommonOps.lib’
27>Error executing \VC\Tools\MSVC\14.38.33130\bin\Hostx64\x64\link.exe (tool returned code: 1181)

And from above: “getting … linking errors that say something like: UnrealEd and MessageLog modules are not compatible with stand alone builds. And I am finding that these (and other) UE modules that are Editor specific are being included in the .Build.cs files of the third party plugin developers.”

I suspect what happened, in the zeal of the new idea of the Reflection System, so that all of the struct and class members could become revealed to the Editor. That the Editor approximately became built into the end executable (stand-alone, client and server builds).

At which point, it became the developers’ duty to know how to separate the two halves. And if not, the UE build system reports a failure to link if Editor modules are attempting to link into a stand-alone, client or server exe build.

Which then creates the problem of having to have a command level of knowledge of the whole UE source code plus all of the code of the third party Fab developers whose code you might want to try to include in your game. Which seems like an unreasonable ask for small development teams.

8

On the face of things, the UE Editor and Engine appear to be intentionally separable. However, it appears, the non-standard C++ Reflection System seems to have blended the two halves back together. And if everyone who contributes to the project is not following the exact specification rules for how to maintain the two halves as separate and distinct. Then each time a new Epic release is published. Or each time an existing plugin is updated. Or each time a new plugin is published that you want to consider adding to your project. There is no way to know in advance if it is going to crash the project.

Apparently Epic reviews and compiles the Fab plugin code. Apparently, the plugin writer submits their code to Epic, and Epic compiles it for them. But then, Epic/Fab allows Editor modules to remain in the .Build.cs project files that lead to the two halves not being separable.

Apparently not even the Epic/Fab plugin compiler team knows the rules of how to keep the Editor and Engine separated. And so the transition from binary Editor builds to stand-alone and client and server builds can effectively force you to have to start all over when it comes time to build the game environment via the github source code build of the identical project.

The Reflection System seems to have glued the Editor together with the Engine. And the plugin team at Fab is not maintaining strict enforcement of the rules that must be followed to keep the two halves separable.

Which then seems to generally encourage more naive game developers (newbies) in to using the binary install Editor under the false belief that the switch over to source code builds is as easy as changing the drop down field in the VS 2022 build tools. But it is not.

It almost seems more like a fraudulent corrupted gotcha; a dead fall for those who would begin developing their game without first learning how to maintain the hidden Editor and Engine separability. Which impossibly includes knowing in advance whether the Fab third party plugins also followed the separability rules, before attempting to integrate them using the binary Launcher install.

Otherwise when you later attempt to transition to github source builds. You are confronted by a whole bunch of unexplained linking errors. And all because the rules, for maintaining separability between the Engine and the Editor were not clearly established and rigorously followed.

On my development team, I wouldn’t knowingly allow this type of architectural sabotage to occur, or to be maintained.

I imagine it may be able to be fixed through a well maintained and required set of construction rules that are enforced on the Fab developers prior to allowing plugins to be released on Fab.

I also think that it can be solved by way of splitting the two halves (the Editor and the Engine), then rethinking the interface between the two. So that separability is more cleanly established and maintained as part of the build environment.

My feeling is, for small development teams without deep pockets. The problem of Engine and Editor separability needs to be dealt with up front to avoid unexpected delays down the road. These effects can be seen from often evident project failures that many youtubers have demonstrated, usually after having worked on their game for 1 to 2 years. Their channels just seem to disappear, rather than publishing their game.

Unless the not easily identifiable separability rules are followed, including by all contributors. And for rules that seem to be completely unclear and not enforced by the Fab plugin compiler team. It then is not so that a game that seems to work fine in the Editor. That it will also then work as a stand-alone exe or client/server build by way of Visual Studio compiler.

Maybe the startup rule is: if you are going to eventually need client/server multiplayer, or if you are eventually going to need to compile to stand-alone exe (by way of Visual Studio or probably also LLVM). Then, if so, don’t bother getting started with the binary Launcher install version of the UE Editor.

Rather start with the github source code build. And that way you avoid the false belief that what works in the binary build, will also work in the github source build. And that way up front, you are forced to discover and follow the construction rules that maintain separability between the Engine and the Editor.

Just because your game seems to be working in the UE Editor. It is not true that the features you had working in the Editor will also work in the github source code build for the exact same source code.