Unreal 4.15 FMod and Shipping build

So I can’t build a shipping version of the fmodstudiooculous plugin. I’m compiling with 4.15 under Visual studio and
I get: >D:\Projects\VRProjects\Engine\Plugins\FMODStudio\Source\FMODStudioOculus\Classes/FMODOculusBlueprintStatics.h(10): error C2504: ‘UBlueprintFunctionLibrary’: base class undefined

Development Editor works fine, but not Shipping. I assume this is do to the changes they did to include files in 4.15, but I haven’t figured out the magic needed to work around this. Have and of you made it work ? Attempting to reference Kismet in the dependency list results in errors about not including editor files in shipping builds.

Thanks, Rick

Hi Rick, I see you managed to solve this on Unreal Answers. Just wanting to check if this was caused by the FMOD Plugin or something else?

The FMod plugin doesn’t compile for shipping unless you add additional headers at the top. These are apparently included in editor builds by other stuff, but not in shipping builds. Try building a C++ project including your plugins for shipping, and the blueprint libraries won’t compile. I had to add:

#include “Kismet/BlueprintFunctionLibrary.h”

At the top of FModBlueprintStatics.h
And FModOculusBlueprintStatics.h

(I had to add this include to our plugin with a blueprint library as well).
And I had to add:

#include “GameFramework/Actor.h”

At the top of FModAmbientSound.h

And in FMOdStudioOculus.Build.CS I had to move Slate and SlateCore to PublicDependencyModuleNames.AddRange() with Core and CoreObject instead of where it was in the editor section under

if (UEBuildConfiguration.bBuildEditor == true)

All of this is because of the changes Unreal did to not have monolithic header includes but to make all the c++ files need to include the headers they use.

We’re good to go for the moment, but your code will need to be updated to be 4.15 shipping build compatible at some point.


Oh, missed one. Also need:

#include “Components/SceneComponent.h”
#include “Audio.h”

in FModAudioComponent.h

Thanks Rick, at the moment it works fine when the plugin is in the Project directory but we will endeavor to have this solved for the next release.

So our issues are because we’ve got it in the Engine directory?

As far as I’m aware, the only time the monolithic header change has effected our plugin is when it is in the Engine/Plugins directory.