This allows them to separate their mounting and content loading into two phases, such as allowing a GFP to mount the plugin when "registered" and defer mounting the localization data until "activating".
Note: Anything that was calling one of the MountExplicitlyLoadedPlugin functions to load a plugin, will now need to also call MountExplicitlyLoadedPluginLocalizationData if it wants to also mount the localization data.
#rb anton.dunchev, Leon.Huang
[CL 32029617 by jamie dale in ue5-main branch]
[Backout] - CL31459949
[FYI] bob.tellez
Original CL Desc
-----------------------------------------------------------------
[Backout] - CL31443953
[FYI] Josh.Adams
Original CL Desc
-----------------------------------------------------------------
Phase 1 of the FConfigBranch changes:
Introduced FConfigBranch which maintains logic and data for each individual branch of GConfig (Engine, Game, Input, DeviceProfiles, etc), with static and dynamic layers
Introduced FConfigCommandStream which is how each layer is loaded, and Apply'd to an FConfigFile
Added a new way of making a "diff" of in-memory vs what's loaded, which creates an FConfigCommandStream that can be re-applied (more useful in Phase 2, see below)
Expectation is no visible differences from before this change, as it's mostly internal data structure changes
Phase 2 is where the functional changes will happen, with the dynamic layers being able to be removed at runtime, and the state of GConfig is maintained as expdected
The editor does maintain full state of where config values come from, so the "getini" command in the editor will show a lot more information now
Runtime will not keep any state, so unloading dynamic layers is not supported by default (running with -ConfigReplayMethod=1 or 2 will allow for it, but will use more memory)
#rb david.harvey
#jira UE-201472
[CL 31470013 by josh adams in ue5-main branch]
[FYI] Josh.Adams
Original CL Desc
-----------------------------------------------------------------
Phase 1 of the FConfigBranch changes:
Introduced FConfigBranch which maintains logic and data for each individual branch of GConfig (Engine, Game, Input, DeviceProfiles, etc), with static and dynamic layers
Introduced FConfigCommandStream which is how each layer is loaded, and Apply'd to an FConfigFile
Added a new way of making a "diff" of in-memory vs what's loaded, which creates an FConfigCommandStream that can be re-applied (more useful in Phase 2, see below)
Expectation is no visible differences from before this change, as it's mostly internal data structure changes
Phase 2 is where the functional changes will happen, with the dynamic layers being able to be removed at runtime, and the state of GConfig is maintained as expdected
The editor does maintain full state of where config values come from, so the "getini" command in the editor will show a lot more information now
Runtime will not keep any state, so unloading dynamic layers is not supported by default (running with -ConfigReplayMethod=1 or 2 will allow for it, but will use more memory)
#rb david.harvey
#jira UE-201472
[CL 31459959 by bob tellez in ue5-main branch]
Introduced FConfigBranch which maintains logic and data for each individual branch of GConfig (Engine, Game, Input, DeviceProfiles, etc), with static and dynamic layers
Introduced FConfigCommandStream which is how each layer is loaded, and Apply'd to an FConfigFile
Added a new way of making a "diff" of in-memory vs what's loaded, which creates an FConfigCommandStream that can be re-applied (more useful in Phase 2, see below)
Expectation is no visible differences from before this change, as it's mostly internal data structure changes
Phase 2 is where the functional changes will happen, with the dynamic layers being able to be removed at runtime, and the state of GConfig is maintained as expdected
The editor does maintain full state of where config values come from, so the "getini" command in the editor will show a lot more information now
Runtime will not keep any state, so unloading dynamic layers is not supported by default (running with -ConfigReplayMethod=1 or 2 will allow for it, but will use more memory)
#rb david.harvey
#jira UE-201472
[CL 31444162 by josh adams in ue5-main branch]
Introduced opt in localization for plugins. Plugins can be set to never have localization config files generated, auto-generated or have the localization pipeline use the user generated localization config files.
- All existing plugins with localization targets will be retrofitted to have a LocalizationConfigGenerationPolicy of Never to match current behavior.
- Introduced the LocalizationConfigGenerationPolicy enum to plugin descriptors and LocalizationTargetDescriptors. This controls whether plugin localization targets use user generated localization config files, auto-generated localization config files or if the plugin is never to have localization config files and thus not localized.
- Introduced a step in the Localize UAT command to auto-generate localization config files with default settings for plugins that opt into the auto-generation feature.
- Added a clean up step in the Localize uAT command to delete all auto-generated files and folders from a run of the command.
- Added a -PreserveAutoGeneratedResources flag for the Localize UAT command to preserve the auto-generated files and directories for debugging.
-Updated both the C# and C++ version of the LocalizationTargetDescriptor to contain the new LocalizationConfigGenerationPolicy and have them read and written from the plugin descriptor files.
- Updated the NewPluginLocalizationTarget command under the LocalizationTargetEditor UAT command to accept a LocalizationConfigGenerationPolicy as a command line argument for all plugin localization targets to be created.
If the parameter is not specified, the parameter defaults to the Auto LocalizationConfigGenerationPolicy for all the plugins specified.
#rb: Jamie.Dale
#jira: UE-194880, UE-194879
#test Used the NewPluginLocalizationTarget sub-command to create plugins with an auto localization target. Used the Localize UAT command to perform a gather for such a plugin. Config files were indeed generated, the plugin was gathered and the loc data stored in PluginName/Content/Localization and then the config files were deleted. No fuss, no muss
[CL 30172150 by leon huang in ue5-main branch]
Original CL Desc
-----------------------------------------------------------------
New VerseScope "InternalUser" and renamed "User" to "PublicUser"
- new enumerator for VerseScope named "InternalUser"
- renamed existing VerseScope "User" to "PublicUser" - this is possible without breaking existing projects since the VerseScope is not written out to the uplugin file when it is set to "User"
#rb andrew.scheidecker
#rnx
[CL 29419291 by bob tellez in ue5-main branch]
[FYI] Markus.Breyer
Original CL Desc
-----------------------------------------------------------------
New VerseScope "InternalUser" and renamed "User" to "PublicUser"
- new enumerator for VerseScope named "InternalUser"
- renamed existing VerseScope "User" to "PublicUser" - this is possible without breaking existing projects since the VerseScope is not written out to the uplugin file when it is set to "User"
#rb andrew.scheidecker
#rnx
[CL 29418991 by bob tellez in ue5-main branch]
