To keep it simple, we have two types of builds we create for our Android platform (differentiated mainly by levels, some compile-time differences, etc). One of them requires and uses the Niagara plugin, and the other one doesn’t need or use Niagara at all. Currently the Niagara plugin is Enabled in our .uproject file. We are trying to find some additional memory savings and I noticed that there is some savings that can be had if I disable the Niagara plugin on the build where we don’t need or use Niagara (About 7-10mb)
I first thought maybe we can dynamically modify the .uproject file during our build scripts (like finding Niagara plugin and setting “Enabled” to true/false, etc), however while this probably works, this seems kind of hacky, and I wanted to see if there is any other suggestion for doing this that could maybe use the config files, etc. Or are there are CVARs that would be helpful to modify in order to minimize memory usage on the build that doesn’t need Niagara?
I saw some forum posts about changing LoadingPhase for the plugin to “None” and then manually loading the plugin in code. Is that possible, and is there an example of that somewhere?
if you have created different targets for both Android builds then you can disable specific plugins from your TargetName.Target.cs file.
Here’s an example from the LyraGame.Target.cs:
// We don't use the path tracer at runtime, only for beauty shots, and this DLL is quite large Target.DisablePlugins.Add("OpenImageDenoise");There is also a corresponding EnablePlugins option that you can use to enable plugins that would be disabled by default.
Thank you for the reply. So we actually use the same target for both of the android builds unfortunately. The same project/code is shared amongst the two builds (except a few compile-time differences). We could add code in our build scripts to dynamically modify this Target.cs file, which may be easier than .uproject, but still feels a bit hacky.
Would I be able to just copy-paste a differently-named Target file (that has the additional disable plugins line above) and specify which one to use dynamically in our build scripts?
Like in our “RunUAT BuildCookRun” command, we specify “-target=<target_name>”. Can I just then change that target name accordingly to the newly-created one?
Otherwise, if there is a way to do it when the game loads, that could work as well. As in if it was unloaded by default, and we load it dynamically in some part of the game code (that is differentiated by the two different build types)
> Would I be able to just copy-paste a differently-named Target file (that has the additional disable plugins line above) and specify which one to use dynamically in our build scripts?
Like in our “RunUAT BuildCookRun” command, we specify “-target=<target_name>”. Can I just then change that target name accordingly to the newly-created one?
Yes, it’s totally possible to have multiple Target.cs files for your game next to each other and set which to use through the parameters of your BuildCookRun call.
> Otherwise, if there is a way to do it when the game loads, that could work as well.
There are a few options here, but I don’t think they are necessarily cleaner than the target approach.
There are command line options for explicitly enabling/disabling plugins: -EnablePlugins=A,B,C and -DisablePlugins=A,B,C
These are probably easy to use and could be an alternative to changing the build configuration, but it will still include all the plugin code and files in your builds even if disabled at startup with those options.
Instead of the plugin names it’s also possible to specify a text file with a list of plugins for these options.
Another approach would be markind the plugin as ExplicitlyLoaded and calling MountExplicitlyLoadedPlugin, but this would require you to edit the Niagara plugin file and is a very uncommon approach, so there’s a chance it won’t work with Engine plugins (it’s mostly designed for loading downloaded GameFeaturePlugins at runtime in Fortnite).
Thanks Sebastian! I created two child target.cs files that inherit from the main one and specified the DisablePlugin line for one of them and that seems to work. It does seem to have to recompile a lot of the same code files between the two different build configurations (as if they need their own intermediate files), but if that is the price to pay, it may be worth it to save that extra runtime memory. And our build machines have a lot of cores so hopefully it won’t be a lot of extra build time.
Yes, this is unfortunately a consequence of using the DisabledPlugins/EnablePlugins options.
They require a unique build environment, which means both targets will have separate build artifacts and compiled/intermediate data will not be shared between them anymore.
