- Formalizing all TargetPlatforms to have a Client version, rename WindowsNoEditor to Windows, and removing DDPI specification of TargetPlatforms, and generate them programmatically
- Updated names DeviceProfiles and Build scripts, as above
- Some PlatformInfo class cleanup
- Added a TNonDesktopTargetPlatformBase class to make most TargetPlatforms simpler
- Added "No Compiled Support" to the Turnkey LaunchOn menu when the TargetPlatforms aren't compiled in (to show that even if you install an SDK, you will need to compile before you can LaunchOn)\
- Starting the transition away from PlatformInfo::FPlatformInfo to FDDPI
[CL 13966487 by Josh Adams in ue5-main branch]
- Renamed FDataDrivenPlatformRegistry::FPlatformInfo to FDataDrivenPlatformInfo
- Moved some fields from PlatformInfo::FTargetPlatformInfo to FDataDrivenPlatformInfo, and cleaned them up in the process
- Fixed the DataDrivePlatformInfo.ini files to match the previous items
- Removed FVanillaPlatformEntry, and now just using FTargetPlatformInfo to manage flavors under a vanilla PlatformInfo (see PlatformInfo::GetVanillaPlatformInfoArray())
- Cleaned up TPerPlatformValue, as it was often misused (took a group and platform name, but we can get the group from the platform name) [AnimationSharingManager.cpp, *Engine.cpp, Runtime\Engine\*, ]
- Fixed FBlueprintNativeCodeGenPaths::GetDefaultCodeGenPaths() to use IniPlatformName instead of some hacky code [BlueprintNativeCodeGenManifest.cpp]
- Fixed various Turnkey bugs that recent testing exposed
- Enabled AUTOSDKS_ENABLED in both Mac and Linux on the Editor side (not that there are much set up to use it)
- Using Turnkey to get the SDK status instead of ValidatePlatforms (gives more detailed information - may want to go back to ValidatePlatforms so only UBT is needed, but change it to give more info)
- Moved OnDeviceDiscovered and Lost delegates from each platform's TargetPlatform class to a static in ITargetPlatform - there was no need for per-platform implementations
- Started working on allowing for SDK to be installed with editor running and not need to restart editor - Work in Progress! It is not usable yet.
#fyi jack.porter
#rb pete.sauerbrei
[CL 13816905 by Josh Adams in ue5-main branch]
There are no longer any platforms marked as having "restricted" localization, as they all now live inside platform extensions. The original spirit of this option lives on as ELocTextPlatformSplitMode::Confidential, however none of our localization targets are using it and it has limited utility.
#rb none
[CL 13035985 by Jamie Dale in Main branch]
LatAm Spanish (es-419) often leaves words in English rather than translate them, however we were finding that they would take the Castilian Spanish (es) translation instead, which often lead to confusion for players as those terms weren't understood within the LatAm community.
This was caused by the fact that any untranslated text (text matching the source) was considered redundant and was skipped when generating the LocRes file, which failed to take into account potentially needing to override a base translation when dealing with language hierarchies.
This change now tests otherwise untranslated text against the translations of any parent languages, and will consider the entry translated if it is different from one that would be inherited at runtime.
[FYI] Carlos.Almeida, David.Emmanuelli
#rb Lauren.Barnes
#ROBOMERGE-SOURCE: CL 12973946 via CL 12973947 via CL 12973948 via CL 12973950
#ROBOMERGE-BOT: RELEASE (Release-Engine-Staging -> Main) (v682-12900288)
[CL 12973951 by jamie dale in Main branch]
#rnx
#rb none
#ROBOMERGE-SOURCE: CL 10869240 via CL 10869516 via CL 10869902
#ROBOMERGE-BOT: (v613-10869866)
[CL 10870584 by ryan durand in Main branch]
The localization pipeline locks the relative paths used by a target to either the engine or project root (depending on the target type), however the UE4 engine isn't localized into many languages, so project targets often have to override some of the engine localization to support their additional languages. For in-source builds, this was possible by using a project relative path to the engine directory (which was in a fixed location), however for any out-of-source projects (such as those in the "Unreal Projects" directory) there was no way to do this in a portable way.
This change adds a "path root" to every include and exclude path, which can be set to "Auto" (the default, which detects the root based on the target type), "Engine" (to force the path to be resolved relative to the engine root), or "Project" (to force the path to be resolved relative to the project root). This allows out-of-source projects to specify paths relative to the engine in a portable way.
#jira UE-70296
#rb Lauren.Ridge
#ROBOMERGE-SOURCE: CL 5073204 in //UE4/Release-4.22/...
#ROBOMERGE-BOT: RELEASE (Release-4.22 -> Main)
[CL 5073205 by jamie dale in Main branch]
This is handled by the ELocTextPlatformSplitMode enum, used by FLocTextHelper (default is ELocTextPlatformSplitMode::None to preserve old behavior), and allows you to optionally split localization data for all platforms, or for any NDA restricted platforms. Note: Any localization data that is used by multiple platforms is still considered platform agnostic, even if it appears only within platform specific files.
#jira UE-65600
#rb Francis.Hurteau
#lockdown Matt.Kuhlenschmidt
[CL 4761508 by Jamie Dale in Dev-Editor branch]
