We were blindly assuming that CurrentObject was non-null and crashing on CurrentObject->GetOuter(), even though DuplicateObject() itself was safe to call with null.
#review-20365567 @lauren.barnes
#jira UE-151124
#preflight 628e4dccf622d972b58a1e26
[CL 20429746 by sebastian nordgren in ue5-main branch]
FPropertyNode::FindChildNode is now actually breadth-first, rather than only being breadth-first for a single level. This was causing an issue whereby title properties were being incorrectly retrieved from the first child rather than the topmost child.
Reported from UDN: https://epicgames.lightning.force.com/lightning/r/Case/5004z00001eFeYlAAK/view
#review @nick.darnell, @mikko.mononen
#preflight 628bb2d4183c1e13462d50cd
[CL 20364792 by sebastian nordgren in ue5-main branch]
This causes all the modified objects to have their PostEditChangeProperty() handlers called even if the construction script of a blueprint class is triggered by the first invocation.
Most notably, this fixes the case where multiple components of an actor are multi-selected and edited at the same time, but only one of them will receive a PostEditChangeProperty() call.
Reported from UDN: https://epicgames.lightning.force.com/lightning/r/Case/5004z00001eEzehAAC/view
#review-20292399 @lauren.barnes, @marc.audy
#preflight 628ca47af237058787b96692
[CL 20345739 by sebastian nordgren in ue5-main branch]
Some property types may rely on PPF_SerializedAsImportText to allocate extra state that's required for accurate comparison against another instance
#jira
#rb Rex.Hill
#rnx
#ROBOMERGE-OWNER: jamie.dale
#ROBOMERGE-AUTHOR: jamie.dale
#ROBOMERGE-SOURCE: CL 20180858 via CL 20180979 via CL 20181019 via CL 20181058 via CL 20181073
#ROBOMERGE-BOT: UE5 (Release-Engine-Staging -> Main) (v943-19904690)
[CL 20182513 by jamie dale in ue5-main branch]
The child struct properties can't inherit the sparse data flag, as FStructurePropertyNode is already directly editing a block of struct memory.
This also includes a workaround for a crash when propagating changes from a FStructurePropertyNode nested within an object, as the sparse data flag used to workaround it but that is no longer set.
#jira UE-140961
#preflight 61fa9368ad2ae6c3b75c1d66
#rb Mikko.Mononen
#ROBOMERGE-AUTHOR: jamie.dale
#ROBOMERGE-SOURCE: CL 19816629 via CL 19819868 via CL 19820375
#ROBOMERGE-BOT: UE5 (Release-Engine-Staging -> Main) (v939-19570697)
[CL 19821914 by jamie dale in ue5-main branch]
[FYI] Nick.Darnell
Original CL Desc
-----------------------------------------------------------------
Allow AddChildStructure to be used by sparse data properties
The child struct properties can't inherit the sparse data flag, as FStructurePropertyNode is already directly editing a block of struct memory.
#jira UE-140961
#preflight 61fa9368ad2ae6c3b75c1d66
#rb Mikko.Mononen
#p4v-cherrypick 18826515
#ROBOMERGE-AUTHOR: jamie.dale
#ROBOMERGE-SOURCE: CL 18826037 via CL 18826067 via CL 18826480 via CL 19776180 via CL 19776547 via CL 19776613
#ROBOMERGE-BOT: UE5 (Release-Engine-Staging -> Main) (v939-19570697)
[CL 19803101 by josh may in ue5-main branch]
Setters and getters are native functions called by FProperties when setting property values with *_InContainer functions.
Setters and getter function names can be manually specified with Setter = Func and Getter = Func keywords inside of UPROEPRTY macro but they will also be automatically parsed if the name is not explicitly specified if the setter or getter function name matches SetPropertyName and GetPropertyName pattern.
The latter behavior can be disabled in UHT's DefaultEngine.ini by setting AutomaticSettersAndGetters=False.
ImportText and ExportTextItem functions have been deprecated and should be replaced with *_InContainer or *_Direct variants.
#rb Steve.Robb
#preflight 6210a377a83e0bcefd03d9e1
#ROBOMERGE-OWNER: marc.audy
#ROBOMERGE-AUTHOR: robert.manuszewski
#ROBOMERGE-SOURCE: CL 19070318 via CL 19098059 via CL 19104650 via CL 19104661 via CL 19110012
#ROBOMERGE-BOT: UE5 (Release-Engine-Staging -> Main) (v921-19075845)
[CL 19147839 by marc audy in ue5-main branch]
The child struct properties can't inherit the sparse data flag, as FStructurePropertyNode is already directly editing a block of struct memory.
#jira UE-140961
#preflight 61fa9368ad2ae6c3b75c1d66
#rb Mikko.Mononen
#ROBOMERGE-AUTHOR: jamie.dale
#ROBOMERGE-SOURCE: CL 18826037 in //UE5/Release-5.0/... via CL 18826067 via CL 18826480
#ROBOMERGE-BOT: UE5 (Release-Engine-Test -> Main) (v910-18824042)
[CL 18826515 by jamie dale in ue5-main branch]
It was specifically looking for an object parent rather than a complex parent, which meant it skipped invalidating the cache when editing a struct (including a nested external struct) rather than an object.
#jira
#preflight skip
#rb Sebastian.Nordgren
#rnx
#ROBOMERGE-AUTHOR: jamie.dale
#ROBOMERGE-SOURCE: CL 18340184 via CL 18342197 via CL 18342218 via CL 18342239 via CL 18342503 via CL 18342517
#ROBOMERGE-BOT: STARSHIP (Release-Engine-Staging -> Release-Engine-Test) (v895-18170469)
[CL 18342528 by jamie dale in ue5-release-engine-test branch]
This would try and get the value of the outer array property (for the inner array value) using FObjectBaseAddress::ObjectOrStruct as the start address, however for class sparse data FObjectBaseAddress::ObjectOrStruct was set to the CDO of the class that owns the sparse data, rather than the start of the sparse data itself. This resulted in a crash as it would try and read garbage from the CDO.
This change removes FObjectBaseAddress::ObjectOrStruct and FObjectBaseAddress::bIsStruct, in favor of storing FObjectBaseAddress::Object (if not editing a struct) and FObjectBaseAddress::StructAddress. FObjectBaseAddress::StructAddress always points to the thing that actually contains FObjectBaseAddress::BaseAddress, which allows the ImportText code to get the correct offset for the array property within the sparse data instance.
#jira
#rb Sebastian.Nordgren
#preflight 61a59b104f5d65edc3a8564b
#rnx
#ROBOMERGE-AUTHOR: jamie.dale
#ROBOMERGE-SOURCE: CL 18326295 via CL 18328452 via CL 18328534 via CL 18328607 via CL 18330452 via CL 18330516
#ROBOMERGE-BOT: STARSHIP (Release-Engine-Staging -> Release-Engine-Test) (v895-18170469)
[CL 18330630 by jamie dale in ue5-release-engine-test 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]
class UFoo
{
struct Bar { int X; } Bar;
int X;
}
Returning Bar.X instead of just X when searching for "X", because we were iterating into the struct's children before our own.
This entire behaviour is a bit questionable since it doesn't use property paths, and is presumably in place to deal with groups and not structs, but I'm not comfortable making that change without further testing.
#jira UE-126704
[at]matt.kuhlenschmidt, [at]mikko.mononen
#ROBOMERGE-AUTHOR: sebastian.nordgren
#ROBOMERGE-SOURCE: CL 17721178 in //UE5/Main/...
#ROBOMERGE-BOT: STARSHIP (Main -> Release-Engine-Test) (v879-17706426)
[CL 17721189 by sebastian nordgren in ue5-release-engine-test branch]
This ensure is intended to check if we can simplify the logic here to just return the first object's default value in the near future.
#jira UE-81958
[at]matt.kuhlenschmidt
#ROBOMERGE-AUTHOR: sebastian.nordgren
#ROBOMERGE-SOURCE: CL 17721129 in //UE5/Main/...
#ROBOMERGE-BOT: STARSHIP (Main -> Release-Engine-Test) (v879-17706426)
[CL 17721138 by sebastian nordgren in ue5-release-engine-test branch]
