The build system supports many types of flags that can be enabled in game-specific Target.cs files to enable things like logging in shipping, target-specific overrides like custom config, or enabling plugins for a certain release version. These features depend on having a unique build environment, but in an installed/Rocket version of the engine it will always use the Shared build environment for monolithic builds (so it can reuse the intermediate binaries we ship). This issue is also why you cannot package Test versions or dedicated servers using an installed build. This restriction exists in both launcher-downloaded versions of the engine as well as custom licensee-built installer versions.
Newer samples like Lyra heavily take advantage of these features to support creating a modular game that can be configured at target creation time. These features need to be disabled or hacked around to work with installed builds. Also the warning messages for these features tend to say things like "use a monolithic build" when the tool is already trying to create a monolithic build so it is confusing to end users
It makes sense for a blueprint-only game to use the shared monolithic environment, but there needs to be some way for a C++ game to opt in to requiring a unique build environment when creating monolithic builds. Packaging C++ games already requires a working compiler so it could recompile the engine binaries at the same time. Trying to reuse the intermediate binaries in packaged builds is not worth the complication because monolithic versions of a game are much faster to compile than the entire editor is.
LyraGameEOS will package fine from a custom version of the engine, but can not work with installed versions which the warning explains
There's no existing public thread on this issue, so head over to Questions & Answers just mention UE-145482 in the post.
2 |
Component | UE - Foundation - Build - Rocket (Installed Engine) |
---|---|
Affects Versions | 5.0 |
Created | Mar 10, 2022 |
---|---|
Updated | Mar 8, 2023 |