Our users were having issues accessing virtualized assets. We eventually realized it was trying to connect to an entirely different Perforce server. Some users had system-wide settings via p4 set and others had invalide .p4config.txt files in their projects. Is there any way to force the in-Editor system to use the Editor source control? Or do we need to implement some studio-wide system to make sure the right server is used for each Workspace? A side issue is that the UGS feature to create a p4config file automatically does not seem to do anything at all.
Steps to Reproduce
Connect to a project with virtualized assets using Editor source control.
Attempt to open / load assets.
Observe that Virtualization system does not use Editor source control settings, and cannot connect.
Create a .p4config.txt file in the project root.
Reload the Editor and observe that the Virtualization system uses the settings in .p4config.txt.
> Is there any way to force the in-Editor system to use the Editor source control?
At the moment there is no option to do this.
We’ve got this backlogged as a feature request (UE-212178), and would like to make it an opt-in option someday. Unfortunately there is currently no estimate on this as features work on VA is currently low priority.
There’s multiple reasons why the Editor settings are not strictly coupled with the VA settings currentl:
- Not all users are logged into revision control but might still need to connect to Virtualization.
- Not all teams/projects use the same server for their content as they do for their virtualized payloads, so we cannot make an assumption for them here.
One option to make these failures more noticeable is to enable the RetryConnection Dialog like so in your Virtualization configuration:
SourceControlCache=(Type=P4SourceControl, ..., UseRetryConnectionDialog=true)It will try to display the settings it used at the point of failure and ask the user to provide a new set of settings. However, since this will add extra entries to your config it increases the likelihood of having local overrides that differ from your company-wide setup, so it might not be a good option if you want to make sure you can centrally control those values from a single place.
This can be a bit confusing for users so you can set this in your Engine.ini to provide a url (wiki page on your local intranet, etc) that the user can click on to get more info if you want to try and reduce the support cost:
[Core.VirtualizationModule]
ConnectionHelpUrl=""
If your company only uses a single P4PORT (no edge servers or proxies) you can also set this as part of the .ini file setup and force it that way:
SourceControlCache=(Type=P4SourceControl, ..., Server="correct-url.net:1666", UseRetryConnectionDialog=true)
> A side issue is that the UGS feature to create a p4config file automatically does not seem to do anything at all.
There’s a lot details and variations in how the perforce settings can be provided, so there’s a chance this is due to your local configuration.
One possible option is that there’s already a wrong P4PORT saved in <project root>\Saved\Config\WindowsEditor\SourceControlSettings.ini under the
[PerforceSourceControl.Virtualization]
section where
[PerforceSourceControl.PerforceSourceControlSettings] is the editor settings.
We did some changes to the code to only save that value if it was manually entered via the retry dialog so it shouldn’t have saved unless it was saved under a much older UE version previously.
Other potential reaons depend on on the location of your .p4config.txt file.
Due to legacy weirdness we look for that file relative to the editor .exe directory, not the project directory.
If you have your project folder external to the engine folder then we might not pick up any .p4config.txt files inside the project (since it would search relative to the Editor executable.
If that’s the case you could try running “p4 set” in the editor .exe directory to see the values Unreal tries to use and where they come from.
Let me know if this helps!
Kind Regards,
Sebastian
We’re glad it helped! Just to confirm - You’re all set for now? If so, I’ll close out this ticket. Thanks!
Thanks, Sebastian - this does help. I ended up modifying UGS so that the “write P4 config file” option is an application-level setting and each project’s config is overwritten every time the tab loads. Our bulk data payloads are currently in the same p4 server under a different depot to simplify access. I will need to come up with another solution for users who do not use UGS, so I might implement that wiki help page suggestion.
Yes we are good for now. Thank you!