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]
Note: For now this lives with Enhanced Input, but should probably go somewhere else as it doesn't actually depend on anything related to Enhanced Input. Ideally I think it should live in InputCore, but it cant because InputCore cannot depend on the "Engine" module which is where all the debug helpers are.
#jira UE-147805
#rb andy.davidson
#preflight 6275531bd8373707f21bcf76
[CL 20102045 by ben hoffman in ue5-main branch]
These functions will make it easier for people to extend this class, while still keeping the AppliedInputContext and EnhancedActionMappings properties const and non-mutable.
#jira none
#rb trivial
#preflight 626fe786264f78f46f766589
[CL 20008700 by ben hoffman in ue5-main branch]
Create a "UEnhancedInputPlatformData" base class that can be subclassed in a blueprint and placed on specific platforms. By default, this object has a map of Input Contexts that will "redirect" one context to another. This makes it possible to swap out Input Mapping Contexts on specific platforms, with an asset that will simply be added to the input ini of the game.
#jira UE-144850
#preflight 6245cae4c51908059abd88b4
#rb andrew.davidson
#rb dave.jones2
[CL 19575308 by ben hoffman in ue5-main branch]
1. On custom types, they require overloads for operator <= and >= respectively; it's more idiomatic in C++ code for ordering predicates to rely solely on <
2. The current definition results in highly suboptimal code generation for floating-point types on x86 when compiling in IEEE compliant mode: https://godbolt.org/z/3zsYKaasc
In short, x86 min/max instructions are equivalent to "(a < b) ? a : b" and "(a > b) ? a : b", respectively. In the specific case where a=+0, b=-0 (IEEE signed zeros), then in comparisons +0 == -0, so we have both (a >= b) and (a <= b), but neither (a > b) nor (b < a). As a result, the original expressions for FMath::{Min,Max} return a (+0), while the changed expressions returns b (-0) in this particular case. (The a=-0, b=+0 case is analogous.)
Most code in UE currently compiles with /fp:fast or -ffast-math, which makes the compiler not respect signed zero behavior; see behavior with -fno-signed-zeros in the Compiler Explorer link. Because so much gets compiled with fast math semantics, behavior in this case was not reliable anyway. We might as well pick the definition that is efficient on x86 even without fast math.
#rb devin.doucette
#preflight 6239248304769ab4934cd0ea
[CL 19462511 by fabian giesen in ue5-main branch]
