I’d like to ask about the behavior of UPROPERTY variables marked with the Config specifier, especially in the context of patching.
From what I understand, these properties are initialized by referencing the ConfigCache when creating Class Default Objects (CDOs), which occurs after the corresponding module is loaded. However, the ConfigCache itself is initialized much earlier during engine startup.
A typical patch flow looks like this:
Engine initialization
Module loading
Download and mount the patch .pak (including updated .ini files)
Given this order, any modified .ini files included in the patch are applied after the ConfigCache and CDOs have already been initialized using the base version’s settings. As a result, updated config values from the patch are not reflected.
To work around this, we are currently doing the following:
Manually reloading the ConfigCache by config type using FConfigContext
Explicitly calling LoadConfig on related UObjects
However, this approach is quite manual and error-prone, especially when managing many objects and config files.
Is there a recommended or more automated way to refresh config-based UPROPERTY values after patch application, or is this manual handling the intended and only supported method?
Any guidance on best practices for this use case would be greatly appreciated.
Reloading the newer config files is the proper way to handle this case. You can have a look at the Online Hotfix Manager plugin as an example. Check UOnlineHotfixManager::HotfixIniFile
It’s a bit disappointing to hear that the functionality I need isn’t supported as a built-in feature of the engine.
As for the OnlineHotfixManager you mentioned, it seems to be part of the OnlineFramework plugin. From what I could find, it looks like only a few plugins—such as DefaultInstallBundleManager and OnlineSubsystemTencent—make use of it.
Since OnlineSubsystemTencent isn’t relevant to our project, I’ll rule that one out.
It seems like DefaultInstallBundleManager, if used properly, could be leveraged to patch elements that impact the engine initialization process (such as .ini files, shaders, etc.). Is there any guide or documentation available that explains how to use this system effectively?
Separately, our project runs in an environment that uses its own dedicated servers, independent of the Unreal system. I’m curious whether it’s still possible to integrate modules like OnlineSubsystem or OnlineServices in such a setup.
The UOnlineHotfixManager is a public class in the base OnlineFramework plugin. You can access this class from your project code by activating the plugin and referencing the HotFix module in the build.cs. I recommend looking at the Lyra sample which uses a customized version named ULyraHotfixManager.