In case someone still has a problem: For me in the latest 4.20 code (after 4.20.3) it still was a problem. But when I added the following line to my myGame.Target.cs and myGameEditor.Target.cs it solved the problem (I am not using the python script): BuildEnvironment = TargetBuildEnvironment.Shared;
(I also have “bUseSharedPCHs = true;” in my myGameEditor.Target.cs)
It needs to be added under the ‘public myGameTarget’ line. Maybe it helps you.
yeah, still using my script^^ But It got better 
That’s strange. I created a new project/class in .3 and was not able to reproduce the issue.
I also recovered an old project from VC and regenerated VS files without needing to use the script as I usually do. so I can say with certainty that it works for me. Maybe because my Unreal dir has no spaces. ie. C:\UE_4.20\
I’m still getting the same generated.h errors even after updating 4.20.3, cleaning my project and deleting my intermediates/saved folders, and adding the edits that you mentioned 
Anybody have any other ideas? It takes over four hours for me to rebuild my project and recompile all the shaders, so having to repeatedly do this every time a “fix” is issued is pretty frustrating. I’ve just given up on intellisense at this point.
Edit:
I’ve tried running the python script on Python 3.7 but I’m getting this error:
…line 62, in
_solution_file = glob("*.sln)[0]
indexError: list index out of range
Maybe I’m not running the python script correctly. I saved the python file to my project directory, and used the windows 10 command prompt to call the file with the python executable.
First of all you do not need to rebuild everything, and you should never press rebuild for your Project, since if you use UE from source, it will rebuild the engine. Second, you need to regenerate your Project files, so rightclick your *.uproject and press smth like Generate Visual Studio project files, which will call the BuildTool to create all Files you need. The Python script needs to be in the same folder, your Projects *.sln is, otherwise glob can’t find it.
HI Frigerius, thanks for the reply. I do use UE from source, and I usually try to avoid rebuilding for that very purpose. Unfortunately, sometimes it will not build correctly (or blueprints will be out of sync) without first cleaning the project and deleting intermediate files. Epic recommends trying this whenever issues happen (especially when updating the engine). I have already regenerated my project files and have placed the script in the same folder as the project solution file. I’ve also made sure to rename my directories to avoid using spaces. I’m still not sure what the issue is. Is there a way to do this without using the python script? Thanks!
Hm if Blueprints don’t work, I just close my engine and build, so the old tmp dlls get deleted an everything gets a fresh build, I never needed to rebuild for that. If there would be an easier solution for fixing this, I wouldn’t use my script^^ But the script shouldn’t crash, since IndexError, as you know, means, that the array/list is empty, which would mean there is no solution file, but I can just guess, since I don’t know your setup^^
Yeah, I think I’m just running the python script incorrectly from the command prompt, and it’s not reading the correct directory (or maybe there’s something weird with my directory names). I’ll look into it some more.
Do you run the CMD inside your folder amd call the script by full path, or did you to a cd in CMD to change your command execution environment to your project?
You’re welcome^^
Yeah, I’m an idiot. I didn’t change my working directory in the command prompt to my project folder before calling the python executable. I assumed that python would use the script’s directory as the working directory (since I used the absolute paths to both the executable and the script file), but that’s not the case.
So here are the steps for command line and python noobies like me:
Thanks for the help Frigerius, and the awesome script. It works great!
As a side tip. if you Shift + Right-click an empty space in your project dir, you’ll get an option to open a Command/Powershell window (pre-set with that working dir)
Or even better: if you associate py files with Python and [set correctly in your windows PATH][2], you can just double-click the script without ever needing to type anything, as then Python is executed from the working dir the script resides in.
PS. I notice both of you are running from source. so maybe the fix in .3 only applies to launcher builds.
This is a bug from the source build. If you use launcher build(from unrealengine.com), this bug will be gone.
The 4.20.3 version: UBT → UEBuildTarget.cs (line: 454)
// Set the default value for whether to use the shared build environment
if(RulesObject.BuildEnvironment == TargetBuildEnvironment.Default)
{
if(RulesObject.Type != TargetType.Program && (***UnrealBuildTool.IsEngineInstalled()*** || RulesObject.LinkType != TargetLinkType.Monolithic))
{
RulesObject.BuildEnvironment = TargetBuildEnvironment.Shared;
}
else
{
RulesObject.BuildEnvironment = TargetBuildEnvironment.Unique;
}
}
And line 1054:
// Set the build environment
bUseSharedBuildEnvironment = (Rules.BuildEnvironment == TargetBuildEnvironment.Shared);
if (bUseSharedBuildEnvironment)
{
AppName = GetAppNameForTargetType(Rules.Type);
}
IsEngineInstalled? That is the difference between launcher version and source code version.
that explains why my “workaround” by setting “BuildEnvironment = TargetBuildEnvironment.Shared;” worked for me (see above somewhere).
Thanks for finding this out. Did you report it?
Should we just force RulesObject.BuildEnvironment = TargetBuildEnvironment.Shared? Or is there a better way to get the conditional to work with source builds? Thanks.
I’ve been having this problem in 4.20.3 after we upgraded from 4.19. But no one else on the team seems to be getting it.
I found that in AddModuleToCompileEnvironment (in UEBuildModuleCPP.cs) the GeneratedCodeDirectory for my project was something like
Intermediate\Build\Win64\MyProjectEditor\Inc\MyProject
But looking in my Intermediate folder I found that my generated code is in
Intermediate\Build\Win64\UE4Editor\Inc\MyProject
I tried doing a string replace on the GeneratedCodeDirectory path to look in UE4Editor instead of MyProjectEditor before adding it to the IncludePaths. After regenerating project files my Intellisense seems to be finding my generated headers properly. I’m no longer seeing errors all over the place.
// This directory may not exist for this module (or ever exist, if it doesn't contain any generated headers), but we want the project files
// to search it so we can pick up generated code definitions after UHT is run for the first time.
if(AutoGenerateCppInfo != null || (ProjectFileGenerator.bGenerateProjectFiles && GeneratedCodeDirectory != null))
{
String s = GeneratedCodeDirectory.FullName;
s = s.Replace("\\Build\\Win64\\MyProjectEditor\\Inc\\", "\\Build\\Win64\\UE4Editor\\Inc\\");
DirectoryReference dr = new DirectoryReference(s);
IncludePaths.Add(dr);
}
Thanks for your script. Good work !
4.21.1 not fixed
It’s terrible, every time you update, add paths to manual, and most of the errors are still not corrected.
OMG THANK YOU!
I’m also running the engine built from source and I’m on 4.21.2, which by all accounts should be free of this infamous 4.20 bug. I could not figure out why I was still getting intellisense errors on my includes for “generated.h” files as well as certain Unreal Macros and Super calls on Pawn classes. I had tried EVERYTHING.
Setting BuildEnvironment = TargetBuildEnvironment.Shared in the MyGame*.Target.cs files SOLVED IT!!!
As pointed out by FeiSuZZ further down this page, it’s a bug with the “source version”. By now the code in UEBuildTarget.cs that determines the default BuildEnvironment (e.g. what will be set if you DON’T make the above fix) has actually been moved to RulesAssembly.cs. But as it is the result is the 4.20 include/generation bug persists even in 4.21.x.
This bug is still around as of 4.21.2 but for the record the first snippet of code above (what was line 454 of UEBuildTarget.cs when you added your answer in October) has now been moved to RulesAssembly.cs. I’m pointing this out for the sake of anybody else in my situation who comes along to read this.
Either IsEngineInstalled() is a bad/incorrect flag to use when determining if BuildEnvironment should be Shared or not (Unique) or LinkType is erroneously set to Monolithic when it shouldn’t be.