Files
UnrealEngineUWP/Engine/Source/Developer/Virtualization/Private/VirtualizationSourceControlBackend.h

199 lines
9.8 KiB
C
Raw Permalink Normal View History

// Copyright Epic Games, Inc. All Rights Reserved.
#pragma once
#include "IVirtualizationBackend.h"
#include "Containers/StringView.h"
class ISourceControlProvider;
namespace UE::Virtualization
{
class FSemaphore;
/**
* This backend can be used to access payloads stored in source control.
* The backend doesn't 'check out' a payload file but instead will just download the payload as
* a binary blob.
* It is assumed that the files are stored with the same path convention as the file system
* backend, found in Utils::PayloadIdToPath.
* ----------------------------------------------------------------------------
*
* Ini file setup:
* 'Name'=(Type=P4SourceControl)
* Where 'Name' is the backend name in the hierarchy
*
* Required Values:
*
Now if the VA source control backend fails to connect we can display a dialog to the user asking for the correct credentials directly. Currently disabled by default. #rb none ### Dialog - When the source control backend tries to connect and fails we will now show a dialog allowing the user to try new settings rather than let the editor continue and crash. - The dialog will allow the user to enter the server address (P4PORT) and their username (P4USER). - Once the dialog is displayed the user will have three options to continue. -- "Reset To Defaults" which will remove all settings saved to the users local ini files and attempt to use the environment defaults to connect. -- "Retry Connection" which will take the new address and username that the user provided and attempt to connect with those settings. -- "Skip" no connection attempt will be made. This may cause instability later if the user needs data that they cannot access. - If the connection succeeds after the user has reset to defaults or provided new settings, then they will be saved in the local ini file for future sessions. - The dialog will not show if: -- Slate is disabled for the current processor has not yet initialized -- The error is found not on the game thread. This means that lazy init will not currently work well with this dialog. Attempts to mashal the error to the game thread have been spotty at best and there is a high chance of thread locking so attempts were abandoned. -- If the -unattended flag is set on the process. -- If the dialog is disabled via the config file when setting up the backend (UseRetryConnectionDialog=False) -- If 'engine.ini:[Core.VirtualizationModule]:UseLocalIniFileSettings' is false as future sessions would not be able to use the new settings and would become tiresome. In these cases the environment settings will need to be fixed. - If the dialog is now shown then the backend is marked as unconnected and will not work. ### Known Issues - We currently cannot get the settings that the failed p4 connection used, nor the error message dueto how the API works. So for now we just display an empty server address and username edit box. This will be fixed when the API is changed. - There is currently no good way to inform the user where their settings come from. - There is no easy way to reset the settings once saved. To allow the user to change the server address to a better proxy for example. ### Initialization - In order to allow a slate dialog to be used, the initialization of the VA system has been moved later in pre init, to the first avaliable point after slate has initialized and its shaders have been built. This in theory should not cause a a problem as engine content cannot be virtualized. -- Added a new option 'engine.ini:[Core.ContentVirtualization]:InitPreSlate' with a default of false. When set to true the VA system will initialize in the original, earlier portion of engine pre init. This is only included in case an existing virtualized project encounters a problem with the new ordering. [CL 26115392 by paul chipchase in ue5-main branch]
2023-06-20 04:26:06 -04:00
* DepotPath [string] The path (in depot format) to the location where virtualized payloads are stored.
* [Default=""]
* ClientStream [string]: Used when the payloads are stored in a stream based depot. It should contain
* the stream name to use when creating a workspace for payload submission. [Default=""]
*
* If the payloads are being stored in a depot with type 'stream' them config value 'ClientStream' must be set to a valid
* stream. The 'DepotPath' value can still be set to choose a specific location within that stream or when the stream
* name is not a valid depot path (such as virtual streams)
*
* If the payloads are not being stored in a 'stream' depot then only 'DepotPath' is required.
*
* Optional Values:
*
Now if the VA source control backend fails to connect we can display a dialog to the user asking for the correct credentials directly. Currently disabled by default. #rb none ### Dialog - When the source control backend tries to connect and fails we will now show a dialog allowing the user to try new settings rather than let the editor continue and crash. - The dialog will allow the user to enter the server address (P4PORT) and their username (P4USER). - Once the dialog is displayed the user will have three options to continue. -- "Reset To Defaults" which will remove all settings saved to the users local ini files and attempt to use the environment defaults to connect. -- "Retry Connection" which will take the new address and username that the user provided and attempt to connect with those settings. -- "Skip" no connection attempt will be made. This may cause instability later if the user needs data that they cannot access. - If the connection succeeds after the user has reset to defaults or provided new settings, then they will be saved in the local ini file for future sessions. - The dialog will not show if: -- Slate is disabled for the current processor has not yet initialized -- The error is found not on the game thread. This means that lazy init will not currently work well with this dialog. Attempts to mashal the error to the game thread have been spotty at best and there is a high chance of thread locking so attempts were abandoned. -- If the -unattended flag is set on the process. -- If the dialog is disabled via the config file when setting up the backend (UseRetryConnectionDialog=False) -- If 'engine.ini:[Core.VirtualizationModule]:UseLocalIniFileSettings' is false as future sessions would not be able to use the new settings and would become tiresome. In these cases the environment settings will need to be fixed. - If the dialog is now shown then the backend is marked as unconnected and will not work. ### Known Issues - We currently cannot get the settings that the failed p4 connection used, nor the error message dueto how the API works. So for now we just display an empty server address and username edit box. This will be fixed when the API is changed. - There is currently no good way to inform the user where their settings come from. - There is no easy way to reset the settings once saved. To allow the user to change the server address to a better proxy for example. ### Initialization - In order to allow a slate dialog to be used, the initialization of the VA system has been moved later in pre init, to the first avaliable point after slate has initialized and its shaders have been built. This in theory should not cause a a problem as engine content cannot be virtualized. -- Added a new option 'engine.ini:[Core.ContentVirtualization]:InitPreSlate' with a default of false. When set to true the VA system will initialize in the original, earlier portion of engine pre init. This is only included in case an existing virtualized project encounters a problem with the new ordering. [CL 26115392 by paul chipchase in ue5-main branch]
2023-06-20 04:26:06 -04:00
* Server [string]: When set the backend will use this server address to connect to. When not
* set the backend will use the environment defaults. [Default=""]
* UsePartitionedClient [bool]: When true the temporary workspace client created to submit payloads
* from will be created as a partitioned workspace which is less overhead
* on the source control server. If your server does not support this then
* use false. [Default=True]
* WorkingDir [string]: Sets the temp location on disk where payloads are submitted from. The path can
* contain config file expansions (see ConfigCacheIni.cpp ::MatchExpansions) and
* environment variables with the format $(EnvVarName).
* [Default="%GAMESAVEDDIR%/VASubmission"]
* RetryCount [int32]: How many times we should try to download a payload before giving up with
* an error. Useful when the connection is unreliable but does not experience
* frequent persistent outages. [Default=2]
* RetryWaitTime [int32]: The length of time the process should wait between each download attempt
* in milliseconds. Remember that the max length of time that the process
* can stall attempting to download a payload file is
* RetryCount * RetryWaitTime; [Default=100ms]
* MaxConnections [int32] The maximum number of perforce connections that can be made concurrently.
* If this value is exceeded then additional requests will wait until a
* connection becomes free. Pass in '-1' to disable this feature and allow
* unlimited connections. [Default=8]
* BatchCount [int32] The max number of payloads that can be pushed to source control in a
* single submit. If the number of payloads in a request batch exceeds
* this size then it will be split into multiple smaller batches. [Default=100]
* SuppressNotifications[bool]: When true the system will not display a pop up notification when a
* connection error occurs, allowing the user to stay unaware of the error
* unless it actually causes some sort of problem. [Default=false]
* UseLocalIniFileSettings[bool] When true the revision control provider will be allowed to load connection
* settings from the users locally saved 'SourceControlSettings.ini' file, if
* false then the settings in this file (if any) will be ignored. [Default=true]
* IgnoreFile [string]: Sets the name of the p4 ignore file to use. When submitting payloads we
* create a custom p4 ignore file to override any ignore settings for a project
* which allows us to submit from the saved directory which is normally prevented
* by the default ignore file. This value should be set to the value of P4IGNORE
used by your environment. [Default=".p4ignore.txt"]
Now if the VA source control backend fails to connect we can display a dialog to the user asking for the correct credentials directly. Currently disabled by default. #rb none ### Dialog - When the source control backend tries to connect and fails we will now show a dialog allowing the user to try new settings rather than let the editor continue and crash. - The dialog will allow the user to enter the server address (P4PORT) and their username (P4USER). - Once the dialog is displayed the user will have three options to continue. -- "Reset To Defaults" which will remove all settings saved to the users local ini files and attempt to use the environment defaults to connect. -- "Retry Connection" which will take the new address and username that the user provided and attempt to connect with those settings. -- "Skip" no connection attempt will be made. This may cause instability later if the user needs data that they cannot access. - If the connection succeeds after the user has reset to defaults or provided new settings, then they will be saved in the local ini file for future sessions. - The dialog will not show if: -- Slate is disabled for the current processor has not yet initialized -- The error is found not on the game thread. This means that lazy init will not currently work well with this dialog. Attempts to mashal the error to the game thread have been spotty at best and there is a high chance of thread locking so attempts were abandoned. -- If the -unattended flag is set on the process. -- If the dialog is disabled via the config file when setting up the backend (UseRetryConnectionDialog=False) -- If 'engine.ini:[Core.VirtualizationModule]:UseLocalIniFileSettings' is false as future sessions would not be able to use the new settings and would become tiresome. In these cases the environment settings will need to be fixed. - If the dialog is now shown then the backend is marked as unconnected and will not work. ### Known Issues - We currently cannot get the settings that the failed p4 connection used, nor the error message dueto how the API works. So for now we just display an empty server address and username edit box. This will be fixed when the API is changed. - There is currently no good way to inform the user where their settings come from. - There is no easy way to reset the settings once saved. To allow the user to change the server address to a better proxy for example. ### Initialization - In order to allow a slate dialog to be used, the initialization of the VA system has been moved later in pre init, to the first avaliable point after slate has initialized and its shaders have been built. This in theory should not cause a a problem as engine content cannot be virtualized. -- Added a new option 'engine.ini:[Core.ContentVirtualization]:InitPreSlate' with a default of false. When set to true the VA system will initialize in the original, earlier portion of engine pre init. This is only included in case an existing virtualized project encounters a problem with the new ordering. [CL 26115392 by paul chipchase in ue5-main branch]
2023-06-20 04:26:06 -04:00
* UseRetryConnectionDialog[bool] When true a slate dialog will be shown if the initial connection to the
* source control server fails allowing the user to attempt to input the correct
* login values. [Default=false]
Improved the code logic for where we submit virtualized payloads from and added some additional options. #rb PJ.Kack #jira UE-142926 #preflight 621e1f177f2803279b575764 - Now when payloads are submitted, we will submit them from within the project's saved directory (by default) this now works because we write a .p4ignore file to the submission directory which will override any additional ignore file higher up in the directory structure. -- A new utility function ::CreateSubmissionSessionDirectory was added to make sure that the directory we are submitting from has a p4ignore file. It is added in it's own scope as it is assumed that additional functionality will be added here later. - If a user wishes to choose a different location to submit from, they can override the environment variable "UE-VirtualizationWorkingDir" to provide a different location. This might be useful if the user does not have a huge amount of spare space on the disk that the project is running from. - There is also an optional entry to the ini file set up 'SubmitFromTempDir' (false by default) which when set to true will cause the system to attempt to submit the payload files from the machines temp directory instead. -- There isn't an easy way for users to override this locally, which reduces the usefulness of the option. This might be worth improving in the future although that time would be better spent removing the need for the directory in the first place. - We now try to find/create the root directory to submit payloads from when the backend is created. Failure at this point is not expected and will prevent the backend from working and so is considered an error. - Added more logging to track the session guid when submitting and to be clear about where the files are being submitted from. [CL 19197367 by paul chipchase in ue5-main branch]
2022-03-01 09:05:41 -05:00
*
* Environment Variables:
* UE-VirtualizationWorkingDir [string]: This can be set to a valid directory path that the backend
* should use as the root location to submit payloads from.
* If the users machine has this set then 'SubmitFromTempDir'
* will be ignored.
* ----------------------------------------------------------------------------
*
* Perforce Storage Setup:
*
* Once you have decided where in perforce you want to store the virtualized payloads you will need to submit
* a dummy file to the root of that location named "payload_metainfo.txt" preferably with a short message describing
* the storage locations purpose.
* When initialized this backend will first attempt to find and download this dummy file as a way of validating that
* a) the process can correctly connect to perforce
* b) the process has the correct location setup in the config file.
* This validation not only allows us to alert the user to misconfiguration issues before they need to access the data
* but allows us to prevent users from accidentally pushing virtualized payloads to the wrong location.
*
* So for example, if the virtualized payloads are to be stored under '//payloads/project/...' then the backend would
* expect to find a '//payloads/project/payload_metainfo.txt' file that it would download via a p4 print command.
*
* If this file is not found then the backend will log an error the first time that it attempts to connect and will prevent
* the user from pulling or pushing payloads until the issue is resolved.
* ----------------------------------------------------------------------------
*
* Perforce Settings Setup:
The source control settings for the VA source control connection are no longer saved to a local ini file. #rb Per.Larsson #jira UE-163834 #rnx #preflight 632d98e4b4515b7e221654ec ### Virtualization - At the moment there is no way in the editor UX to change the source control settings for the source control backend, so what ever settings are found in the global environment would be applied when the editor is first run and then saved to a config file under the <saved> directory. From this point onwards those settings would always be used when setting up the source control backend. If the settings were wrong, the first time that the editor was started, then we'd continue to use the incorrect settings even if the global enviroment was fixed. Making the backend work at that point would require that the user know about the local ini file and change the settings there. - We cannot fix this by just ignoring the ini file as it has been requested that users can add their settings there in case they want to customize things, so we just need to avoid saving to it. - Added documentation to the source control backends header file on how to set up the ini file if needed. ### Perforce - FSourceControlInitSettings now accepts EConfigBehavior which describes how we want the source control provider to deal with its settings with regards to the ini file. - Note that EConfigBehavior is not a bitfield as we do not wish to support only writing to the ini file, there is no point if it cannot be read from. - When the source control provider is creatred we pass on the into from EConfigBehavior to the FPerforceSourceControlSettings to enable/disable saving and loading. [CL 22163769 by paul chipchase in ue5-main branch]
2022-09-23 20:05:59 -04:00
*
* The backend will attempt to use the current global environment settings for perforce to determine
* the P4PORT and P4USER values. If you wish to set them via an ini file then they can be done per
* user by adding the following to Saved\Config\<platform>Editor\SourceControlSettings.ini
*
* -----
* [PerforceSourceControl.VirtualizationSettings]
* Port=<server address>
* UserName=<username>
* -----
* Note that the backend will read from these ini file settings but will not write to them.
*/
class FSourceControlBackend final : public IVirtualizationBackend
{
public:
explicit FSourceControlBackend(FStringView ProjectName, FStringView ConfigName, FStringView InDebugName);
virtual ~FSourceControlBackend() = default;
private:
/* IVirtualizationBackend implementation */
virtual bool Initialize(const FString& ConfigEntry) override;
Add a number of ways for the VA backend connections to be changed to lazy initialize on first use. #rb Devin.Doucette #jira UE-161599 #rnx #preflight 6303c8d65a5d4e4624e7bf52 - There are some use cases that require the VA system to be initialized and configured correctly but would prefer that the backend connections only run if absolutely needed (usually when a payload is pulled or pushed for the first time), this change provides four different ways of doing this: -- Setting [Core.VirtualizationModule]LazyInitConnections=true in the Engine ini file -- Setting the define 'UE_VIRTUALIZATION_CONNECTION_LAZY_INIT' to 1 in a programs .target.cs -- Running with the commandline option -VA-LazyInitConnections -- Setting the cvar 'VA.LazyInitConnections' to 1 (only works if it is set before the VA system is initialized, changing it mid editor via the console does nothing) --- Note that after the config file, each setting there only opts into lazy initializing the connections, setting the cvar to 0 for example will not prevent the cmdline from opting in etc. - In the future we will allow the connection code to run async, so the latency can be hidden behind the editor loading, but for the current use case we are taking the minimal approach. -- This means we only support the backend being in 3 states. No connection has been made yet, the connection is broken and the connection is working. -- To keep things simple we only record if we have attempted to connect the backends or not. We don't check individual backends nor do we try to reconnect failed ones etc. This is all scheduled for a future work item. - If the connections are not initialized when the VA system is, we wait until the first time someone calls one of the virtualization methods that will actually use a connection: Push/Pull/Query -- We try connecting all of the backends at once, even if they won't be used in the call to keep things simple. - Only the source control backend makes use of the connection system. The horde storage (http) backend could take advantage too, but it is currently unused and most likely going to just be deleted so there seemed little point updating it. - If we try to run an operation on an unconnected backend we only log to verbose. This is to maintain existing behaviour where a failed backend would not be mounted at all. This logging will likely be revisited in a future work item. [CL 21511855 by paul chipchase in ue5-main branch]
2022-08-23 13:01:15 -04:00
virtual EConnectionStatus OnConnect() override;
IVirtualizationBackend::EConnectionStatus OnConnectInternal(FString& InOutPort, FString& InOutUsername, bool bSaveConnectionSettings, FText& OutErrorMessage);
virtual bool PushData(TArrayView<FPushRequest> Requests, EPushFlags Flags) override;
virtual bool PullData(TArrayView<FPullRequest> Requests, EPullFlags Flags, FText& OutErrors) override;
virtual bool DoesPayloadExist(const FIoHash& Id) override;
virtual bool DoPayloadsExist(TArrayView<const FIoHash> PayloadIds, TArray<bool>& OutResults) override;
private:
bool TryApplySettingsFromConfigFiles(const FString& ConfigEntry);
void CreateDepotPath(const FIoHash& PayloadId, FStringBuilderBase& OutPath);
Improved the code logic for where we submit virtualized payloads from and added some additional options. #rb PJ.Kack #jira UE-142926 #preflight 621e1f177f2803279b575764 - Now when payloads are submitted, we will submit them from within the project's saved directory (by default) this now works because we write a .p4ignore file to the submission directory which will override any additional ignore file higher up in the directory structure. -- A new utility function ::CreateSubmissionSessionDirectory was added to make sure that the directory we are submitting from has a p4ignore file. It is added in it's own scope as it is assumed that additional functionality will be added here later. - If a user wishes to choose a different location to submit from, they can override the environment variable "UE-VirtualizationWorkingDir" to provide a different location. This might be useful if the user does not have a huge amount of spare space on the disk that the project is running from. - There is also an optional entry to the ini file set up 'SubmitFromTempDir' (false by default) which when set to true will cause the system to attempt to submit the payload files from the machines temp directory instead. -- There isn't an easy way for users to override this locally, which reduces the usefulness of the option. This might be worth improving in the future although that time would be better spent removing the need for the directory in the first place. - We now try to find/create the root directory to submit payloads from when the backend is created. Failure at this point is not expected and will prevent the backend from working and so is considered an error. - Added more logging to track the session guid when submitting and to be clear about where the files are being submitted from. [CL 19197367 by paul chipchase in ue5-main branch]
2022-03-01 09:05:41 -05:00
bool FindSubmissionWorkingDir(const FString& ConfigEntry);
Give improved error messages to the user if the source control asset virtualization backend fails to connect. #rb PJ.Kack #jira UE-136612 #rnx #preflight 61e589b7904123989a1817cc - If a perforce connection issue is encountered when starting up the editor we will now print an error to the message log and then on the first tick of the editor display a notification to get the users attention. It will no longer result in a fatal error. - Add a new category "Asset Virtualization" to the message log so that we can start to improve the feedback we give to end users rather than only reporting problems via UE_LOG. This also introduces a new localization text name space. -- I will need to go over a lot of the virtualization modules error handling and move it to use the message log instead. - When the source control backend first starts up we now specifically check if the connection works and if not try to give the user feedback on how to fix it. -- Ideally we'd provide a login dialog for the user to fix the problem in place but due to how early in the start up process we need to be able to access the virtualization backends this is quite tricky. - In the future we will build the concept of a backends connection into a formalized concept in the system along with better error handling. At this point FSourceControlBackend::OnConnectionError should be moved to general use for all backends. this will allow us to provide much better status info to the user. #ROBOMERGE-AUTHOR: paul.chipchase #ROBOMERGE-SOURCE: CL 18637036 in //UE5/Release-5.0/... via CL 18637043 via CL 18637054 #ROBOMERGE-BOT: UE5 (Release-Engine-Test -> Main) (v899-18417669) [CL 18637614 by paul chipchase in ue5-main branch]
2022-01-18 04:50:38 -05:00
/** Will display a FMessage notification to the user on the next valid engine tick to try and keep them aware of connection failures */
void OnConnectionError(FText ErrorMessage);
/** A source control connection owned by the backend*/
TUniquePtr<ISourceControlProvider> SCCProvider;
/** The name of the current project */
FString ProjectName;
/** The path (in depot format) to where the virtualized payloads are stored in source control */
FString DepotPathRoot;
/** Address of the server to connect to */
FString ServerAddress;
/** The stream containing the DepotRoot where the virtualized payloads are stored in source control */
FString ClientStream;
Improved the code logic for where we submit virtualized payloads from and added some additional options. #rb PJ.Kack #jira UE-142926 #preflight 621e1f177f2803279b575764 - Now when payloads are submitted, we will submit them from within the project's saved directory (by default) this now works because we write a .p4ignore file to the submission directory which will override any additional ignore file higher up in the directory structure. -- A new utility function ::CreateSubmissionSessionDirectory was added to make sure that the directory we are submitting from has a p4ignore file. It is added in it's own scope as it is assumed that additional functionality will be added here later. - If a user wishes to choose a different location to submit from, they can override the environment variable "UE-VirtualizationWorkingDir" to provide a different location. This might be useful if the user does not have a huge amount of spare space on the disk that the project is running from. - There is also an optional entry to the ini file set up 'SubmitFromTempDir' (false by default) which when set to true will cause the system to attempt to submit the payload files from the machines temp directory instead. -- There isn't an easy way for users to override this locally, which reduces the usefulness of the option. This might be worth improving in the future although that time would be better spent removing the need for the directory in the first place. - We now try to find/create the root directory to submit payloads from when the backend is created. Failure at this point is not expected and will prevent the backend from working and so is considered an error. - Added more logging to track the session guid when submitting and to be clear about where the files are being submitted from. [CL 19197367 by paul chipchase in ue5-main branch]
2022-03-01 09:05:41 -05:00
/** The root directory from which payloads are submitted. */
FString SubmissionRootDir;
/** The name to use for the p4 ignore file */
FString IgnoreFileName = TEXT(".p4ignore.txt");
/** Should we try to make the temp client partitioned or not? */
bool bUsePartitionedClient = true;
/** When true, the backend will not raise a pop up notification on connection error */
bool bSuppressNotifications = false;
/** The maximum number of files to send in a single source control operation */
int32 MaxBatchCount = 100;
/** A counted semaphore that will limit the number of concurrent connections that we can make */
TUniquePtr<UE::Virtualization::FSemaphore> ConcurrentConnectionLimit;
/** The number of times to retry pulling a payload from the depot */
int32 RetryCount = 2;
/** The length of time (in milliseconds) to wait after each pull attempt before retrying. */
int32 RetryWaitTimeMS = 100;
/** When true we allow the revision control provider to read settings from the users local SourceControlSettings.ini file */
bool bUseLocalIniFileSettings = true;
Now if the VA source control backend fails to connect we can display a dialog to the user asking for the correct credentials directly. Currently disabled by default. #rb none ### Dialog - When the source control backend tries to connect and fails we will now show a dialog allowing the user to try new settings rather than let the editor continue and crash. - The dialog will allow the user to enter the server address (P4PORT) and their username (P4USER). - Once the dialog is displayed the user will have three options to continue. -- "Reset To Defaults" which will remove all settings saved to the users local ini files and attempt to use the environment defaults to connect. -- "Retry Connection" which will take the new address and username that the user provided and attempt to connect with those settings. -- "Skip" no connection attempt will be made. This may cause instability later if the user needs data that they cannot access. - If the connection succeeds after the user has reset to defaults or provided new settings, then they will be saved in the local ini file for future sessions. - The dialog will not show if: -- Slate is disabled for the current processor has not yet initialized -- The error is found not on the game thread. This means that lazy init will not currently work well with this dialog. Attempts to mashal the error to the game thread have been spotty at best and there is a high chance of thread locking so attempts were abandoned. -- If the -unattended flag is set on the process. -- If the dialog is disabled via the config file when setting up the backend (UseRetryConnectionDialog=False) -- If 'engine.ini:[Core.VirtualizationModule]:UseLocalIniFileSettings' is false as future sessions would not be able to use the new settings and would become tiresome. In these cases the environment settings will need to be fixed. - If the dialog is now shown then the backend is marked as unconnected and will not work. ### Known Issues - We currently cannot get the settings that the failed p4 connection used, nor the error message dueto how the API works. So for now we just display an empty server address and username edit box. This will be fixed when the API is changed. - There is currently no good way to inform the user where their settings come from. - There is no easy way to reset the settings once saved. To allow the user to change the server address to a better proxy for example. ### Initialization - In order to allow a slate dialog to be used, the initialization of the VA system has been moved later in pre init, to the first avaliable point after slate has initialized and its shaders have been built. This in theory should not cause a a problem as engine content cannot be virtualized. -- Added a new option 'engine.ini:[Core.ContentVirtualization]:InitPreSlate' with a default of false. When set to true the VA system will initialize in the original, earlier portion of engine pre init. This is only included in case an existing virtualized project encounters a problem with the new ordering. [CL 26115392 by paul chipchase in ue5-main branch]
2023-06-20 04:26:06 -04:00
/* When true, if the initial connection to the revision control provider fails we will show a slate dialog (if possible) to the user prompting for correct settings */
bool bUseRetryConnectionDialog = false;
};
} // namespace UE::Virtualization