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]
This represents UE4/Main @17911760, Release-5.0 @17915875 and Dev-PerfTest @17914035
[CL 17918595 by aurel cordonnier in ue5-release-engine-test branch]
This represents UE4/Main @17774255, Release-5.0 @17791557 and Dev-PerfTest @17789485
[CL 17794212 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]
Sections are now sorted correctly - General and All are special-cased to be the first and last categories respectively, the rest are alphabetically sorted.
#preflight 615b13e1b3702500016676aa
#ROBOMERGE-AUTHOR: sebastian.nordgren
#ROBOMERGE-SOURCE: CL 17708850 in //UE5/Main/...
#ROBOMERGE-BOT: STARSHIP (Main -> Release-Engine-Test) (v879-17706426)
[CL 17708864 by sebastian nordgren in ue5-release-engine-test branch]
