This change consists of multiple changes:
Core:
- Deprecation of ANY_PACKAGE macro. Added ANY_PACKAGE_DEPRECATED macro which can still be used for backwards compatibility purposes (only used in CoreUObject)
- Deprecation of StaticFindObjectFast* functions that take bAnyPackage parameter
- Added UStruct::GetStructPathName function that returns FTopLevelAssetPath representing the path name (package + object FName, super quick compared to UObject::GetPathName) + wrapper UClass::GetClassPathName to make it look better when used with UClasses
- Added (Static)FindFirstObject* functions that find a first object given its Name (no Outer). These functions are used in places I consider valid to do global UObject (UClass) lookups like parsing command line parameters / checking for unique object names
- Added static UClass::TryFindType function which serves a similar purpose as FindFirstObject however it's going to throw a warning (with a callstack / maybe ensure in the future?) if short class name is provided. This function is used in places that used to use short class names but now should have been converted to use path names to catch any potential regressions and or edge cases I missed.
- Added static UClass::TryConvertShortNameToPathName utility function
- Added static UClass::TryFixShortClassNameExportPath utility function
- Object text export paths will now also include class path (Texture2D'/Game/Textures/Grass.Grass' -> /Script/Engine.Texture2D'/Game/Textures/Grass.Grass')
- All places that manually generated object export paths for objects will now use FObjectPropertyBase::GetExportPath
- Added a new startup test that checks for short type names in UClass/FProperty MetaData values
AssetRegistry:
- Deprecated any member variables (FAssetData / FARFilter) or functions that use FNames to represent class names and replaced them with FTopLevelAssetPath
- Added new member variables and new function overloads that use FTopLevelAssetPath to represent class names
- This also applies to a few other modules' APIs to match AssetRegistry changes
Everything else:
- Updated code that used ANY_PACKAGE (depending on the use case) to use FindObject(nullptr, PathToObject), UClass::TryFindType (used when path name is expected, warns if it's a short name) or FindFirstObject (usually for finding types based on user input but there's been a few legitimate use cases not related to user input)
- Updated code that used AssetRegistry API to use FTopLevelAssetPaths and USomeClass::StaticClass()->GetClassPathName() instead of GetFName()
- Updated meta data and hardcoded FindObject(ANY_PACKAGE, "EEnumNameOrClassName") calls to use path names
#jira UE-99463
#rb many.people
[FYI] Marcus.Wassmer
#preflight 629248ec2256738f75de9b32
#codereviewnumbers 20320742, 20320791, 20320799, 20320756, 20320809, 20320830, 20320840, 20320846, 20320851, 20320863, 20320780, 20320765, 20320876, 20320786
#ROBOMERGE-OWNER: robert.manuszewski
#ROBOMERGE-AUTHOR: robert.manuszewski
#ROBOMERGE-SOURCE: CL 20430220 via CL 20433854 via CL 20435474 via CL 20435484
#ROBOMERGE-BOT: UE5 (Release-Engine-Staging -> Main) (v949-20362246)
[CL 20448496 by robert manuszewski in ue5-main branch]
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]
#rb Alexis.Matte
[FYI] Rex.Hill
#ROBOMERGE-AUTHOR: scott.nelson
#ROBOMERGE-SOURCE: CL 20355903 via CL 20355929 via CL 20356007 via CL 20356029
#ROBOMERGE-BOT: UE5 (Release-Engine-Staging -> Main) (v948-20297126)
[CL 20357497 by scott nelson in ue5-main branch]
#rb Rex.Hill
#preflight 628c7900d8258814a9f1508a
#ROBOMERGE-AUTHOR: scott.nelson
#ROBOMERGE-SOURCE: CL 20348402 via CL 20348414 via CL 20348589 via CL 20348662
#ROBOMERGE-BOT: UE5 (Release-Engine-Staging -> Main) (v948-20297126)
[CL 20352071 by scott nelson 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]
[FYI] scott.nelson
Original CL Desc
-----------------------------------------------------------------
Pass PropertyHandle through MaterialList PropertyEntryBox so that AssetReferenceFilter can access the property source
#rb Dave.Belanger
#preflight 626c698b9e6bef17921880b6
#ROBOMERGE-AUTHOR: scott.nelson
#ROBOMERGE-SOURCE: CL 20015741 via CL 20015772 via CL 20015783 via CL 20015806
#ROBOMERGE-BOT: UE5 (Release-Engine-Staging -> Main) (v943-19904690)
[CL 20017273 by scott nelson in ue5-main branch]
#rb Dave.Belanger
#preflight 626c698b9e6bef17921880b6
#ROBOMERGE-AUTHOR: scott.nelson
#ROBOMERGE-SOURCE: CL 20014556 via CL 20014584 via CL 20014763 via CL 20014996
#ROBOMERGE-BOT: UE5 (Release-Engine-Staging -> Main) (v943-19904690)
[CL 20017231 by scott nelson in ue5-main branch]
Previously, I had assumed that FProperty::InitializeValue() would initialize a simple member (eg. a float) to the correct value, but this appears not to be the case, rather values are zero-initialized and the CDO stores the correct default values. In the case of structs, InitializeStruct() does in fact initialize correctly.
However, this means that we can't use GetMutableDefault() to get an instance of the UObject, since then we're changing what we're diffing against and serialize no values. Changed the usages of this pattern to use singletons instead.
#jira UE-141150
#review-19900014 @lauren.barnes, @aditya.ravichandran
#preflight 6267fa44a021c91a50f26a65
[CL 19919719 by sebastian nordgren in ue5-main branch]
This is a pretty rare case that only occurs if you bypass OnItemNodeInitialized() by creating and adding a property row outside of a CustomizeDetails() call in a property customization. However, the use case is pretty innocuous and this seems more correct anyway, so there's not really any harm to changing the behaviour.
Reported in UDN case 00426747.
#review-19806378 @lauren.barnes
#preflight 6261522f080c66006373c9e5
[CL 19848082 by sebastian nordgren in ue5-main branch]
Added ensure to check that either the PropertyEditor or PropertyHandle passed is valid.
Reported through UDN.
#review @lauren.barnes
#preflight 624d78d08d1db441a91f35e8
[CL 19847726 by sebastian nordgren 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]
