Our team is all using the source version of UE4 right now, and we have one engineer responsible for downloading the latest source from GitHub and copying it up to our local repository to ensure that we’re all on the same source version.
All of us have put our UE4 source in a “UE4” subfolder right inside the project folder.
In order to associate UE4 with that source, we right-click the .uproject file and “Select Unreal Engine Version.” Unfortunately, this seems to create a unique GUID for the EngineAssociation inside the .uproject file:
What to do? This seems like it will make it impossible for us to share the .uproject file as a single, shared file in our own source repository. Why doesn’t “EngineAssociation” just store a relative path instead?
This will be fixed properly in the upcoming 4.2 release: we’ve changed it so it won’t need to write out that engine association string if it can find the engine in a parent directory from your project.
In the meantime, the way we handle this at Epic is to include multiple game projects in a single solution with the engine. You can set this up by creating a text file with the .uprojectdirs extension in your engine root (the same directory as GenerateProjectFiles.bat) which has a list of relative paths to search for game folders. Just add a line that reads:
Then copy your game folder alongside the Engine folder and run GenerateProjectFiles.bat. The solution that’s generated in the root directory should have both the engine and game project in it (plus any other games you add in there).
It won’t work with the .uproject shell extensions (yet), but it should allow you to share the same .uproject files in Git.
Allowing the use of environment variables in value fields would solve the problem too:
Actually, if you want to go for a global solution, it might be easier to just manually add the registry entry for the engine installation. The map of assigned GUIDs to directory is stored at:
HKEY_CURRENT_USER/Software/Epic Games/Unreal Engine/Builds
The GUIDs are just generated randomly each time a new installation directory is found. If you want to force it to always use a certain GUID for a certain directory, you can manually add it here.
Did this get resolved for 4.2 and I’m just missing it? I’m testing 4.3 now and it still doesn’t seem to be. We’re starting to get some more people on board and It’s tripping them up.
We decided to embrace the .uprojectdirs workflow that I mentioned in my original post, and made it so that workflow is completely compatible with the EngineAssociation scheme. This system works well for all of the games we’re developing at Epic, so it seemed like an easier jump to get the shell integration working with that. To recap, set your directory structure up like this:
/SomeFolder/Engine - from GitHub
/SomeFolder/MyGameFolder - containing your .uproject file
/SomeFolder/UE4.uprojectdirs - text file containing the line: ./
The .uprojectdirs file just gives a list of directories to search for game folders in, which lets you revision-control the engine and game into the same repository.
Actually I have 1 more question about this.
Does it work on any relative path?
It should be a relative path underneath the directory containing the .uprojectdirs file. It won’t work correctly if it’s a relative path outside that.
Cool, we’ll have to restructure our depot a little then.
Our setup was.
The goal here being that we wanted to be able to have the engine releases available. I assume then that you always branch the engine and the game together?
Exactly, yes. We would put the game inside /SomeFolder/UnrealEngine/4.2/MyGameFolder (or not include the version number at all, and just upgrade the engine in-place).
Could I bump this thread w/ a follow-up question? I’m on 4.4, trying to get a source-built engine to play well with P4 and other users. So we are bumping into the issue of the engine GUID is unique for every user, etc.
Is the .uprojectdirs approach expected to work for the workflow of a developer double-clicking the .uproject file to open the editor?
It seems like the codepaths related to .uprojectdirs don’t get hit via UnrealVersionSelector. The places I found were:
- FUProjectDictionary::FUProjectDictionary(const FString& InRootDir)
- FEngineLoop::PreInit( const TCHAR* CmdLine )
But when I run UnrealVersionSelector in the debugger with commandline params /editor .uproject, breakpoints in these functions don’t get hit.
Am I missing a piece of the puzzle, or is there another approach for enabling multi-users/source-built/source-controlled projects? This is admittedly a small issue, users can launch the editor and open the project, but just curious if there was something I was missing.
Yes, the workflow you describe should work.
UnrealVersionSelector uses the GetEngineRootDirForProject() function to determine the engine root. Your .uproject file should have an empty EngineAssociation string, which will trigger FDesktopPlatformBase::GetEngineIdentifierForProject() to scan up the directory hierarchy looking for the engine.
How is your directory structure laid out?
Thanks Ben! Our .uproject still had the EngineAssociation in there. =) I didn’t realize that the directory-walk happened only after the EngineAssociation-Registry lookup fails.
Once I cleared out the EngineAssociation, all is well!
I tried to set all the things up, but utterly failed. Can you sum up all the steps again and what should happen in 4.9.0?
Put your project folder inside Unreal Engine folder. Delet *.sln, *.suo files in your projects folder. Run GenerateProjectFiles.bat. Thats’ all.
We use git for project files, and I added project as a submodule to our UE fork.
And what place have the bp projects in this, because they don´t have any solution files?
Could you elaborate on exactly what you’re running into? Are you trying to setup a source build of the engine for use by a team? Please detail what you’re trying to do and what results you’re getting to help us understand your issue.