Z's Blog

UE Plugin and Tools Development: Extensibility Support

UE插件与工具开发：可扩展性支持
Posted on In , Views:
Symbols count in article: 11k Reading time ≈ 28 mins.

When developing plugins, as plugin functionalities become increasingly complex, it’s often necessary to provide some extensibility support to implement custom extended features that enrich the plugin’s capabilities, and also to facilitate users in customizing projects without modifying the core program.
In previous articles (HotPatcher’s Modular Refactoring and Development Planning), the support for HotPatcher and extension modules, and how to develop a new module based on HotPatcher were introduced. This article primarily details the specific implementation methods within UE.

Simply put, it means building one’s own extension system on top of UE’s existing plugin system. This article will introduce some of my thoughts and techniques on improving plugin extensibility, and how to conveniently decouple these extension features from the main plugin body for easier maintenance and management.

Core Refactoring

Based on my experience with HotPatcher, extension Mods typically fulfill the following requirements:

  1. Listen to the execution flow to perform actions. For example, after HotPatcher packaging is complete, the patch can be pushed directly to a mobile device.
  2. Extend the execution flow to perform additional data recording and processing within the default execution framework. For example, during the HotPatcher hot-update process, the current git commit information of each local repository is recorded.
  3. Logic replacement, replacing the logic within the plugin with custom logic as needed.
  4. Feature encapsulation. In this case, it won’t affect the core plugin’s flow and logic, but it will wrap the core plugin’s features with a special layer of encapsulation as needed. For instance, the GameFeaturePacker Mod encapsulates HotPatcher‘s packaging capabilities specifically for GF packaging.

Therefore, based on these requirements, some refactoring of the base plugin core is needed before proceeding with extensibility modifications:

  1. Configuration-driven refactoring: Make the plugin’s task execution completely configuration-driven, allowing extension modules to override configuration logic to implement custom features. For example, the GameFeaturePacker module I previously implemented encapsulates HotPatcher‘s packaging capabilities, but adds specific asset and file packaging logic for GF plugins.
  2. Execution logic phase splitting: Divide the plugin’s process into multiple distinct phases. This part is crucial, as splitting allows us to easily intervene in the execution process of each phase, achieving the goal of extensibility.
  3. Context support: Ensure a unified context (Context) throughout the entire execution process. In extension flows, data within the context is often modified (e.g., to further process the results of HotPatcher‘s diff analysis, one would need to retrieve the diff results from the context and modify the context after processing).
  4. Critical logic replacement: Some behaviors within the plugin are not hardcoded but can be controlled dynamically or through configuration, such as resource analysis and diff analysis logic in HotPatcher.
  5. Allow recording additional data or files: When a module is developed, it might produce data or files not directly required by the core, which need to be collected centrally within the core’s process.
  6. Module isolation: The behavior of extension modules themselves needs to be well-abstracted to prevent direct dependencies of the core on modules, thus avoiding cyclical plugin dependencies in UE.

Once a plugin has undergone the above refactoring, the core will have a clearer execution architecture and be easily extensible. Next, the specific implementation of the extensible parts will be introduced.

Our goals are to achieve:

  1. The Mod is a completely independent UE plugin. Installing it requires no modifications to the core; simply place the Mod’s plugin into the project.
  2. The Mod has pluggable behavior, and its impact on the core is controllable, allowing it to be disabled via configuration at any time to prevent a Mod issue from affecting the entire execution process.
  3. The Mod has completely independent configuration and execution flows.

Mod Registration

Sometimes modules add completely independent configurations, such as extension modules for HotPatcher:

Each module’s configuration is independent and supports Import/Export/Reset configuration mechanisms.
Because the main interface is written by the HotPatcher core, and each module’s configuration logic and Slate widgets are written within its own module, and each module may also have multiple configuration scenarios.
Therefore, it’s necessary to define good abstractions for modules within the core. Each module’s behavior is abstracted into an Action, and each extension can have multiple Actions:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
using FRequestWidgetPtr = TFunction<TSharedRef<SHotPatcherWidgetInterface>(TSharedPtr<FHotPatcherModContextBase>)>;

