Those repro steps are one small part of our overall issues right now, as even after modifying Build.bat, our UGS is acting very strangely.
I noticed that unlike older versions of UE, the UGS installer now puts the whole set of UGS files into the “C:\Program Files (x86)” location, including UGS proper (UnrealGameSync.exe) where only the UGS Launcher (UnrealGameSyncLauncher.exe) used to live there, with UGS proper being located inside LocalAppData.
Anyway, that launcher finds our UGS files via our Perforce source and syncs those to LocalAppData. The launcher then runs the resulting UnrealGameSync.exe that’s in LocalAppData. So far, seemingly so good.
However, upon a subsequent run of the UnrealGameSync app, which executes UnrealGameSyncLauncher.exe that’s living in program files, it then launches the UnrealGameSync.exe that’s in program files rather than the UnrealGameSync.exe that’s in LocalAppData, such that it’s running an older version of UGS.
There may be local things we need to fix, or this may be more of a general issue that’s flying under the radar due to many already using Horde instead of Perforce for UGS deployments.
What is the general state of the UGS installer and Perforce sourcing, and how should we be using these for UE 5.6?
[Attachment Removed]
Steps to Reproduce
After installing a fresh copy of UE 5.6.1, the UnrealGameSync Installer is failing, even after building the UnrealGameSync project’s Release configuration. It seems that the Installer has an old value in its Build.bat, where that file is expecting to find the UGS files in a net6.0-windows folder, while the UGS project is now targeting net8.0, with the UnrealGameSync project outputting to net8.0-windows.
I edited Build.bat to point at the net8.0-windows folder, which resulted in successfully building an UnrealGameSync.msi. I was then able to install that msi and run the resulting installed UnrealGameSync app.
[Attachment Removed]
Hi Jeff,
Thanks for raising this, we don’t use Build.bat as part of our internal workflows so it looks like this one has definitely flown under the radar.
We currently rely on the https://github.com/EpicGames/UnrealEngine/blob/release/Engine/Source/Programs/UnrealGameSync/BuildUGS.xml build graph and build the UGS installer through Horde.
I’ll get Build.bat updated to avoid any confusion.
Looking at the build graph we use Release when building the Commandline version of UGS (UnrealGameSyncCmd.csproj) and ReleaseAutoUpdate when building the GUI version (UnrealGameSync.csproj).
In both cases we are targeting x64 for the windows builds.
In terms of where the UGS install is pushed and updated from we are still submitting it to perforce internally so can verify that workflow should be working correctly.
The issue with the wrong version of UnrealGameSync being launched is likely to be one of the following:
- You have UGS configured to not check for updates (this causes the version from “C:\Program Files (x86)” to be ran)
- This can be fixed from Options => Application Settings => Update Settings or closing UGS and shift+clicking UGS from the start menu
- Ensure that you don’t have the Disable option selected in the window that pops up
- You have an old version of UGS pinned to your task bar and are using it to launch
- Unpin UGS from your task bar, launch it from the start menu and then re-pin it
Hope this helps.
[Attachment Removed]
Hi Jeff,
That looks like a nice simple change to save a lot of time and confusion.
Even internally we still hit scenarios where we find a user on a very old version due to this issue.
I’ll share this approach that you took in our next UGS developer sync, as rolling something like this into the core version of UGS sounds like a good move.
Thanks for sharing this.
[Attachment Removed]
On a related note, that Build.bat is targeting the UGS files from the “Release” rather than “ReleaseAutoUpdate” folder.
I don’t fully understand yet when the Release configuration should be used vs. the ReleaseAutoUpdate configuration, but this seems odd, that the installer would exclusively only handle the non-auto-update version of UGS. Is that intentional? What am I missing?
[Attachment Removed]
While looking into that some more, I noticed that the ReleaseAutoUpdate x64 is configured to output to use the Release configuration of UnrealGameSync and to output to the Release folder, while the ReleaseAutoUpdate Any CPU is configured to use the ReleaseAutoUpdate configuration of UnrealGameSync while outputting to the ReleaseAutoUpdate folder.
[Attachment Removed]
Thank you, that does help.
After I had posted this issue, I discovered that building UGS via build graphs on Horde dodges the output path issue related to the .NET version change by providing its own paths, which led me to a similar assumption that may be how the issue via Visual Studio publishing may have flown under Epic’s radar.
We should be all set here now, as we’ve locally adjusted the .NET path to successfully publish via Visual Studio, and we’ve also succeeded with building and publishing via the build graphs on Horde. We’re just getting fully up to speed on using those graphs and using Horde servers for building, uploading, and downloading tools like UGS, so we’ll also soon be mainly using that setup and be less reliant on publishing via Visual Studio.
Thanks for looking into this and providing helpful information, such as confirming my hunch that Epic was mainly using Horde build graphs now rather than using Visual Studio publishing lately.
[Attachment Removed]
I also thought I should drop a quick comment about that last point, as we’ve had a lot of issues caused by people at our studio pinning the running instance of UGS, then subsequently just running that exclusively. That very standard Windows behavior breaks a fundamental feature of UGS, where it will silently carry on while never again checking for an update. That’s a sneaky problem for us, which generally surfaces as some sort of sync failure down the road, when we’ve updated our project to newer UGS for example, which has some incompatibility with older UGS versions. It can take a lot of time to troubleshoot back to this bypassing of the launcher being the source of the problem, so while it’s a quick fix then each time, overall, it’s a quite large time cost for UGS support.
To that end, we eventually added a check when UGS is starting up where if it’s running from within appdata and wasn’t started by the launcher, we display the following error message and immediately close UGS, preventing our developers from being able to bypass the auto-update functionality of the UGS launcher:
[Image Removed]
[Attachment Removed]