We have a game, published on the Epics Games store, using Easy Anti Cheat.
Now, the prerequisite for running the game is to install the EAC installer first. But also, any UE game really needs UEPrereqSetup_x64.exe to run first. This installs VC14 and some other basic DirectX components.
Normally, the UE bootstrapper, GameClient.exe, will do this, prior to launching the game proper. But for EAC, we have replaced the bootstrapper with the EAC bootstrapper, so automatic installation of prerequisites won’t happen.
Now: what I want to know is whether the execution of the UEPrereqSetup_x64 is really necessary in the context of the Epic Games Launcher. This is because the EGL cannot execute more than one automatic prerequisite without resorting to a .bat file and thus opening up an unsightly console window. Also, the UEPrereqSetup_x64 sometimes takes a long time to run and requires elevated permissions. It would be best if we could just skip the prereq installer, and rely on epic games launcher to install those…
But I cannot be certain. And it would be unfortunate if launchign the game would fail on some PCs that for some reson don’t have VC14 runtime or the necessary basic DirectX components that are added by the prerequisite installer.
Can you help clarify the necessity for this installer? does the Epic Games Launcher itself make sure that those components are present?
The EGL will install the prerequisites as part of its installation but you should not rely on it for your title. The best solution is to add the prerequisites part of the game package. If you are packaging from the editor, you can check the “Include app-local prerequisites” project setting. The editor will generate the proper argument when it issues the call to BuildCookRun.
If you are packaging from a build machine, you can add the following to the BuildCoorRun command line: -applocaldirectory=$(EngineDir)/Binaries/ThirdParty/AppLocalDependencies
In regards to this, I realize that our understanding of windows packaging is perhaps a bit limited. I have a number of questions here, that you might be able to help me with. I’ve been playing around with the Project Launcer to review the BuildCookRun arguments that we have been using in our scripts for years.
We have been in early access for a while but with release loming we’d want to to do things properly.
What is the significance of the -package and -distribution flags for the Windows platform? Until now, we have simply used -stage.
What is the preferred way of distributing prerequisites? The Project Launcer just adds the -prereqs flag, which I assume used during the Stage phase, to install the UEPrereqSetup.exe. I do not see it adding the -applocaldirectory, even though I have added that setting in the project as per your suggestion. I guess one would want one or the other (the app local way is more appealing to me since it has no global effects on the target machine)
You should use both arguments when generating official packages that you plan on distributing.
-Package doesn’t do much for a Windows package but is required on other platforms it’s better to keep it there as it might do something in a future release.
-Distribution: It modulates the level of compression for the Pak\IOStore. Some platforms also consume this argument and will flag the resulting package so it can be published the different stores.
applocaldirectory is automatically added based on the project setting only when packaging from the editor. It must be added manually to the argument list when the AutomationTool is used outside the Editor (cmd prompt, batch file, build machine…) Epic doesn’t have a preferred distribution per se although Fortnite does use the local option.
I spoke with Patrick who handled your earlier case and he’s telling me that you should not need to stage the local dependencies since the Store will install the required package for you . [Content removed]
That’s right, it will install VC14. But that is not the only dependency unless I am mistaken. There are DirectX dependencies in the applocal folder as well, and they are not mentioned in the MicrosoftGame.config file.
When pacaged with “-prereqs” flag, WinDBG will happily package UEPrereqSetup_x64.exe with the application and the bootstrapper will run it if required.
This is a very unclear area, I find, for windows. Explicit instructions for best practice for distribution on windows/windbg regarding prerequisites would be good.
Windows: Can I choose between UEPrereqSetup or the applocal depends?
WinGDK: Do I need other dependencies besides VC14? directx? Is UEPrereqSetup needed at all or is VC14 in the WindowsGame.config manifest the only thing reqired? (applocal dependencies don’t work out of the box)
For Windows: The prereqs installer is mostly useful for older OS versions. More recent versions (11\10) do ship with most of the packages in the installer. The only missing package is usually the VC2022 CRT dlls.
WinGDK: This only support Win10 and onward, You should be fine with letting the system update the VC14 dependencies. It’s a bit confusing in name but it’s what the game needs.
From what I understand, that is only to copy dlls to my game executable location. What I am talking about is the _installing_ of prerequisites, i.e. running of particular .exe files prior to first launching the game. The Unreal bootstrapper usually does this automatically, but until now we have been replacing that with the Easy Anti Cheat boostrapper.
It is really hard to find details of what exactly UEPrereqSetup.exe installs on the machine. I can’t find it now, but I remember at some point that there were some basic DirecX packages, some VC runtimes, and the like.
However, we have recently figured out how to modify the Unreal bootstrapper to call the EasyAntiCheat boostrapper instead of the main game, so I guess we are safe, because as long as the UnrealBootstrapper runs, all the system prerequisites should be covered. Then there is only the EAC installer that needs to be run before the game.
(The bootstrapper can be patched by re-writing the resource #201 in it, which holds the relative path to the executable to launch. We can do this as part of our EAC packaging scripts that run between staging and packaging)
Thanks. I was packaging from the editor using Project Launcer, specifically to get a list of canonical arguments to the BuildCookRun tool, but the argument wasn’t added there. I guess this prerequisite business must constitue UE “lore” since I cannot find much information on the “proper” way to do this. I’ll be going forward with app local prerequisites on windows to minimize install requirements. Was previously unaware of this possibility.
Okay, -applocaldir does not work correctly for WinGDK.
Although it is called from WinPlatform.Automation.cs here, as “StageAppLocalDependencies(Params, SC, “Win64”);”, it ends up looking for a target folder of Win64. I added diagnostic code here:
static void StageAppLocalDependenciesToDir(DeploymentContext SC, DirectoryReference BaseAppLocalDependenciesPath, StagedDirectoryReference StagedBinariesDir) { // Check if there are any executables being staged in this directory. Usually we only need to stage runtime dependencies next to the executable, but we may be staging // other engine executables too (eg. CEF) List<StagedFileReference> FilesInTargetDir = SC.FilesToStage.NonUFSFiles.Keys.Where(x => x.IsUnderDirectory(StagedBinariesDir) && (x.HasExtension(".exe") || x.HasExtension(".dll"))).ToList(); if (FilesInTargetDir.Count == 0) { Logger.LogWarning("No executables found in {StagedBinariesDir} to stage AppLocal dependencies for", StagedBinariesDir); }which results in:
Staging AppLocalDirectory dependencies from $(EngineDir)/Binaries/ThirdParty/AppLocalDependencies No executables found in Engine/Binaries/Win64 to stage AppLocal dependencies for No executables found in Project/Binaries/Win64 to stage AppLocal dependencies forFor a WinGDK build, it should be looking at the “WinGDK” folder. I guess there should be a way to find the destination platform from the “active” platform, while the source platform is Win64.