我们有如题的需求，例如在构建结束后，想要修改构建包体中某个ini的内容，这样生成一个仅有ini变化的新包体。
这个需求如何实现比较合适呢，能想到的比较稳定的方法是将构建后包体内的pak解出来，对其中的ini文件做修改，然后要么重新生成这整个pak，要么将ini独立生成为一个新的pak，通过指定命名带_%d_P来使得优先级高于原有的pak。
除此之外还有什么方法比较合适，可以跳过解pak这一步的吗？例如引擎中的UOnlineHotfixManager::HotfixIniFile，用在这种场景下是否合适呢？
如果我们想更新的是[OnlineSubsystem]的DefaultPlatformService，该模块的初始化时机在PostConfigInit，情况是否会发生变化（因为这个初始化时机过早了）
[Attachment Removed]
你好
正如您所说的，将修改的ini文件单独生成一个新优先级高的pak，是比较稳妥的方案。
还有一个选项是，不将ini文件放在pak包里面，这样自然是随时都可以修改。
HotfixIniFile是运行时下载更新，对于DefaultPlatformService而言，已经太迟了。
希望这些信息对您有所帮助。如果您还有后续问题，请让我知道。
谢谢
Henry Liu
[Attachment Removed]
感谢回复！不过我想表达的是可以用类似HotfixIniFile中类似的方案，例如通过UE::DynamicConfig::PerformDynamicConfig来更新ini中的特定值。例如OnlineSubsystem在PostConfigInit阶段初始化，我看在这个阶段之前的EarliestPossible阶段，pak和ini应该都初始化了，我们把需要修改的ini单独打成pak，通过上述方式做一个简单的更新是否稳定呢？
[Attachment Removed]
你好
根据您所描述的方案，我理解您是准备自己实现一个Plugin,在EarliestPossible阶段，读取定制的pak中的配置信息(这可以是任意适合您项目的数据格式，pak是UE的选项)，然后在合适的时机写入这些相应的配置。EarliestPossible确实是在Config信息都加载完后，最临近的时机。感觉上这个方案是合理可行的。您可以访问到GConfig，基本上，您有什么需求直接进行操作就行了。
如果您还有后续问题，请联系我。谢谢。
[Attachment Removed]