We are finding that many clients and internal teams modify UGS. We also have many people that need to move between projects as freely as possible.
Ideally we want to be able to run multiple installations of UGS on the same machine. There are two details that stop this working out of the box.
1. The Perforce Depot Path for UGS binaries is stored in a Registry Key that is referenced by all installations if set.
2. When the UGS binaries are downloaded from the Depot Path it is to a fixed single place in AppData for all installations.
Quite often when UGS is modified by clients or internally one or both of these are modified (anecdotally the Registry Key part is the most common change we’ve seen).
To work around this we have to clear the registry keys and reinstall UGS when switching projects, or hope that the current installed version of UGS is compatible. This is causing issues and complaints especially for less technical team members that can switch between different projects, sometimes multiple times a day.
As a potential solution:
1. Downloading UGS to a path related to the Depot Path (possibly with the server address as well) in AppData so it isn’t fixed for all installations.
2. Instead of using the registry, save the settings in a file in that directory.
We’ve seen a few ad hoc partial implementations of either of these in various projects but any use vanilla UGS can interfere and they can break each other. It would be very helpful to have this as standard UGS functionality.
Hi.
Sorry for the delay. I assume all the projects are using a shared version of the engine workspace? Because when you have several P4 workspaces, you can have several projects in UGS. That’s how I maintain all my UE releases for support purpose because I have to constantly jump between versions, but I have a copy for each engine and I deal with about 8GB of disk, so I have to delete some intermediate files time to times. So if your projects are all in the same source tree and you are sharing most of the code locally, this doesn’t work. The other approach that was suggested by the UGS owner can be found here: [Content removed] but it is similar
[Image Removed]So, I’m unsure how you are setup and how you share code between projects. If you don’t share anything between project, then it should work, I can investigate with you why it would not for you. Otherwise, let me know, I’ll create the feature request.
Regards,
Patrick
Hi Patrick,
I have been asked to reply on Scott’s behalf, apologies for the lateness.
No these projects are often not using a shared Engine workspace. It is common for these to be projects to be for entirely different clients with publisher mandated separate Perforce installations. We do use the above UGS tabs when appropriate though and like the feature.
Changing between projects is proving to be error prone for many team members. Ideally we would like to be able to have multiple installs of UGS to exist concurrently. This is not possible due to the issues mentioned in the first post.
We are finding that a lot of our developers like using UGS and so do the vast majority of our clients so this is a fairly common issue.
If you would like more details of the situation please let us know.
Regards,
Daniel
Hi,
Sorry, I misunderstood the issue. Your issue is because the games you are working on have customized UGS changes and you cannot just use the latest UGS version to rule them all. I entered a feature request under UE-343517 with the suggestions you made but I expect the feature to be backlogged for a foreseeable future. We don’t have any developer currently assigned to UGS and this is for a less common use case.
Regards,
Patrick
Thanks for logging the feature request Patrick. On commonality of use case (and conscious that you have internal priorities), I have spoken to other multi-partner development service providers and they’re also experiencing this. Hopefully it will make its way up the backlog 
.
Best regards,
Scott.