#ROBOMERGE-AUTHOR: mic.rooney
#ROBOMERGE-SOURCE: CL 19377824 via CL 19378971 via CL 19393378 via CL 19393515
#ROBOMERGE-BOT: UE5 (Release-Engine-Staging -> Main) (v926-19321884)
[CL 19402337 by mic rooney in ue5-main branch]
#rb Sebastian.Nordgren
#rnx
#preflight 62309ccae65a7e65d686d1dc
#robomerge FNNC
- The behaviour for the settings for the default provider (that takes it's settings from the command line) should be OverrideExisting not OverrideAll to maintain the original behaviour. This was a mistake due to misreading the original code. As it was, setting one setting via the command line would clear any previously set or saved settings.
- When parsing the cmdline we used the form "KeyName=" as the key, as FParse::Value does not strip the = automatically, but when we were looking up the values to override settings we were just using "KeyName" which would not match. The lambda ::ParseCmdLineSetting now adds = to any key passed in when parsing, so there is no longer a need for the caller to add it. This helps the keys match and work correctly.
[CL 19386795 by paul chipchase in ue5-main branch]
#rb Patrick.Laflamme
#jira UE-145721
#rnx
#preflight 622f0358752729a2ad448e16
- The problem we have is if a p4 depot path is used when requesting filestates (to see if the file exists in p4 for example) it will be treated as a networkpath due to it starting with // so calling the filesystem to check if it is a directory or not can get very expensive.
- Other operations just check the end of the path for '/' or '\' which is what this operation used to do, but that was changed at some point to check the file system, presumably to fix another problem and as we don't really know how 3rd party code is using this system we cannot just change the behavior without risking breaking existing code bases.
- This fix allows the caller to opt in to the old behavior of just checking the end of the path to determine if it is a directory or not.
- This fix is not very good, future work for a better fix will be tracked in the attached jira.
[CL 19371141 by paul chipchase in ue5-main branch]
#preflight 622a9696df3960e506b23304
#ROBOMERGE-AUTHOR: rex.hill
#ROBOMERGE-SOURCE: CL 19344805 via CL 19346510 via CL 19352303 via CL 19353002 via CL 19355785
#ROBOMERGE-BOT: UE5 (Release-Engine-Staging -> Main) (v926-19321884)
[CL 19357749 by rex hill in ue5-main branch]
#rnx
#preflight skip
#ROBOMERGE-AUTHOR: rex.hill
#ROBOMERGE-SOURCE: CL 19341879 via CL 19343585 via CL 19346308 via CL 19351236 via CL 19351297
#ROBOMERGE-BOT: UE5 (Release-Engine-Staging -> Main) (v926-19321884)
[CL 19351899 by rex hill in ue5-main branch]
#preflight skip
#rb bart.hawthorne
[FYI] jamie.dale
#ROBOMERGE-AUTHOR: rex.hill
#ROBOMERGE-SOURCE: CL 19341691 via CL 19343577 via CL 19346300 via CL 19351233 via CL 19351291
#ROBOMERGE-BOT: UE5 (Release-Engine-Staging -> Main) (v926-19321884)
[CL 19351897 by rex hill in ue5-main branch]
These are important (and trivial) enough to warrant direct support.
#rb charles.bloom
#preflight 622a5db9df3960e506a9f135
[CL 19340792 by fabian giesen in ue5-main branch]
Use TArray/TArray64 instead of raw allocs for our storage, there's no reason not to.
(The only reason the original code did raw allocs was because it was adapted from C code.)
Read from/write to memory not FArchive by request.
FDDSHeader->FDDSHeaderWithMagic, we don't care about the old-school DDSURFACEDESC,
we only ever have magic then ddsd so just make it part of the header struct.
Make mip sizes int64; a 16k * 16k R32G32B32A32_FLOAT image is enough to overflow 4GB.
#rb charles.bloom
#preflight 622914ee0d5a90e98eccf49d
[CL 19325619 by fabian giesen in ue5-main branch]
#rb Luc.Eygasier, Sebastien.Lussier
#rnx
#preflight 622895d331133a23da78a4ca
### Misc
- FPerforceSourceControlRevision, FPerforceConnection and FPerforceSourceControlLabel now own a reference to their FPerforceSourceControlProvider and accesses the connection settings from that rather than via the module singleton.
- FPerforceSourceControlCommand now accesses the connection settings by finding the FPerforceSourceControlProvider that the given IPerforceSourceControlWorker references.
- FPerforceSourceControlProvider now owns it's own FPerforceSourceControlSettings rather than accessing a shared one owned by the module.
- Marked a number of derived classes as final.
### FPerforceConnection
- ::EnsureValidConnection can now work without a valid client (although most commands will require a client to run, things like p4 print does not).
-- Due to this change we might not catch cases where the the system cannot connect to source control as the user is not logged in as this would get caught when we checked the workspace by calling ::TestConnection.
-- To get around this ::EnsureValidConnection will now call "p4 login -s" via the newly added TestLoginConnection.
- Renamed ::TestConnection to ::TestClientConnection as we are really testing the connection to the specified workspace.
- There does seem to be some inconsistency in the logging, depending how a perforce source control provider first creates its connection as in some cases FPerforceConnection::EnsureValidConnection gets called first and in other cases FPerforceConnection::EstablishConnection is called. We should unify these paths but this change list is already so large I am opting to postpone this to it's own work item.
### FPerforceSourceControlModule
- Removed all of the singleton style accessors so that classes inside of the module can no longer assume that there is only one FPerforceSourceControlProvider. Updated the documentation to match.
- Since there is no reason for classes in the module to need to access FPerforceSourceControlModule, ::Get has been removed
- The responsibility to register all of the worker creation delegates has been moved to IPerforceSourceControlWorker so that all source control providers can share them.
- ::GetProvider has been removed, if a class inside the module needs access to a provider then a reference to it's provider will be given to it at construction time.
- ::SetLastError, ::AccessSettings and ::SaveSettings are now called directly on FPerforceSourceControlSettings
### FPerforceSourceControlSettings
- This class now takes the name of the system that owns it as a parameter in the constructor
-- The name will be used to identify where to store the settings in the config file, unless the name is blank in which case the pre-existing default location will be used.
- This will allow for multiple source control providers to store their connection info.
### SPerforceSourceControlSettings
- Moved FGetWorkspaces from SPerforceSourceControlSettings.h to its own header file to reduce the number of places that need to include the slate headers.
- Move the fwd declares to the top of the header base don recent coding standards discussions.
- Instead of accessing the source control provider via FPerforceSourceControlModule the dialog is now given a pointer to one when constructed.
-- This pointer is assumed to always be valid and should be a reference if the slate system supported it.
### PerforceSourceControlOperations
- IPerforceSourceControlWorker now takes a reference to the owning FPerforceSourceControlProvider in it's constructor. All derived workers have been updated to this.
- Moved the registering of worker creation delegates from the module cpp to a new static method IPerforceSourceControlWorker::RegisterWorkers
-- This should make it easier to find when adding a new worker and allows source control providers to share the same map of delegates rather than duplicating it.
-- This means we also need a new static method IPerforceSourceControlWorker::CreateWorker for instantiating new workers based on the given name.
### FSourceControlInitSettings
- This is a new class that is used to set up a newly created source control provider.
- The settings are expected to be given in the same way you would override settings via the cmdline. The existing perforce cmdline code has been updated to use this class.
- This still has the downside that the calling code needs to know the type of source control provider, but I don't really see a good way around this unless we refactor the entire API to be feature based.
[CL 19318801 by paul chipchase in ue5-main branch]
to use Final EncodeSpeed on a texture instead of Fast when editing changes
so you can see the project's Final RDO settings while working on a texture
#preflight 6227c776671c913c052a82fb
#rb dan.thompson
[CL 19311911 by charles bloom in ue5-main branch]
Put DDS parameter validation in one function (Validate) that is shared between Create, Read, Write funcs.
Add support for saving D3D9-format DDS files, either automatically when doing so is "lossless" in "Auto" mode, or in a D3D9-only mode that tries hard to express data as a D3D9 file and will fail when it can't find a suitable mapping. Still default to writing as D3D10-format DDS since that tends to preserve semantics the best.
The pixel format tables for D3D9-format DDS files were reordered slightly to make us prefer "canonical" choices when writing D3D9 DDS files, e.g. we prefer BC2 textures to get writtten as DXT3 not DXT2, and likewise BC3 should prefer DXT5 over DXT4.
#rb Charles.Bloom
#preflight 62267996123eef55e6fa32d6
[CL 19292462 by fabian giesen in ue5-main branch]
#jira UE-145000
#jira UE-144997
#jira UE-144996
#fyi dominik.peacock
#rb none
#preflight 6226586b06521a56d5db23ba
[CL 19290027 by jason walter in ue5-main branch]
- 14.1s to 7.6s when loading CitySample Small_City_LVL -ddc=cold
#rb Charles.Bloom, Fabian.Giesen
#preflight 6225f3a7b97fb949cf3412a2
[CL 19284116 by danny couture in ue5-main branch]