struct HOTPATCHEREDITOR_API FHotPatcherActionDesc
{
	FHotPatcherActionDesc()=default;
	FHotPatcherActionDesc(FString InCategory,FString InModName,FString InActionName,FString InToolTip,FRequestWidgetPtr InRequestWidgetPtr,int32 InPriority = 0):
	Category(InCategory),ModName(InModName),ActionName(InActionName),ToolTip(InToolTip),RequestWidgetPtr(InRequestWidgetPtr),Priority(InPriority)
	{}
	
	FString Category;
	FString ModName;
	FString ActionName;
	FString ToolTip;
	FRequestWidgetPtr RequestWidgetPtr;
	int32 Priority = 0;
};

struct HOTPATCHEREDITOR_API FHotPatcherModDesc  
{  
    FString ModName;  
    bool bIsBuiltInMod = false;  
    float CurrentVersion = 0.f;  
    FString Description;  
    FString URL;  
    FString UpdateURL;  
    float MinHotPatcherVersion = 0.0f;  
    TArray<FHotPatcherActionDesc> ModActions;  
};

For each Mod, the following information needs to be recorded:

  1. Name
  2. Whether it’s a built-in Mod for the core
  3. Current version number
  4. Mod description
  5. Mod URL (documentation, etc.)
  6. Update URL (for checking Mod updates)
  7. Minimum core version that this Mod depends on
  8. List of Actions supported by the Mod

This way, each Mod’s information can be clearly recorded.

Each Mod adds executable configuration logic by registering an Action, allowing RequestWidgetPtr to dynamically request the Mod’s Widget; it’s just a callback function.

Taking HotPatcher as an example, when a Mod’s Action is selected from the list in the upper right corner, the corresponding control for that Action will be dynamically requested and populated into the main interface:

At the same time, logic to register an Action also needs to be written when the Mod plugin’s Module starts up. This also depends on the base core plugin’s LoadingPhase being earlier than that of the extension Mod.

The core provides registration functions

1
2
3
4
5
6
7
8
9
10
11
struct HOTPATCHEREDITOR_API FHotPatcherActionManager
{
    static FHotPatcherActionManager Manager;
	static FHotPatcherActionManager& Get()	{ return Manager; }
	// ...
	void RegisteHotPatcherAction(const FHotPatcherActionDesc& NewAction);
	void UnRegisteHotPatcherAction(const FString& Category, const FString& ActionName);
	void RegisteHotPatcherMod(const FHotPatcherModDesc& ModDesc);
	void UnRegisteHotPatcherMod(const FHotPatcherModDesc& ModDesc);
	// ...
};

The Mod needs to call registration upon plugin startup:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
#define CREATE_ACTION_WIDGET_LAMBDA(WIDGET_CLASS,MODENAME) \  
    [](TSharedPtr<FHotPatcherModContextBase> InContext)->TSharedRef<SHotPatcherWidgetInterface>{\  
       return SNew(WIDGET_CLASS,InContext).Visibility_Lambda([=]()->EVisibility{\  
          return InContext->GetModeName().IsEqual(MODENAME) ? EVisibility::Visible : EVisibility::Collapsed;\  
    });}
FHotPatcherModDesc FGameFeaturePackerEditorModule::GetModDesc() const  
{  
    FHotPatcherModDesc TmpModDesc;  
    TmpModDesc.ModName = MOD_NAME;  
    TmpModDesc.CurrentVersion = MOD_VERSION;  
    TmpModDesc.bIsBuiltInMod = IS_INTERNAL_MODE;  
    TmpModDesc.MinHotPatcherVersion = 80.0f;  
    TmpModDesc.Description = TEXT("Plugin/GameFeature Packager");  
    TmpModDesc.URL = TEXT("https://imzlp.com/posts/17658/");  
    TmpModDesc.UpdateURL = TEXT("https://github.com/hxhb/HotPatcher/Mods/GameFeaturePacker");  
    TArray<FHotPatcherActionDesc> ActionDescs;  
    TmpModDesc.ModActions.Emplace(  
       TEXT("Patcher"),MOD_NAME,TEXT("ByGameFeature"), TEXT("Create an Game Feature Package."),  
       CREATE_ACTION_WIDGET_LAMBDA(SGameFeaturePackageWidget,TEXT("ByGameFeature")),0  
       );  
    return TmpModDesc;  
}

