Code in Plugins
When generating project files for Visual Studio or Xcode, any Plugins that have
Source folders (containing
.Build.cs files) will be added to your project files to make it easier to navigate to their source code. These Plugins will automatically be compiled by UBT when compiling your game project.
Plugins are allowed to have any number of Module source directories. Most Plugins will only have one Module, but it is possible to create multiple, for example, if a Plugin contains some Editor-only functionality, and other code that is intended to run during the game.
For the most part, Plugin source file layout is the same as any other C++ Module in the Engine.
Plugins are able to declare new
UObject types (
USTRUCT, etc.) in header files within a
Classes subdirectory in their Module code folders. The Engine's build system will detect these files and generate code as needed to support the new
UObject types. You will need to follow the normal rules for using
UObjects within C++ modules, such as including the generated header file and the Module's
generated.inl file in one of your Module's source files.
Most Plugin Modules will not export public APIs in header files via the
Public source folder, because Plugin Modules cannot be direct dependencies (or statically linked) by the Engine or by game code. However, there are a few exceptions to this rule:
- If your Plugin contains multiple C++ Modules, code in a Public folder can be shared between Modules within your Plugin.
- If you are creating a game Plugin (not an Engine Plugin), and you want the game to statically link against one of your Plugin Modules. This is an unusual practice, but can be often useful for Plugins that want to declare new
UObject types that game classes can inherit or use directly. The Engine itself will never have direct dependencies on a Plugin, but the game project code and content may.
- If you want to distribute public interface headers with your Plugin in order to enable game code or other Plugins to access types implemented in that Plugin's Modules. This is very uncommon and generally discouraged, as we do not currently intend to support Plugins that are directly dependent on other Plugins.