Overview:
- An "override flag" is an inline toggle-style Boolean edit condition. These are implicitly set to true at runtime within the output struct value if any member that's bound to it is exposed as a visible input pin on a MakeStruct node.
- For context, the Property Editor implicitly sets an override flag to true at edit time when a member that's bound to it is enabled for editing. These members are not otherwise labeled/exposed for direct editing.
- An override flag is meant to signal to a system that the user wishes to use the bound member's value in place of the current value (whatever that may be) when the full struct value is applied. Examples: FPostProcessSettings, FMovieSceneSequencePlaybackSettings, etc.
Previous UX:
- All boolean edit conditions were being treated as override flags on a MakeStruct node.
- Any inline toggle edit condition that did not begin with "bOverride_" or whose suffix otherwise did not match another value member could be exposed as an input on a MakeStruct node.
- Override flags exposed as inputs would always be set to TRUE at runtime regardless of input if it was declared at the top of the struct and if a member value bound to it was also exposed as an input pin.
After this change:
- Only inline toggle edit conditions and legacy struct members that follow the "bOverride_" naming convention will be treated as an override flag on a MakeStruct node.
- Inline toggle edit conditions can no longer be exposed directly as an input on a MakeStruct node. The intent was to bring the MakeStruct node UX closer to parity with the Property Editor UX.
Additional notes:
- Members that follow the legacy "bOverride_" naming convention were already being excluded from the optional input pin set on MakeStruct nodes if another member property name also matched its suffix. These have historically been excluded from ALL optional pin sets that utilize any FOptionalPinManager subtype (regardless of node type), so there was no change here.
- Existing MakeStruct nodes that may have already exposed inline toggle edit condition members as input pins will now orphan those pins on load if connected or if set to a non-default value (true). The "correct" way to set an override flag is by choosing to expose a member that's bound to the override condition as an input.
- Existing BreakStruct nodes are unchanged currently. Meaning, inline edit conditions that don't follow the legacy "bOverride_" convention can still be optionally exposed as an output pin. This UX was preserved as existing Blueprint logic could conceivably rely on the value of an override flag.
- Only one implicit assignment is now emitted for each override flag binding. Previously, we were emitting one assignment statement per bound property, so it could result in redundant assignments to the same flag if more than one property was bound to it.
#jira UE-147873
#rb Ben.Zeigler, Sebastian.Nordgren
#preflight 632c7353c7791417aa87f3bf
[CL 22164359 by phillip kavan in ue5-main branch]
#preflight 61eefc77ba69a4fdb220bf23
#ROBOMERGE-AUTHOR: marc.audy
#ROBOMERGE-SOURCE: CL 18712765 in //UE5/Release-5.0/... via CL 18712784 via CL 18713147
#ROBOMERGE-BOT: UE5 (Release-Engine-Test -> Main) (v903-18687472)
[CL 18713191 by marc audy in ue5-main branch]
This represents UE4/Main @18073326, Release-5.0 @18081140 and Dev-PerfTest @18045971
[CL 18081471 by aurel cordonnier in ue5-release-engine-test branch]
This represents UE4/Main @17911760, Release-5.0 @17915875 and Dev-PerfTest @17914035
[CL 17918595 by aurel cordonnier in ue5-release-engine-test branch]
#rb CarlMagnus.Nordin
#rnx
#tests Ran overnight preflights on several platforms, opened/cooked/staged/ran the oldest version of InfiltratorDemo that can be downloaded (4.11)
### ObjectVersion
- Add a new version enum EUnrealEngineObjectUE5Version.
-- This version number starts at 1000 which leaves more than enough for for EUnrealEngineObjectUEVersion to be expanded
- Even though very few changes (if any at all) to EUnrealEngineObjectUE4Version are expected there is a static assert to make sure that EUnrealEngineObjectUEVersion::AUTOMATIC_VERSION never overtakes EUnrealEngineObjectUE5Version::INITIAL_VERSION.
- Add a struct FPackageFileVersion that wraps around the version numbers and is used to store them instead of raw int32 values which was done before. This should make it easier to add new version numbers in the future if we desire (although this will cause problems in places that serialize the struct directly)
### FPackageFileSummary
- Adding a new entry to CurrentLegacyFileVersion at value -8 which shows the UE5 version being added. This lets us make the changes without needing to submit anything to UE4 Main.
- When loading a package that does not have a UE5 version, it will remain at 0.
- Added ::IsFileVersionTooOld and ::IsFileVersionTooNew to replace hardcoded tests in the code base for version validity. This will make it easier to make changes in the future.
- A few months ago most of the accessors of the version number were deprecated in favour of a version that did not contain the Engine number (ie UE4Ver -> UEVer in Archive) but to work with these changes the renamed methods now will return or accept the version as FPackageFileVersion rather than int32. The old UE4 methods will remain deprecated and direct licensees to use the new methods.
### Archive
- Now stores the version as a FPackageFileVersion rather than int32
### LinkerLoad
- Reports the larger version number if we detect a higher version number than we support. Note that this could cause an issue if the UE4 version is ever raised but helps keep the code simple.
### AssetData
- Need to add a new version here to manage existing data that only has the UE4 version
### EditorDomain
- We do not need to version the format, we can just invalidate existing editor domain entries via EditorDomainVersion
### EditorServer
- When reporting that a package is too old we report the UE4 version as that is the only version that can be older than VER_UE4_OLDEST_LOADABLE_PACKAGE
- When reporting that a package is too new it can be either the UE4 or the UE5 version so we print them together "UE4Ver|UE5Ver"
### ContentCommandlets
- The min and max resave versions have been kept as a single value, you will not be able to resave against different UE4 and UE5 versions at the same time. It doesn't seem like a useful feature and would greatly increase the complexity of the code.
- We will also only report the file version as a single value.
### ManifestUObject
- This class was setting an older obsolete version on purpose to try and maintain compatibility with older clients so we need to provide a way to create an older UE4 only version that will leave the UE5 version as unset.
### NetworkPlatformFile
- I was unable to test the code path in FNetworkPlatformFile::ProcessServerCachedFilesResponse as I am unsure how to run the game in a mode that will actually use it.
- When reading an older "CookedVersion.txt" that was saved with a single version, the reads will fail and this will count as a version change in the code so that all of the existing files will be deleted. The existing code would not give the user a log message when this happens and given the very small time window where this might happen caused by this change I have opted to leave this alone and not add any additional logging.
- If we do detect a version mismatch we will still only log the version number as a single version.
### CookOnTheFlyServer
- We now add each version number to the IniVersionMap rather than merge the version and license version as a key/value pair. This allows us to a) use both the UE4 and UE5 version numbers b) we now log a warning that the version values don't match when it is changed, previously since it was a key value we would log a warning about an additional setting instead.
-- I also added "vs" to the log message when values are mismatched to make the space between the two values being printed clearer.
#ROBOMERGE-OWNER: paul.chipchase
#ROBOMERGE-AUTHOR: paul.chipchase
#ROBOMERGE-SOURCE: CL 17549459 via CL 17550236 via CL 17550238 via CL 17550582
#ROBOMERGE-BOT: STARSHIP (Release-Engine-Staging -> Release-Engine-Test) (v870-17433530)
#ROBOMERGE[STARSHIP]: UE5-Main
[CL 17550583 by paul chipchase in ue5-release-engine-test branch]
Description: Make it so breakpoints are saved in the EditorPerProjectUserSettings ini rather than blueprint uasset files so that they can be excluded from version control and be unique to the user
#jira UE-119540
#rb Ben.Zeigler
#ROBOMERGE-SOURCE: CL 16959614 in //UE5/Main/...
#ROBOMERGE-BOT: STARSHIP (Main -> Release-Engine-Test) (v838-16927207)
[CL 16959625 by jordan hoffmann in ue5-release-engine-test branch]
[FYI] jordan.hoffmann
Original CL Desc
-----------------------------------------------------------------
Feature: Move breakpoint storage out of the uasset file
Description: Make it so breakpoints are saved in the EditorPerProjectUserSettings ini rather than blueprint uasset files so that they can be excluded from version control and be unique to the user
#jira UE-119540
#preflight 60fa0407224826000161cd31
#ROBOMERGE-SOURCE: CL 16934737 in //UE5/Main/...
#ROBOMERGE-BOT: STARSHIP (Main -> Release-Engine-Test) (v838-16927207)
[CL 16934748 by jordan hoffmann in ue5-release-engine-test branch]
Description: Make it so breakpoints are saved in the EditorPerProjectUserSettings ini rather than blueprint uasset files so that they can be excluded from version control and be unique to the user
#jira UE-119540
#preflight 60fa0407224826000161cd31
#ROBOMERGE-SOURCE: CL 16933419 in //UE5/Main/...
#ROBOMERGE-BOT: STARSHIP (Main -> Release-Engine-Test) (v838-16927207)
[CL 16933421 by jordan hoffmann in ue5-release-engine-test branch]
[FYI] jordan.hoffmann
Original CL Desc
-----------------------------------------------------------------
Feature: Move breakpoint storage out of the uasset file
Description: Make it so breakpoints are saved in the EditorPerProjectUserSettings ini rather than blueprint uasset files so that they can be excluded from version control and be unique to the user
#jira UE-119540
#ROBOMERGE-SOURCE: CL 16929845 in //UE5/Main/...
#ROBOMERGE-BOT: STARSHIP (Main -> Release-Engine-Test) (v838-16927207)
[CL 16929852 by jordan hoffmann in ue5-release-engine-test branch]
Description: Make it so breakpoints are saved in the EditorPerProjectUserSettings ini rather than blueprint uasset files so that they can be excluded from version control and be unique to the user
#jira UE-119540
#ROBOMERGE-SOURCE: CL 16915099 in //UE5/Main/...
#ROBOMERGE-BOT: STARSHIP (Main -> Release-Engine-Test) (v836-16769935)
[CL 16915117 by jordan hoffmann in ue5-release-engine-test branch]
#rb johan.torp
GetLinkerUE4Version renamed to GetLinkerUEVersion
#ROBOMERGE-SOURCE: CL 15859222 in //UE5/Release-5.0-EarlyAccess/...
#ROBOMERGE-BOT: STARSHIP (Release-5.0-EarlyAccess -> Main) (v786-15839533)
[CL 15859586 by mark lintott in ue5-main branch]
[FYI] Nick.Darnell
#ROBOMERGE-SOURCE: CL 12582218 via CL 12582221 via CL 12582223
#ROBOMERGE-BOT: RELEASE (Release-Engine-Staging -> Main) (v675-12543919)
[CL 12582228 by bob tellez in Main branch]
#ROBOMERGE-OWNER: nick.darnell
#ROBOMERGE-AUTHOR: nick.darnell
#ROBOMERGE-SOURCE: CL 12580939 via CL 12580947 via CL 12581021 via CL 12581039 via CL 12581048
#ROBOMERGE-BOT: RELEASE (Release-Engine-Staging -> Main) (v675-12543919)
[CL 12581062 by nick darnell in Main branch]
Fred.Kimberly, Marc.Audy, Dan.Oconner, Michael.Noland
#ROBOMERGE-OWNER: nick.darnell
#ROBOMERGE-AUTHOR: nick.darnell
#ROBOMERGE-SOURCE: CL 12572258 via CL 12572295 via CL 12572587 via CL 12572601 via CL 12572607
#ROBOMERGE-BOT: RELEASE (Release-Engine-Staging -> Main) (v675-12543919)
[CL 12572619 by nick darnell in Main branch]
