Config Injection during Unreal Engine 4 Builds

Bryan Corell
Disruptive Games
Published in
3 min readJan 29, 2020

Hello all, this article will talk briefly about an Unreal Engine 4 custom build option for overriding configuration INI values in a packaged build. We created and used this option effectively in our recent game, Megalith.

To start, our build process for the title in Unreal 4 revolves around the very common model of triggering build processes with the Unreal Build Tool (UBT) and all its accompanies facilities. These all tend to be bootstrapped by calls to a batch file living in their source tree //Engine/Build/BatchFiles/RunUAT.bat.

Because we run our own dedicated servers in order to try to provide the best user experience (and side stepping some of the nastier issues such as compromised clients and host migration), we developed a relatively simple batch file that would do all the work we needed to kick off client and server builds with the appropriate settings.

In order to allow each developer to test in their own sandbox, we needed different builds to be able to hit different dedicated servers and server pools; these values are built into parts of our ini file in a format like so:

[OnlineSubsystemMegalith]
BuildId=678
BuildTime=SomeTime
MegalithMatchConfig=some_context_string

This is all well and simple for a development environment, but we needed these values to be modified for the build, and we certainly want to reduce the amount of human involvement in the build process as much as possible.

So, of course, we started by attempting to leverage the existing (yet obscure) command line parameter format to override ini values.

-ini:<ConfigFile>:[<ConfigSection>]:SectionKey=SectionValue

Much to our dismay, while these overrides will affect the active build, RunUAT does NOT propagate the options all the way through. The package files would still have the values unmodified and the parameters would only be passed through to the various build processes, not affecting the configuration that gets cooked.

Hmm okay. So, how do we modify config files that get to the builds?

2 things:

  1. Leave the repo in a clean state (no tracked file modifications)
  2. Save these bits as part of the data that is output for pak / packaging.

We need both of these things in order to reduce pain to humans and to ensure we have all the build artifacts we want to save off in long term storage.

The solution that presented itself is to latch into the CopyBuildToStaging portion of package creation. We generate a duplicate version of the ini that then is saved into the staging directory instead of the original from //Game/Config/... . This allows us to meet both our goals, we can have saved content from the cook and not modify our versioned files.

So, there are certainly some intricacies here, but I’ll let the repo do the talking. We latch into a newly created project parameters check and propagate that information into the C# scripts in the Automation project to deploy to the Staging area.

Basically this allows you do invocations on the RunUAT.bat BuildCookRun’s and as long as you stage, it will trigger as well.

RunUAT.bat BuildCookRun blah blah blah -SaveConfigOverrides -ini:[OnlineSubsystemMegalith]:MegalithMatchConfig=Megalith_QA_Config

This would allow you to override the match configuration value string to any other arbitrary data. We haven’t tested this with more complex overrides such as arrays, or structures but it should work all the same.

Repo Link!

(NOTE: You must have a GitHub account that has been authorized to access UE4 GitHub to see content)

Happy building!

Bryan @ Disruptive Games, Inc.

--

--

Bryan Corell
Disruptive Games

Engineering Director at Disruptive Games. Perf, optimization, new technologies, network services and gameplay. Backend game services and architecture.