By passing this information, Mod registration and the ability for the core to dynamically receive it are achieved.

Through this implementation mechanism, it is achieved that simply placing the Mod’s plugin into the project allows it to be recognized by the core, and Mods can then be selected for configuration.

Flow Extension

In the preceding Core Refactoring sub-section, I introduced the need for the core to split execution phases and to have a unified Context, which is crucial for flow extension.

Delegates

Once we have split the execution phases, we can add flow control points before and after each phase. The conventional approach is to add Delegate proxies to notify which phase has been reached.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
DECLARE_MULTICAST_DELEGATE_TwoParams(FNotificationEvent, FText, const FString&)  
DECLARE_MULTICAST_DELEGATE_OneParam(FHotPatcherPatcherEvent,FHotPatcherContextBase*)  
  
class HOTPATCHERCORE_API FHotPatcherDelegates  
{  
public:  
    /** Return a single FGameDelegates object */  
    static FHotPatcherDelegates& Get();  
    static void OnExecDelegate(EPatcherCustomFlowType FlowType,FHotPatcherContextBase* Context);  
    // for patcher  
    DEFINE_GAME_DELEGATE_TYPED(OnPatcherInited,FHotPatcherPatcherEvent);  
    DEFINE_GAME_DELEGATE_TYPED(OnPatcherShutdown,FHotPatcherPatcherEvent);  
    DEFINE_GAME_DELEGATE_TYPED(OnPatcherContextInited,FHotPatcherPatcherEvent);  
    DEFINE_GAME_DELEGATE_TYPED(OnPatcherBaseVerImported,FHotPatcherPatcherEvent);  
    DEFINE_GAME_DELEGATE_TYPED(OnPatcherCurrentVerAnalysised,FHotPatcherPatcherEvent);  
    DEFINE_GAME_DELEGATE_TYPED(OnPatcherVerDiffFinished,FHotPatcherPatcherEvent);  
    DEFINE_GAME_DELEGATE_TYPED(OnPatcherPostMakeChunks,FHotPatcherPatcherEvent);  
    DEFINE_GAME_DELEGATE_TYPED(OnPatcherPreCook,FHotPatcherPatcherEvent);  
    DEFINE_GAME_DELEGATE_TYPED(OnPatcherPostCook,FHotPatcherPatcherEvent);  
    DEFINE_GAME_DELEGATE_TYPED(OnPatcherPakGenerated,FHotPatcherPatcherEvent);  
    DEFINE_GAME_DELEGATE_TYPED(OnPatcherReleaseGenerated,FHotPatcherPatcherEvent);  
    DEFINE_GAME_DELEGATE_TYPED(OnPatcherFinished,FHotPatcherPatcherEvent);  
};

By listening to this global delegate, one can monitor which stage of execution has been reached and receive the context from the parameters for necessary processing.

In fact, a large number of processes within the engine are also built on Delegates, such as FGameDelegates, FCoreDelegates, etc. They are similar approaches, triggered at specific times during engine execution to perform necessary actions.

UClass

Typically, global delegates are always called during execution, and callbacks are received as long as there is a binding. This is not logic that can be dynamically controlled for hot-swapping, so it is generally only used for common logic, such as monitoring when an entire task has completed to perform subsequent processing.

So, how can dynamic and pluggable configuration be achieved?

This can be achieved through UClass. A base class can be defined for the callback function prototypes of each stage, and each Mod can inherit from this base class to override virtual functions:

Then, this Class can be specified in the configuration, and an instance of it can be constructed at runtime to execute our overridden logic.
For example, in HotPatcher, a Mod that supports creating binary patches:

And a Mod for customizing the resource analysis process (HotChunker integrated into the hot-update flow):

