Feature Request: detecting the engine root honours the .uproject's EngineAssociation

[TBBle]

I've just accidentally failed to cause a rebuild when I would have expected to need one, because I switched my .uproject's EngineAssociation from my local git checkout (UUID) to a installer packaged-build ("4.24"), and then did a ue4 build without thinking about it.

This is because setroot, as documented, is the authority on what UE4 installation to use for ue4cli.

I suspect this would have caused issues later if I hadn't noticed it, because compilation triggered in the editor or a generated project would have honoured the .uproject file's EngineAssociation.

I'd much prefer to not set the engineroot, and have my .u4project file parsed to get the correct root, rather than the current _detectEngineRoot behaviour of "latest installed version in the default install directory".

I know on Windows this should all be feasible via the registry, as UnrealVersionSelector must be doing that, but I don't know how it works on other platforms.

It would also be nice if in-tree Engine (i.e. next to the project) projects would work correctly out-of-the-box.

I understand that the logic in UBT will ignore an EngineAssociation value in a .uproject if the Engine directory is sitting next to the project, but haven't tested it myself, I just saw it mentioned on the Unreal forums once when talking about getting the Server binaries into the Installer Packaged Builds.

[adamrehn]

This would certainly be a useful feature to have, but I'm not entirely confident that it would be possible to achieve feature parity across Windows, macOS and Linux. I'll have to have a look into the logic in UnrealVersionSelector and see how viable this is for non-Windows platforms.

[Mik-pe]

I know this is a somewhat stale issue (and I see you are drowning in work Adam), but some code that could be used for windows builds is something along the lines of:

try:
	base_query = 'SOFTWARE\\EpicGames\\Unreal Engine'
	key = winreg.OpenKey(winreg.HKEY_LOCAL_MACHINE, base_query)
	if key:
		(num_keys, _, _) = winreg.QueryInfoKey(key)
		if num_keys > 0:
			# Assume highest key is the highest version (with multiple engines installed)
			version_string = winreg.EnumKey(key, num_keys - 1)
			sub_query = base_query + '\\' + version_string
			sub_key = winreg.OpenKey(winreg.HKEY_LOCAL_MACHINE, sub_query)
			(newestVersionDir, valType) = winreg.QueryValueEx(sub_key, 'InstalledDirectory')
			if valType == winreg.REG_SZ:
				return str(newestVersionDir)
except:
	pass

in _detectEngineRoot for UnrealManagerWindows.
Querying this registry key with the version from the .uproject-file instead of taking the highest version (as done in my code) could be of use.

This should also improve finding UE roots when installed elsewhere than to C:/Program Files/, since the regkey isn't connected to paths.

[TBBle]

My understanding of the issue was for non-Windows platforms. It's possible Linux doesn't even have the concept of an Installed Build registry because there's no EGS or Binary distribution. And on Mac OS, presumably that info is somewhere inside the installer's library/config, since I don't think there's anything like 'The Windows Registry' on Mac OS?

[slonopotamus]

Linux doesn't even have the concept of an Installed Build registry

It has: ~/.config/Epic/UnrealEngine/Install.ini

[sleeptightAnsiC]

That's something that shouldn't be hard to implement but there are few separate problems here:

1. Associating project with engine installation:

   • .uproject file stores EngineAssociation key
   • per this documentation page installation keys are stored as follows:
     • Linux - File ~/.config/Epic/UnrealEngine/Install.ini (thanks slonopotamus)
     • Mac - File - ~Library/Application Support/Epic/UnrealEngine/Install.ini
     • Windows - Registry - Computer\HKEY_CURRENT_USER\SOFTWARE\Epic Games\Unreal Engine\Builds
   • parsing keys from files should be easy
   • parsing keys from registry won't be so easy, but Mik-pe already proposed some code

2. Which version should be prioritized?

   • Version from .uproject probably should take priority for anything that expects project in current working directory, like gen/build/run...
   • ...but would this make sense for user who just used ue4 setroot ?
   • There are generally multiple cases where this can be very unintuitive

3. Automatic version swapping is a general problem
   I think that ue4cli should force you to specify which version to use when there are multiple versions installed.
   It should also warn you when using different version than the one set in .uproject or maybe not allow it at all.

[TBBle]

At least for 2, my feeling is that I'd prefer ue4 setroot <path_or_version> to be an override option, and if I haven't used it (or call ue4 clearroot), then it honours the .uproject, barfing if it points to a not-installed version.

However, inside a container, e.g., ue4-docker, I expect there's only only engine version installed, and selection of the container is implicitly ue4 setroot <path_or_version>; it'd be nice if this didn't have to be explicit in the container build, but that's honestly not an awful option, since the container image build script installing ue4cli knows the path to the engine it built, I expect. But being able to say something like ue4 forceroot (but a better name) to force the use of the only known engine instance, i.e. overriding the "barf" in my first paragraph with a "choose one from a list of one". (I assume but haven't checked that a ue4-docker engine is registered in the registry/files as part of its build/startup process.)

I also used <path_or_version> deliberately, because a side-effect of this work means ue4cli is aware of installed image versions, and hence ue4cli 5.2 becomes a trivial extension, with the caveat that in a pathological directly layout, you might need ue4cli ./5.2 where currently ue4cli 5.2 works today. (This also means that if you happen to have them written down, you can reference custom/local engine builds by UUID. And that suggests ue4cli listroots might be a useful utility function to add too.)

---

I disagree on 3, simply because the trivial case for non-container usage of ue4cli should match the trivial case of "Right click on the ue4project file", which honours with .uproject version with no other setup needed, even if multiple engine versions are installed. Doing otherwise feels like too much friction in what I expect to be common in the non-container use-case.

I do like the idea of being able to override the engine for individual ue4cli commands though as a global flag. I like it more when you can just pass in a version, not a full path. Honestly, that'd probably have removed the use of ue4 setroot for me entirely on the second-last project I worked on, when building test-plugin packages for multiple versions. (Which to be fair, was a while ago now.)

This becomes even more useful if we duplicate the logic that finds a project-adjacent Engine directory and uses that instead of what's in the .uproject file.

---

Anyway, my underlying principle here is that ue4cli should feel like a native CLI interface that works like the other tools provided in the UE4 editor GUI or otherwise, consuming the same configuration and state etc. I raised this issue because I got caught-out in a place (the one place?) where it doesn't do that.

[sleeptightAnsiC]

Yea, that makes sense @TBBle , I'm just thinking how to implement it from the code side.

Current implementation searches for common installation directories, it isn't aware of Install.ini files nor the registry.
To be honest, I'm not sure why this functionality isn't already there. Perhaps, older UE version weren't using it.

This is totally doable. It will require some code changes but in my opinion it would be a great feature!

Anyway, I'll propose a fix after the response on #58 , since it would touch the same code.

[TBBle]

I would guess that this wasn't done earlier because ue4 setroot has been good enough for everyone (including me, as I never implemented this idea either), and possibly because the installed build version data wasn't well-supported outside Windows way back when ue4cli was created.

It was and is a feature request, requiring new code.