Creating Plugin with Optional Dependencies

Initial Question:
Is there a method to produce a plugin which compiles correctly in an empty project but can also contain additional logic which is compiled and activated when built in a project with another plugin enabled?

Use Case:
My plugin should have behaviour that only applies if it’s being used in a project built for the SteamVR plugin, and have different behaviour that applies if it’s being used in a project built for the “Oculus VR” plugin. My plugin’s C++ code must be able to call functions that are declared/defined in the SteamVR/Oculus VR plugins.

A few ideas:
Plugin Descriptor File - I’m aware that you can flag an entire plugin as having a required dependency on another plugin, but what we’re looking for is more an ability to flag a specific module inside that plugin as depending on another plugin, and if that dependency isn’t found, skip that module.
Precompile Defines - This is likely a required part of the solution to enable some plugin-specific code to become inactive when its dependency isn’t found. Not sure where to start with manipulating these though.
Reflection - Should work for this type of thing but not sure of the intricacies with Unreal’s build process. Also a bummer due to the lack of compile-time safety and potential performance hit(?).

Let me know if you’ve run into this problem before and how you went about solving it.


We have an open feature request for being able to check whether plugins are enabled from .build.cs files. It’s a little tricky though; we don’t want to allow you to modify build settings in response to it, because that would break the installed engine build and plugin marketplace, where everything is already precompiled. So it would probably have to be a separate module that’s conditionally enabled and dynamically loaded at runtime via settings in the plugin file.

Just wanted to second this request. I just finished writing a plugin (B) that I’d like to make one of my other plugins (A) use if it is present. Unfortunately I haven’t been able to find a way to get it to work.

I was hoping that if I included both plugins in the project I could use an #ifdef to conditionally compile the dependent code in the first plugin (A) based on a PublicDefinition in the other plugin (B), but it doesn’t seem to be possible for whatever reason (I’m guessing because they are different modules). I even tried setting the LoadingPhase for plugin (B) to PreDefault to make sure it is loaded first but no dice.

I can definitely see how this would be next to impossible for engine plugins since they are compiled separately and not recompiled when compiling the project, but it seems like it would be fairly straight-forward for project plugins.

I think for now I will just add a line to the README for plugin (A) to tell the user to add the PublicDefinition manually to plugin (A)'s Build.cs, but that is obviously less than ideal.

I would be pretty happy just to be able to do this with project plugins, but it would really be ideal if it was somehow possible for engine plugins as well.

By the way…this is trivial to do in Unity. Obviously it’s totally different worlds since there is no such thing as an engine plugin in Unity and everything in a project is one big compilation unit, but it’s a shame that Unity can do something that Unreal can’t ;p

Hi [USER=“1345”]Ben Marsh[/USER], thanks for the info, it helped me along significantly.

I was able to explore this route but did get some mixed signals so I wanted to check in:

The plugin we want optional module activation with (OculusVR) can’t be declared in the “Plugins” field since we don’t want it forced on. This leads to warnings on compile/packaging:

Triggering this warning is definitely sub-optimal for our users but doesn’t seem to actually indicate any underlying problems as I’m able to call LoadModule at runtime as needed and have the additional functionality kick in from there.

So my question is: will there be/have there been any changes to the system to better handle this scenario or at least some confirmation that the current approach will continue to be supported? Can work with the current situation (especially with a way to remove/suppress the warning) but would like an understanding of where it’s headed.


So this still seems to be an issue? There’s the “Optional” field for plugin dependencies, but that seems to be ignored for the purposes of the warning?

For a concrete example, we have a plugin with optional features which use the editor’s Python scripting plugin. This is all editor-only and completely optional, but obviously that warning gets spat out regardless.

I have the exact same use case as OP where I have 2 different projects for SteamVR and Oculus, then I have preprocessor guards in C++ to enable the plugin-specific code only when that plugin is enabled.

I haven’t found a good way to conditionally pass those pre-processor defines though.