Cannot open include file:

Integrating C++ Asset is often problematic and I have trouble over including header files in the SK-generated wrapper.
Here is a sample.

#pragma once

#include "Bindings/SkUEClassBinding.hpp"
#include "Public/PrefabricatorProperty.h"
class SkUEPrefabricatorProperty : public SkUEClassBindingEntity<SkUEPrefabricatorProperty, UPrefabricatorProperty>
    static SkClass * get_class();
    using tBindingEntity::register_bindings;

The problem is at the 3rd line where it has “Public/” prefix.

#include "Public/PrefabricatorProperty.h"

“Public” shouldn’t be there and it’s causing compilation errors.

Here is the plugin structure.

It might be a simple problem but I ran of things to try.
I would appreciate it if you can help figure it out.


This is a super annoying generator problem that I’ve also hit but don’t have a polished solution for yet.

Open up SkookumScript\Source\SkookumScriptGenerator\Private\SkookumScriptGenerator.cpp and around line 1793 you’ll see:

if (generated_type.m_class_scope == ClassScope_project)
        // For files in the project, we want to preserve the relative path. e.g.:
        // Public/MyActor.h
        include_file_path = relative_file_path;

This is where the generator decides whether to add the Public prefix or not. One hacky fix could be simply adding any additional class types here that you want to prevent that prefix on.


if (generated_type.m_class_scope == ClassScope_project &&
        !generated_type.m_sk_name.Contains(TEXT("Prefabricator")) &&

I think there’s a better solution out there that requires reading some Microsoft documentation on include paths.

As you can see I have lazily been using this hack myself for some time :flushed:

Hi, many thanks.
I just added your suggestion but it didn’t remove the prefix.
I guess it gets the prefix from someplace else.

I suppose it’s has something to do with the generator but I wasn’t able to debug the generator in the first place to figure it out myself.

Do you know how to debug the generator? It would help if I debug it myself. I tried to debug UnrealBuildTool but it didn’t trigger the breakpoint in the generator.

I appreciate your help.

Oh, it worked!! Awesome!
I had to recompile a couple of times to reflect the changes.
However, it was kinda tedious to add all of them.

Anyway, being able to debug the generator would be helpful for the further analysis.
Please let me know if you know how to debug the generator.
I’ll try to find better ways to handle it.


This is very common when dealing with SkookumScriptGenerator. The problem is that SkookumScriptGenerator is ran by UnrealHeaderTool (UHT), but UHT only runs when it detects changes in certain key files. So sometimes you might make modifications to something in SkookumScriptGenerator and UHT doesn’t detect the change and so you never see your changes reflected.

The key to watch for in a build is the output:
1>SkookumScript: Generating C++ script bindings for 49 engine modules and 1 project module(s)

Your number of engine modules might vary, but the key takeaway is that when UHT runs SkookumScriptGenerator, this is the message that is generated.

If for whatever reason you just can’t get UHT to run, you can always clean the UnrealHeaderTool project and build again. This incurs a bit more build time than the next method.

If you want to debug the script generation and manually invoke/force UHT to run, here’s how you do it.

  1. Build the project normally and look for the output that indicates that UHT ran, you need to get an execution line to do this, so if needed, just clean UHT once as I’ve described above. Just before the “Generating C++ script bindings” log, you will see output that looks like this.
1>  Running UnrealHeaderTool "C:\Perforce\MyProject\MyProject.uproject" "C:\Perforce\MyProject\Intermediate\Build\Win64\MyProjectEditor\Development\MyProjectEditor.uhtmanifest" -LogCmds="loginit warning, logexit warning, logdatabase error" -Unattended -WarningsAsErrors -abslog="C:\Perforce\UnrealEngine\Engine\Programs\UnrealBuildTool\Log_UHT.txt"
  1. Copy everything after Running UnrealHeaderTool, the entire rest of the line, double quotes and all

  2. Right-click edit the properties of the UnrealHeaderTool program

  3. Paste the text that you copied into the Command Arguments field and hit ok

  4. Right-click on UnrealHeaderTool and set it as Startup Project

  5. Hit Play, you can now hit breakpoints in SkookumScriptGenerator :partying_face:

Just don’t forget to set your game as the startup project when you’re done. Once you have this setup, you can quickly switch the startup project to UHT anytime you want to force the generator to run or if you need to debug some of that code.

Ah…, it’s HeaderTool instead of BuildTool. I was barking at the wrong tree. ^^
I’ll give it a try.
If I come up with a better method, for example, to skip the prefix for the entire module, I’ll let you know.

1 Like

FYI, there is ModuleInfo and I thought I could use this but to my surprise, the reference to ModuleInfo is null. It gets the reference from m_targets[0].m_script_supported_modules but my module is NOT visible there.
Sure, I added the module in SkookumScript.ini and I see every other module I have listed but not the one in question.
I think the culprit is that the module is not visible and therefore it treats the module differently from others. Hmm…

is this a custom module or one that you have made? Is there something unique in its .uplugin file that makes it not visible?

Yeah, I’m trying to compare side-by-side with other plugins and it doesn’t seem obvious.
It’s this free asset I’m using and if you can spare your time, you can try it.

Is there any chance you could share with me a bare bones C++ project that has this included in the plugins where I can quickly reproduce your issue?

Hi, thanks for the offer.
I got it working and I’ll probably not bother this time.
I’ll let you know if I run into another problem.

Happy Skookum!