Are there guidelines of implementing in-house engine versioning when building Unreal Engine from source with local customizations?
The user stories are:
- I’ve made a new version of the engine and want designers to optionally upgrade to it.
- I’ve made a new version of the engine and want designers to be forced to upgrade to it.
- I want to use git commit hash in the engine version identifier.
- I want a game module DLL to contain the engine version that it requires to run.
As far as I could see, all this has already been implemented for internal usage in Epic. UAT supports this. Instead of making our own system on top, we could use what is already there. But it’s hard to build a big picture and figure out where to inject custom engine versions.
I’ve found these places of interest:
- UAT can produce it, but what for?
- This seems like a good place to refer to
- UAT can update it
- But which fields can we update and in which way?
- This has very little to do with ObjectVersion.h
- Contains another definition of ENGINE_VERSION that can potentially conflict with Version.h
- Used to identify compatible engine versions in a network scenario
- Which fields can we update and in which way?
This is a term that is used in many places throughout the code. It looks close to what we need. We are licensees, after all
How to specify this, and what’s the benefit of using it, compared to modifying Version.h?
If we want to use a string version (git commit), should we forget about using the “licensee version” concept?
Engine Association in .uproject
- Another place to stuff a version string to. Convenient, but accessible only by the VersionSelector tool.
Apologies for dumping my potentially inaccurate findings here. The question itself is short: what do we need to do to implement custom versioning?
While I’m looking for the best way to do this as well, I can give you some insight:
ObjectVersion.h is used to version your data formats. As you can see Epic adds a new enum each time they change the format, so that serialization code can handle each version differently. You can look for checks against Ar.UE4Ver() in the code how that’s made.
To avoid conflicts with Epic’s versioning when you change the serialization of your own data, you use the VER_LIC_ enums instead, and check the corresponding property Ar.LicenseeUE4Ver() when serializing.
So, the data serialization is related to the editor version, but it’s not the same thing. You would expect the Version.h to change whenever ObjectVersion.h changes, but the reverse is not required.
Version.h would be the place to modify, as far as I can tell. Set ENGINE_IS_LICENSEE_VERSION to 1, change the branch name to whatever suits you, and check that into your own repo. The binary build comes with BUILT_FROM_CHANGELIST set to the actual Perforce change list of the build, so I assume this is something Epic modifies at build time, but never checks into the depot.
The UnrealVersionSelector maps a GUID to an Engine folder. There’s no way, that I can see, to get it to use the actual version of your local build, it will always generate a GUID if the folder has not been registered before. You can, however, modify the registry (PC) or Install.ini-file (Mac), replacing the GUID with the version specifier of your liking, but everyone on your team has to manually set this up, and the first one will have to re-save the .uproject file with the new reference name.
In UE4Build.cs UpdateVersionFiles(…) will perform the Version.h update, but requires Perforce, and that it’s running on a build machine, so there’s where you’ll want to make your changes, I believe.
I was looking for the same quection, and the UpdateVersionFiles is what I want!
Runuat -UpdateLocalVersion -cl= -Licensee