Furthermore, by utilizing the PropertyCustomization mechanism (see article Property Panel Customization in Unreal Engine), overridden parameters can be added to each specified Class, allowing for more flexible control over behavior:

And property controls can be automatically created based on the parameter type, with strings stored at the bottom layer:

This way, which extension capabilities to enable can be determined based on the configuration file.

Extension Case Study

In addition to what was introduced earlier, in the hot-update process, we also added a check process for hot-update assets based on ResScanner. During each hot-update, the specifications of all participating assets are checked to prevent problematic resources from being introduced into the live environment.

In HotPatcher, this can be achieved by specifying ResScanner‘s adapter:

The implementation logic is that after the hot-update patch is created, all assets within the patch are retrieved, and then all rules are checked:

And the results will be output to the directory of the current patch.

Based on this extension pattern, various plugins can be combined very conveniently to achieve a 1+1>2 effect, and without writing additional control flows, everything can be realized within the same execution process.

Logic Replacement

In addition to the flow extension mentioned in the previous sub-section, there is also a need to replace certain built-in logic.
For example, choosing a binary patch algorithm in HotPatcher, modifying the default diff analysis process, etc., all aim to replace the default flow with a new one.

ModularFeature

Long ago, I wrote an article about integrating a new compression algorithm into UE: ModularFeature: Integrating ZSTD Compression Algorithm for UE4.

It utilized the ModularFeature mechanism in the engine, which allows providing a base interface class, implementing it separately, and then registering it with the engine.

When the corresponding capability is needed, the relevant ModularFeature instance can be obtained from the engine to execute the logic.

For example, the base MF interface provided by HotPatcher for creating binary patches needs to inherit from IModularFeature:

1
2
3
4
5
6
7
struct IBinariesDiffPatchFeature: public IModularFeature  
{  
    virtual ~IBinariesDiffPatchFeature(){};  
    virtual bool CreateDiff(const TArray<uint8>& NewData, const TArray<uint8>& OldData, TArray<uint8>& OutPatch) = 0;  
    virtual bool PatchDiff(const TArray<uint8>& OldData, const TArray<uint8>& PatchData, TArray<uint8>& OutNewData) = 0;  
    virtual FString GetFeatureName()const = 0;  
};

Then, an HDiffPatch algorithm was extended in the Mod:

1
2
3
4
5
6
7
8
9
10
11
12
class FHDiffPatchModule : public IBinariesDiffPatchFeature,public IModuleInterface
{
public:
	
	/** IModuleInterface implementation */
	virtual void StartupModule() override;
	virtual void ShutdownModule() override;
public:
	virtual bool CreateDiff(const TArray<uint8>& NewData, const TArray<uint8>& OldData, TArray<uint8>& OutPatch) override;
	virtual bool PatchDiff(const TArray<uint8>& OldData, const TArray<uint8>& PatchData, TArray<uint8>& OutNewData) override;
	virtual FString GetFeatureName()const { return TEXT("HDIFFPATCH"); }
};

It needs to be registered with the engine when the UE Module starts:

1
2
3
4
5
6
7
8
9
void FHDiffPatchModule::StartupModule()
{
	IModularFeatures::Get().RegisterModularFeature(BINARIES_DIFF_PATCH_FEATURE_NAME,this);
}

void FHDiffPatchModule::ShutdownModule()
{
	IModularFeatures::Get().UnregisterModularFeature(BINARIES_DIFF_PATCH_FEATURE_NAME,this);
}

When running, to access ModularFeature, all registered Features can be obtained from the engine:

1
TArray<IBinariesDiffPatchFeature*> ModularFeatures = IModularFeatures::Get().GetModularFeatureImplementations<IBinariesDiffPatchFeature>(BINARIES_DIFF_PATCH_FEATURE_NAME);

Then, this array can be iterated through, and the desired Feature can be found using GetFeatureName.

This way, any algorithm can be extended independently, decoupled from the core plugin.

It is more suitable for specifying general mechanisms that are independent of business logic, such as the engine’s support for new compression algorithms, which is also implemented through ModularFeature.

UClass

