Never store the return of ANSI_TO_TCHAR, as it goes out of scope
#jira none
#rb none
[FYI] Pj.Kack
#ROBOMERGE-AUTHOR: brandon.schaefer
#ROBOMERGE-SOURCE: CL 17713301 in //UE5/Main/...
#ROBOMERGE-BOT: STARSHIP (Main -> Release-Engine-Test) (v879-17706426)
[CL 17713386 by brandon schaefer in ue5-release-engine-test branch]
#rb Francis Hurteau
[FYI] Andriy.Tylychko
#ushell-cherrypick of 17692611 by Andriy.Tylychko
- I also disabled "System.Core.Containers.TSTicker" as it was exceeding the memory of some platforms as well
#ROBOMERGE-AUTHOR: paul.chipchase
#ROBOMERGE-SOURCE: CL 17709761 via CL 17709762 via CL 17709766 via CL 17709769 via CL 17709783
#ROBOMERGE-BOT: STARSHIP (Release-Engine-Staging -> Release-Engine-Test) (v879-17706426)
#ROBOMERGE[STARSHIP]: UE5-Main
[CL 17709789 by paul chipchase in ue5-release-engine-test branch]
#rb CarlMagnus.Nordin
#jira none
#rnx
#preflight 6156eabd7b2a62000169d451
### Current Changes
- By storing the location of the toc in the package file summary we can access the toc by reading the summary and then jumping to it. It should also be possible for external scripts to be able to do this as well.
- We currently store the identifier, the offset into the package file and the uncompressed size of payload, which will be stored in FCompressedBuffer format.
-- We don't need all this info right now but it means that the structure will be compatible with the experimental sidecar feature. It would also (hypothetically) allow us to move the offset/size info from the bulkdata objects themselves and simply rely on the toc, in which case the loading from within the package file or a sidecar file will be the same.
- When saving a package's exports we will gather a reference to each virtualized bulkdata serialized. The toc should appear before the payloads in the file but we do not know the correct info for the toc until after the payloads have been appended to the package file. So we need to write out a dummy toc that will reserve the space in the file and then after we have appended the payloads, seek back in the file and write out the correct info.
### Future Work
- Although this CL does have a number of code changes to allow this to work with text based assets there are some problems with how that format is currently saved which will prevent it from working (and currently prevents VBD from working with it as well). This will be fixed as a separate issue.
- The experimental sidecar feature uses FTocEntry but serializes a TArray to disk. This should be updated to use FPayloadToc in a later submit.
#ROBOMERGE-AUTHOR: paul.chipchase
#ROBOMERGE-SOURCE: CL 17690578 in //UE5/Main/...
#ROBOMERGE-BOT: STARSHIP (Main -> Release-Engine-Test) (v875-17642767)
#ROBOMERGE[STARSHIP]: UE5-Release-Engine-Staging Release-5.0
[CL 17690585 by paul chipchase in ue5-release-engine-test branch]
To opt in, please define the UE_VALIDATE_FORMAT_STRINGS macro to 1
#rb steve.robb
#ROBOMERGE-AUTHOR: stefan.boberg
#ROBOMERGE-SOURCE: CL 17689137 in //UE5/Main/...
#ROBOMERGE-BOT: STARSHIP (Main -> Release-Engine-Test) (v875-17642767)
[CL 17689153 by stefan boberg in ue5-release-engine-test branch]
* Strip names that are not used when cooking for UPS
* Strip names that are not used by the loader when staging for IoStore
#preflight 615424b7f4d2a4000107be68, 615450a875fae600010d4820
#rb pj.kack, francis.hurteau
#ROBOMERGE-AUTHOR: carlmagnus.nordin
#ROBOMERGE-SOURCE: CL 17674004 in //UE5/Release-5.0/... via CL 17674013
#ROBOMERGE-BOT: STARSHIP (Release-Engine-Staging -> Release-Engine-Test) (v875-17642767)
#ROBOMERGE[STARSHIP]: UE5-Main
[CL 17674014 by carlmagnus nordin in ue5-release-engine-test branch]
Intended for writing unit, integration, functional and all types of tests.
#jira UEENGQA-49764
#rb Jerome.Delattre
#ROBOMERGE-AUTHOR: chris.constantinescu
#ROBOMERGE-SOURCE: CL 17666358 in //UE5/Main/...
#ROBOMERGE-BOT: STARSHIP (Main -> Release-Engine-Test) (v875-17642767)
[CL 17666384 by chris constantinescu in ue5-release-engine-test branch]
#rb Danny Couture
#rnx
### Problem
- The crash would occur when the texture being since contains a reference to another texture (via composite) which is also in need of syncing on the users machine.
- After the files on disk have been updated the current packages are reloaded but the original version of the texture will still be in memory when the composite texture notifies that it has been reloaded causing a texture compilation job with the older now invalid texture.
-- VirtualizedBulkData relied on out of date packages not trying to access their payloads on disk once the file has been changed, but with the above scenario it was possible. There could also be other paths causing this (even if the access of out of date package payloads at this point is a waste of time)
### Fix
- The virtualized bulkdata objects now reference themselves with the FLinkerLoader if the payload is on disk, just as the old bulkdata system did. When file changing operations are invoked, the FLinkerLoader will inform it's referenced bulkdata to load the payloads off disk and hold them in memory.
-- Note that virtualized bulkdata was trying to avoid this memory bloat by design, but if we cannot be certain that the bulkdata will not try to access the payload after the file changes (as was thought) then we must take the payload into memory.
- Added a log message to VBD if we detect that the loaded payload does not match the VBD members expectations. This log message can either be an error or a fatal error depending on the define 'VBD_CORRUPTED_PAYLOAD_IS_FATAL' (defaulted to on)
- The registration to FLinkerLoader can be easily disabled by setting the define 'VBD_ALLOW_LINKERLOADER_ATTACHMENT' to 0
### Outstanding Issues
- Cloned bulkdata objects (via assignment) do not currently register themselves to the FLinkerLoader (the old bulkdata system did not) if we were to add this then we need to make sure that the FLinkerLoader registration is thread safe. This should be done as a separate work item so that we can unblock the current workflows that this changelist addresses.
-- Note that if we did not update cloned bulkdata to work with this system then we could drop the registration and just iterate over the package's bulkdata and force them to load into memory when required. However that would leave the cloned virtual bulkdata in an uncertain state and is not desirable.
- When saving a package, the virtualized bulkdata objects that it contains will change their members so that future payload access can come from the newly saved files, where as the old bulkdata system would force the payload to remain in memory for the rest of the editor session. If we want to keep this then we will need to try and make sure that the newly updated bulkdata can be registered so that it receives future notifications about the file being changed.
#ROBOMERGE-AUTHOR: paul.chipchase
#ROBOMERGE-SOURCE: CL 17648118 via CL 17648147 via CL 17648161 via CL 17648163 via CL 17648175
#ROBOMERGE-BOT: STARSHIP (Release-Engine-Staging -> Release-Engine-Test) (v875-17642767)
#ROBOMERGE[STARSHIP]: UE5-Main
[CL 17648184 by paul chipchase in ue5-release-engine-test branch]
In C++20, a class that defines (or deletes) any constructor may not be aggregate-initialized.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1008r1.pdf
This change allows FCoreTextsSingleton to perform aggregate-like initialization of FCoreTexts FCoreTextsSingleton::Texts.
#jira none
#trivial
#rb Andriy.Tylychko
#ROBOMERGE-AUTHOR: jonathan.adamczewski
#ROBOMERGE-SOURCE: CL 17648071 in //UE5/Main/...
#ROBOMERGE-BOT: STARSHIP (Main -> Release-Engine-Test) (v875-17642767)
[CL 17648086 by jonathan adamczewski in ue5-release-engine-test branch]
* Decouple container concept from IoDispatcher
* Decoiuple PackageStore implementation from AsyncLoading2
* Restore ucas unmount fix that got kist when merrging from UE4
* Fix packages being left in the PackageStiore even after unmounting contaiiners
#rnx
#rb pj.kack, per.larsson
#preflight 61520cc52afc2d0001146ce7
#ROBOMERGE-AUTHOR: carlmagnus.nordin
#ROBOMERGE-SOURCE: CL 17641845 in //UE5/Main/...
#ROBOMERGE-BOT: STARSHIP (Main -> Release-Engine-Test) (v874-17637634)
[CL 17642353 by carlmagnus nordin in ue5-release-engine-test branch]
