Post any questions or compile errors you figured out solutions for here!
Also any questions regarding changes between prior engine versions and 4.15 are welcome here
Skeletal Mesh
If you were using types defined in SkeletalMeshTypes.h, you may now need to include this file explicitly.
What is IWYU?
IWYU stands for “Include What You Use”, indicating that you have to manually include all headers for all engine code that you want to use rather than simply including large headers like one of my personal favorites, Engine.h, hee hee!
Here is the github commit where Epic’s Ben Marsh explains more:
**Disabling IWYU**
You can disable the new system by adding
```
bEnforceIWYU = false;
```
in your build.cs.
Why IWYU?
If you go through the work of finding and manually including all headers you need for the engine code you are using per file, then you stand the chance of seeing 20 to 50% improvement in your compile times
**GEngine? ( * Sniff * )**
Epic's Ben Marsh (who was instrumental in arrival of IWYU) explains how to get access to GEngine here:
https://forums.unrealengine.com/showthread.php?137015-4-15-C-Transition-Guide&p=673109&viewfull=1#post673109
♥
If you have a dedicated server target (MyGameServer.Target.cs), I believe the correct way to define the platforms now is to annotate the class and delete the GetSupportedPlatforms method
[SupportedPlatforms(UnrealPlatformClass.Server)]
public class MyGameServerTarget : TargetRules
{
...
}
So what happens to our game header includes now? Does MyGame still need MyGame.h as the first include in every cpp file? What do I need to include in MyGame.h?
Looks like the engine now creates a .suppressed file which will force you to include what you use instead of letting your headers make use of Core.h or Engine.h as a whole; so if you use classes from different modules you have to include those module’s headers now, simply adding Engine.h won’t work.
UUserDefinedEnums have changed; there’s no more TArray<FName> DisplayNames, it’s now a TMap<FName,FText> DisplayNamesMap.
If you do DisplayNamesMap.GenerateValueArray() you get the stored Enum names from there.
I am trying to follow the “no Engine.h” paradigm so I removed the include to Engine.h from my MyGame.h file. However now I get weird errors, the first of which is in my interface:
I had a compile error saying that UE4EditorServices couldn’t be compiled because it does not run on Win64 systems + I had no rights to run Build.bat.
Edit: Fixed by cleaning solution and rebuilding it.
To use “GEditor->” you now have to include “Editor.h” ( tested in plugin )
I also noticed this during compilation: Skipping MfMedia (requires WINVER >= 0x0601, but WINVER is 0x0601) well… it says WINVER greater or equal to 0x0601 so why skip?
I understand the logic of the use of PCH file has been completely abandoned. Is it possible to revert to the old rules for the project? I would like to use the PCH file and do not add a number of .h files in each .h file.
Substance plugin (from 4.14) has many compilation errors in 4.15 due to new rules for .h files
bEnforceIWYU = true enables warnings or errors about violations of these rules
bEnforceIWYU = false by defaults and there are no warnings or errors in our projects
UBT: Replace the GetSupportedPlatforms() callback on TargetRules with a SupportedPlatforms attribute. Since a TargetRules object can only be instantiated with an actual platform, it doesn't make sense for it to be an instance method.
Now gives “Unresolved external symbols” errors anywhere Cutscene->SequencePlayer->Play(); (or Stop, Pause, etc) was used.
So putting Sequencer into cpp still works, but playing it in any way causes the errors.
Commenting those out fixes it, but now how can we Play/Pause/Stop sequencer from within cpp?
Edit: Fixed by adding “MovieScene” to PrivateDependencyModuleNames in build.cs
Thanks @campd
A few Gameplay Abilities related things that I found:
Since this has been moved to a component, make sure to add GameplayAbilities to your plugin list in the .uproject file, otherwise you’ll get a dll error (if porting a project that was already using abilities).
Also if you are using static gameplay cue notifies, there is an issue if they have a “PlaySoundAtLocation” node in the blueprint. Something to do with how things are loaded, causes an engine level freeze.
The workaround I found here is to add