Besides ModularFeature, the flow extension sub-section already mentioned that UClass can be used for extension. In fact, flow replacement is similar; it also requires first abstracting an independent interface class, then inheriting and overriding it in the Mod.

Taking HotPatcher‘s diff process as an example, I created an abstract interface class:

1
2
3
4
5
6
7
8
UCLASS(Abstract)  
class HOTPATCHERRUNTIME_API UPatcherCustomDiffGenerator : public UPatcherCustomOperatorBase  
{  
    GENERATED_BODY()  
public:  
    // generate patch  
    virtual bool DiffVersionByContext(FHotPatcherContextBase* Context){ return false; }  
};

Then, based on the default analysis process, I wrote a Default class:

1
2
3
4
5
6
7
UCLASS()  
class HOTPATCHERCORE_API UDefaultPatchDiffGenerator:public UPatcherCustomDiffGenerator  
{  
    GENERATED_BODY()  
public:  
    bool DiffVersionByContext(FHotPatcherContextBase* Context) override;  
};

And made it specifiable in the configuration:

1
2
UPROPERTY(EditAnywhere)  
TSubclassOf<UPatcherCustomDiffGenerator> DiffGenerator;

Accessing the specified Class,

1
2
3
4
5
6
// 获取是否指定有效的UClass，否则使用默认的
TSubclassOf<UPatcherCustomDiffGenerator> CustomDiffGeneratorClass = Context.GetSettingObject()->GetDiffOptions().DiffGenerator;  
if(!IsValid(CustomDiffGeneratorClass))  
{  
    CustomDiffGeneratorClass = UDefaultPatchDiffGenerator::StaticClass();  
}

After getting the Class, create an instance, override instance parameters, and call the predefined interface:

1
2
3
4
5
6
7
UPatcherCustomDiffGenerator* CustomDiffGenerator = Cast<UPatcherCustomDiffGenerator>(NewObject<UObject>(Context.GetProxy(),CustomDiffGeneratorClass.Get()));  
UFlibReflectionHelper::OverrideArgs(CustomDiffGenerator,Context.GetSettingObject()->GetDiffOptions().Args);  
if(IsValid(CustomDiffGenerator))  
{  
    CustomDiffGenerator->DiffVersionByContext(&Context);
    // ...
}

This way, replaceable logic is implemented within the flow.

To modify the logic, one only needs to select the corresponding UClass in the configuration:

Module Management

Based on the introductions in the preceding sub-sections, we can now achieve relatively rich extensions for the core plugin. Thus, how to conveniently manage Mods also needs to be considered.

Currently, I manage them based on git submodule (see Mods), which is quite convenient:

  1. Each submodule is an independent git repository, allowing for independent maintenance and extension.
  2. Separate permission management: Since each repository is independent, access permissions for each Mod can be precisely controlled.
  3. The plugin core can record the git hash of each Mod, which can be used to specify the default submodule version, facilitating iteration.

For content related to git submodule, you can refer to an article I wrote previously: Git Quick Start Guide.

Conclusion

This article introduced some of my experiences and ideas in modular plugin development during the process of developing HotPatcher, aiming to prevent all functionalities from piling up in a single plugin and to achieve flexible extensibility.
It allows for relatively convenient feature extension, combination of functionalities from different plugins, and modular management and iteration methods. By decoupling implementations as much as possible, it can serve as an implementation reference for building a Mod extension system on top of UE’s plugin system.

After long-term development and expansion, HotPatcher‘s functionalities are no longer limited to resource packaging and hot-updates. Instead, it encompasses a complete resource management solution including resource sub-packaging, hot-updates, package size optimization, resource auditing, and automated resource processing.

The article is finished. If you have any questions, please comment and communicate.

Scan the QR code on WeChat and follow me.

Title:UE Plugin and Tools Development: Extensibility Support
Author:LIPENGZHA
Publish Date:2025/07/12 09:54
Word Count:11k Words
Link:https://en.imzlp.com/posts/27510/
License: CC BY-NC-SA 4.0
Reprinting of the full article is prohibited.
Your donation will encourage me to keep creating!