I’m reworking and examining a plugin whose development has largely ended and trying to expand its functionality.
The process is being slowed down a bit by my trying to keep the code a plugin, though.
Little tasks like adding new C++ files (can it be done through the editor?) seem to be complicated by developing a plugin versus developing a regular asset or putting source under the normal source folder.
Debugging also seems to be slightly obfuscated as well.
For the particular functionality, making an interactable water surface simulation, I don’t see an immediate improvement in the quality of the release or usability by making the water surface accessible via a plugin.
What are the advantages I might be missing?
Should I switch to development as a regular asset?
For one thing, if you want to sell your asset on the UE4 marketplace, as far as I know, this is only possible when using plugins - if you want/need to program in C++.
Another advantage of plugins, following certain standards defined by UE4 is, that they can also be depended upon by other plugins in a meaningful way (via the .Build.cs definitions).
As is stated in the official UE4, Plugins are really meant to extend UE4 functionality in a standardized way.
where are the docs on plugin dependencies?
I was refering to the documentation under
UE4 Plugin doc
There they state:
One thing with plugin modules that is a bit different, is Public source file headers. Most plugin modules have no business exporting public APIs in header files in a Public source folder, because they will never be a direct dependency (statically linked against) by engine or game code. So usually your Public source folder will be empty. 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 engine plugin), and you want to allow the game to statically link against one of your plugin modules. This breaks the concept of a plugin a little bit, but is often useful for plugins that want to declare new UObject types that game classes can inherit from or use directly. The engine itself has no dependencies on this plugin, but the game project code and content may very well have direct dependencies.
If you want to distribute public interface headers with your plugin in order to allow 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.