This can happen if you've configured multiple things to probe the same health checks (or the system doing health checks simply overlaps two of them as can happen in kubernetes)
#preflight none
[CL 21482569 by Joakim Lindqvist in ue5-main branch]
Some strategies, such as the one for auto-scaling compute tasks need to be much more reactive.
#preflight 63036f7ca45b007ea23bad98
[CL 21481960 by carl bystrom in ue5-main branch]
Also changed to run analyzers during build. When referencing this library from a project that does run analyzers, it failed.
Likely is for the better to enforce that here as well.
#preflight none
[CL 21481937 by carl bystrom in ue5-main branch]
#rb Per.Larsson
#jira UE-161296
#rnx
#preflight 62fe3ce73d3fb466b229bcc0
- There are some usecases that require the VA system to initialize the first time it is accessed (usually the first time we attempt to pull a virtualized payload) rather than be initialized in the program start up. This change provides three different methods to achieve this:
-- Setting the define 'UE_VIRTUALIZATION_SYSTEM_LAZY_INIT' to 1 in a programs .target.cs
-- Setting [Core.ContentVirtualization]LazyInit=true in the Engine ini file
-- Running with the commandline option -VA-LazyInit
- If we detect that the source control backend is being initialized on a background thread we do not try to run the FConnect operation. The backend will still work but this does reduce the potential error checking on initialization. This is done because the FConnect operation currently only works on the main thread and to change this would be a bigger work item than we can schedule at the moment.
- UE::Virtualization::Initialize functions now take a EInitializationFlags enum as a parameter. This enum allows the call to ignore all lazy init settings and force the initialization immediately. This is useful for programs like the Virtualization standalone tool which just needs to start the system when needed.
-- The call to ::Initialize in LaunchEngineLoop passes in None and does not ignore lazy initialization.
-- Calls to ::Initialize in the UnrealVirtualizationTool however all use EInitializationFlags::ForceInitialize and ignore lazy initialization settings.
- Fixed an odd bug in UE::Virtualization::Initialize where the error path (if the config file cannot be found) was using a different start up code path.
- Add asserts when assigning to GVirtualizationSystem to make sure that it is null. This is not 100% safe but should catch some potential threading issues, if any.
- Add an assert after lazy initialization (IVirtualizationSystem::Get) to make sure that GVirtualizationSystem was assigned a valid object.
- Improve how we check for legacy values in [Core.ContentVirtualization]. We now support multiple allowed values.
- Added a way to poll if a VA system has been initialize yet or not, this allows us to avoid initializing a VA system if one has not yet been created and we try to:
-- Dump VA profiling stats after cooking
-- Send VA stats to studio analytics
- Note that currently using lazy init loading will probably cause the VA statistics panel not to work, this will be fixed in future work where we will allow the panel to register for a callback when the system is initialized.
[CL 21467510 by paul chipchase in ue5-main branch]
Remove special case handling of engine plugins in UHT for ObjectPtr behavior.
#rb none
#preflight 62ffc2690f7187ef8112f23f
[CL 21466661 by Zousar Shaker in ue5-main branch]
#fyi Zousar.Shaker
Original CL Desc
-----------------------------------------------------------------
Remove special case handling of engine plugins in UHT for ObjectPtr behavior.
#rb none
#preflight 62ffc2690f7187ef8112f23f
[CL 21461028 by Zousar Shaker in ue5-main branch]
