We finaly switched to a source build of the engine and now struggeling hard to deploy it properly to the team.
We decided for the perforce approach without UnrealGameSyn, just place the engine next to the project into the same Perforce stream.
**1: Whats needs to be uploaded to the perforce server? **
Just uploading the project as downloaded from github is not enough, as the Engine/Binaries/Win64/UnrealVersionSelector.exe is missing (more about it below).
We now decided to upload everything to the server AFTER running setup.bat, that way you also get the engine/Content that can be altered and synced via perforce. That gives us already ~50gb on the server without building the binaries.
2: What do you need to send to team members and what step do you have to take to get it work? The first problem that came up was that the .uproject file stores the custom version via an unique ID. Thus just syncing the engine to a team member, does not make the project find the engine. Some registering needs to happen. I was told in Discord that I need to run the Engine/Binaries/Win64/UnrealVersionSelector.exe to register the engine so that the project can find it. I was not able to find any documentation about this important step. But that did not solve the problem entirely, as the engine now was registered, but with a different unique ID. Thus assigning the engine to the project on the artist pc, caused a different ID in the uproject file. With the next sync all builds will be broken cause of different IDs. Where is the ID stored so that it properly gets applied by every team member?
I was able to find the ID with the engine path in the registry of windows (Computer\HKEY_USERS\S-1-5-21-1718803762-1610700553-3192764085-1002\Software\Epic Games\Unreal Engine\Builds). But adding that entry manually on every team member is nuts (Edit: And even trying to do so, did not work).
I was told to seek the answer under section “Registering an installed build”: https://docs.unrealengine.com/en-US/…ild/index.html
So it really is necessary to make the registry entry, but the entry location was wrong. I wrote a batch file to add the entry.
So many people have source builds, but where is the documentation about that stuff? As of unreals documentation: Just sync and go. But obviously thats not the case.
We work from source and only check in the code from Github into our P4 Depot. You don’t really need UnrealVersionSelector, the source directory will be registered as soon as you have made the source build of the engine, users can generate their project files just by selecting it:
In our case, users on their end run the Setup.bat file and build the engine themselves (artists etc. included). Works well enough for us, everybody is required to install VS community and it’s relatively painless after that.
Yeah ok, then your setup is different. I see for sure that every team handles this stuff differently and thus it is difficult to provide documentation that fit every team. Still the engine assoziation problem is vital and described at a bad point in the docs.
How do you deal with those:
-You only have the source from github synced, thus you are in the end finally restricted to those files. What if someone needs to change something within the engine that is not checked in? It could easily be missed and thus your team is out of sync. E.g. in your case if someone changes an engine content asset, things start to break appart. Or do you have rules that only the source files of the engine is ever to be changed?
-If everyone runs the setup.bat of the engine, every team member has a different engine assoziation ID. Thus every team member has a different .uproject file. If you keep the .uproject as perforce type “locked” then every team member needs to check out the file to change the engine assoziation. Checking it in, breaks it on the other team members. Keeping the .uproject file as perforce type “writeble”, you manually need to remember to reconcile it when adding a plugin to the project (if unreal does not check the file out anyway). Checking the file back in, causes the version selector window to popup again on every team member cause they now got the engine assoziation of the team member that check the file in last.
-As every team member has to build the engine themself, I assume you have a small team. But how do you make sure the engine on the artist pc is rebuild if you change source files?
The EngineAssociation in the Uproject JSON doesn’t have to be an ID it can also be a relative path to the engine.
Setup.bat simply downloads a lot of files so if you don’t want to add all those files to perforce you could exclude them and have the individual members run it after they sync the engine and its binaries and content.
Yeah it really depends on your team. A few points in our case:
We are all working completely remotely (spread all over the world, UK, EU, US, NZ etc.)
Team is approx 16 people, 2 or which are programmers (myself being one) - the others are artists/animators/content etc.
We also have a publisher, who also needs to grab the project source and build on their end, and also integrate into their own internal build system.
Server space is not an issue for our case, we could have more in the P4 depot if we wanted to.
GIT is a literal nightmare for anybody who isn’t a programmer. P4 is super user-friendly IMO.
We essentially download the GIT repository of the engine, then add that to our perforce depot. That’s all we do.
We don’t ever make changes to binary engine content or anything downloaded via Setup.bat. We’ve never had any need to, but if you did it would make maintainence even more of a pain anyway - so it’s probably better to just move those files you need to modify into the project structure IMO.
Yep, we never check changes to the uproject file. In Perforce the file is marked as “always writeable”, so it’s treated as though it’s ignored unless we want to explicitly check it in with changes but we never really do. Plugins are typically greenlit by a programmer before being added to the project permanently, and sometimes content folks may want their own plugins that others don’t have or don’t want enabled.
To be honest, even though we are all spread around the world it’s not too difficult - we just maintain open communication and make sure everybody knows when they need to rebuild. Everybody follows a pretty strict “update from perforce then build” routine, so the team knows to build any potential changes each time. We could probably automate this process if we really wanted to with a small C# tool or a batch file, but so far we’ve not really needed to.
This has served us well so far, at least we haven’t run into any major issues with this workflow. The biggest thing for us is to not waste time, some of our team has pretty poor networking environment (especially in Aus/NZ), so downloading a complete engine build when a programmer makes a small tweak could take them offline for a whole day or more - it’s much more efficient for them to build the engine locally, while only downloading the smaller iterative changes.
When it comes to engine upgrade time, typically this is only once a year for us - so we just get the team to wipe the engine folder out and re-download everything from P4. This keeps it nice and clean.
I will also say, while we have made lots of engine changes - we haven’t done anything incredibly drastic because it just results in being a maintenance nightmare when you want to upgrade. If you have a dedicated person managing your source control it might be viable, but wherever possible we try to workaround or with the engine. Changes to the engine itself are usually a last resort.
If you do plan to make big sweeping changes, but your not making them often - then perhaps just distributing a binary build to your artists is better for you. I have seen that done before, but it tends to work better when everybody is working under the same roof and it doesn’t put them out of action for half a day.
@GarnerP57 Thanks, good to know. Again, docs don’t cover that.
@TheJamsh Yeah, I see. If you have people with low performance networks, building on their own is definitely best. Unfortunately, in our case the artist fears every button. Letting him open VS would make him freeze in place. Only option would be a automation script, as you said. Thanks for your thoughts.