Using engine plugins - add to .uproject file or not?

Hi there,

I have a minimal project with two modules - the default game project module and a sibling module, called “Terrain”, which depends on the engine’s ProceduralMeshComponent module (located in a plugin of the same name at Engine\Plugins\Runtime\ProceduralMeshComponent).

I can compile and run just fine with the Terrain module listing ProceduralMeshComponent module as a dependency:

PublicDependencyModuleNames.AddRange(new[] {
			"Core", "CoreUObject", "Engine", "InputCore", "SlateCore", "Slate", "ProceduralMeshComponent"
		});
PrivateDependencyModuleNames.AddRange(new string[] {});

But the IDE (Rider) warns that “ProceduralMeshComponent is missing in the project file”.

I can make the warning go away by adding the ProceduralMeshComponent plugin (not module) to the plugins list in my .uproject file:

  "Plugins": [
    {
      "Name": "ProceduralMeshComponent",
      "Enabled": true
    }
  ]

But I’m told in the UnrealSlackers discord server that ProceduralMeshComponent should actually be added to the additionalDependencies list of my Terrain module’s entry in the modules list of the .uproject file:

"Modules": [
    ...,
    {
      "Name": "Terrain",
      "Type": "Runtime",
      "LoadingPhase": "Default",
      "AdditionalDependencies": [
        "ProceduralMeshComponent"
      ]
    }
  ]

This also runs fine, but does not get rid of the IDE warning described above.

Could someone shed some light on what the difference is between all of these approaches?

  1. Only declare a dependency on the engine module in my module’s .build.cs file
  2. Do #1, then also declare a dependency on the engine module’s plugin in the .uproject file’s plugins list
  3. Do #1, then also declare a dependency on the engine module in the additionalDependencies list for my module’s entry in the modules list in the .uproject file (or is this a plugin dependency? ProceduralMeshComponent's plugin and module have the same name, so unclear which one is being depended upon here)
  4. Do #1, #2, and #3 (???)

There seem to be multiple ways to declare dependencies - it would be excellent to understand the purpose of each way, as well as how they differ from each other.

Thanks!!

Well, #1 is required because it tells the UnrealBuildTool what modules and their scope(i.e. public/declarations vs private/definitions) to use when compiling your code and linking the objects.

#2 tells the editor that the specified plugin needs to be enabled(i.e. make its modules accessible). It’s worth mentioning that a plugin can have multiple modules. So enabling a plugin will allow you to use all of its modules. The ProceduralMeshComponent plugin for example has two modules: ProceduralMeshComponent and ProceduralMeshComponentEditor. The ProceduralMeshComponentEditor probably has slightly different functionality, but is meant to only be used with the editor not on a dev or ship build. Hopefully someone with a better understanding of engine modules can chime in, but the Plugins list in the uproject file may only enable the plugin when the project is opened. It probably has no effect on what modules are actually used by a project, it’s just there to turn on plugins to make their modules available. I think the nuance here is that if the plugin is already enabled then adding the plugin to the Plugins list isn’t required and you will just be bugged by your IDE if you don’t. The reason it bugs you is likely because if you were to have someone else open your project and the plugin wasn’t enabled by default or settings on their engine, they would get an error about a missing module since the uproject doesn’t specify which plugins to enable.

As for #3, I’m not sure if the AdditionalDependencies refers to plugins or modules. Taking a look at ModuleDescriptor.cs only gives List of additional dependencies for building this module. as a description for it. I would imagine that it is for modules because as I mentioned earlier plugins can have multiple modules, which in some cases can be modules with types that cannot even be used for all builds(i.e. Editor only modules). As for why it’s there, maybe for the engine to find the right modules to use when opening a project? I’m not really sure on this one.

Either way, the best practice is probably to use all three. That way anyone looking at your project, yourself included, has a clear picture of what modules are need for the project, from what plugin, and for which of your modules.

1 Like

Thanks for this!

Blockquote
#2 tells the editor that the specified plugin needs to be enabled(i.e. make its modules accessible). It’s worth mentioning that a plugin can have multiple modules. So enabling a plugin will allow you to use all of its modules. The ProceduralMeshComponent plugin for example has two modules: ProceduralMeshComponent and ProceduralMeshComponentEditor . The ProceduralMeshComponentEditor probably has slightly different functionality, but is meant to only be used with the editor not on a dev or ship build. Hopefully someone with a better understanding of engine modules can chime in, but the Plugins list in the uproject file may only enable the plugin when the project is opened. It probably has no effect on what modules are actually used by a project, it’s just there to turn on plugins to make their modules available. I think the nuance here is that if the plugin is already enabled then adding the plugin to the Plugins list isn’t required and you will just be bugged by your IDE if you don’t. The reason it bugs you is likely because if you were to have someone else open your project and the plugin wasn’t enabled by default or settings on their engine, they would get an error about a missing module since the uproject doesn’t specify which plugins to enable.

I see, so perhaps the ProceduralMeshComponent plugin is already enabled in my context via some other means, and that’s why I was able to compile and run successfully without adding it to my .uproject plugins list? I wonder if all engine plugins are enabled by default or something?

Blockquote
Either way, the best practice is probably to use all three. That way anyone looking at your project, yourself included, has a clear picture of what modules are need for the project, from what plugin, and for which of your modules.

Ok, sounds reasonable I suppose given the lack of documentation around this. I do worry that I’ll run into problems by adding stuff to all these dependency lists without understanding them, but I’ll save that concern for if/when it becomes an actual problem.

Given how core .uproject files are to the architecture of an unreal project I’m kind of surprised there isn’t better documentation around it. The course on learn.unrealengine.com related to plugins best practices yielded a lot of great info about plugins and modules, but didn’t really touch on specifics when it comes to dependency management in .uproject files.

Thanks again for your explanation! Lots of good info here :slight_smile:

Yes, some plugins are automatically enabled based on their *.uplugin definitions. If you go to Engine/Plugins/Runtime/ProceduralMeshComponent/ProceduralMeshComponent.uplugin, you can see it has the “EnabledByDefault” field set to true.

Yeah the documentation can be lacking in places for sure. Luckily we have the full source at our disposal, so we can also find answers by doing some digging. It just depends on how much you want it and whether it’s worth it. I personally wouldn’t worry about it too much since your project is building fine.

1 Like

Blockquote
Yes, some plugins are automatically enabled based on their *.uplugin definitions. If you go to Engine/Plugins/Runtime/ProceduralMeshComponent/ProceduralMeshComponent.uplugin, you can see it has the “EnabledByDefault” field set to true.

Aha! Awesome, thanks for pointing this out.

Yes it’s very nice having the source available, coming from Unity. I’m often not quite sure how to find what I’m looking for a lot of the time, this case included, but experience will help. Thanks again!