I’m trying to add some custom source code to an engine plugin (MassAI), but I get the “cannot open source file xxx.generated.h” error.
After some search it seems to me that rebuilding the solution will not automatically rebuild the engine plugin, so the “xxx.generated.h” was never generated.
I’m wondering what would be the best way to do this. Rebuild the engine? I don’t know if it will lead to any undesirable side effects, or if it’s really worth it since I’m only making some small changes. Is it possible to rebuild this engine plugin only?
Any suggestion is appreciated!
I have never tried to duplicate an engine plugin myself, but making you own you create a c++ project. Inside of it you add a “Plugin” folder and inside of that you create a folder for with your plugin name.
Copy all of the source files of the plugin into that folder and try recompiling your project.
In theory it should work unless unreal has a problem with duplicate plugin names.
You are supposed to be able to copy engine plugins to your project, make changes and maintain that copy of the plugin until you don’t need it. I’ve never done it myself, but I seen it discussed enough that I’ll repeat it here.
However, the danger is that if you do that you (from what I understand) also have to do the same thing for any engine plugins that depend on the plugin that you’re modifying. Even if you don’t plan on modifying them. The reason for this is that the Engine can’t allow for two plugins (yours and the Engine’s) to coexist in a way that your modules use yours and the Engine modules use the original. Depending on the plugin you’re moving it could be more or less painful.
The alternative is to switch over to a source build of the Engine. Grab everything and compile the entire Engine yourself. This can take a while up front (and when new versions release) but you can change/fix anything in the whole codebase without having to make duplicates. You can even fix things that aren’t in plugins!
You can absolutely just copy an engine plugin into your C++ project’s Plugins folder, and simply delete that plugin from the engine plugins folder. Everything will work as expected, no need to move / modify other plugins. I usually zip up the original plugin so that I can basically reset it at any time.
I’m not sure what you’re experience is with it, but that fundamentally shouldn’t work. Plenty of other people run into problems like this one by doing what you’re suggesting.
Once you have a copy of the plugin in your project, it becomes a project plugin. And Engine plugins can’t depend on project plugins. (and you should start getting build errors like those in the linked post).
Maybe you’ve only modified plugins that don’t have Engine dependencies. There are plenty of those.
Hmm interesting, I did do this with the Steam Online Subsystem for example which does have dependencies but I had no issues modifying its source code. At the end of the day it is just a plugin, moved one level higher (engine level → project level).
Perhaps the issue only happens when a plugin that depends on this plugin gets loaded earlier?
It’s unlikely that the SteamOnlineSubsystem is depended on directly by other plugins in the Engine or the Engine itself. Because of how the online subsystems need to be swappable, the Engine tends to interact with them indirectly, through an interface, getting whatever the current one is Steam, Mac, EGS, etc. The interface breaks the compile time dependence that is the issue.
Runtime dependencies, like the Engine being “dependent” on the game because it has to instance a game specific class for the GameInstance, aren’t a problem.
Thank you so much for your reply. I did try making a copy of the plugin inside the project plugin folder but doing that alone led to dependency errors that I didn’t look further into. Maybe it was the case that I needed to make copies for those depending on the plugin I was moving as well.
However, what confuses me is that even if I did make copies of those plugins depending on the one I was to modify - without deleting the original engine plugins - wouldn’t there still be two sets of coexisting plugins? I’m not sure why that would fix the dependency issues with the original engine plugins.
Because the project plugin takes precedence over the engine plugin of the same name. So as long as both copies are in the project, your okay because project plugins can depend on project plugins. Where you run into problems is when the non-duplicated plugins in the engine think they have a dependency on the project, but that’s not allowed. The dependency there can only go project → engine.