I am wondering if anyone ever was able to get VSCode with intellisense working with UE4. I’ve wasted several days of attempting to make it here and there, but always gave up eventually. My latest attempt is also not going anywhere. I also saw various YouTube tutorials about setting up VSCode with UE4, but they all had intellisense too. I’ve never seen anyone actually having unreal cpp files open in VSCode without intellisense throwing errors.
This is 100% stock FPS C++ template, and yet it just never ever works without errors. I’ve tried to delete folders and re-generate the project files like 10 times over, but it never helped. Neither did any other suggestions I’ve found on google
Are these errors actually stopping you from compiling? Or is it just Intellisense being dumb? The later happens often which is why Visual Assist is awesome.
I am not sure if GEngine requires some header to be included first, but in VSCode, nothing extra is included, yet it builds and the AddOnScreenDebugMessage just works… I am very confused
Intellisense is completely dumb when it comes to A.) Large code bases, and B.) Macros.
UE4 has both in spades. Unfortunately Visual Assist doesn’t appear to work with VS Code, so you’ll just have to live with the false positives (unless some patch comes out that greatly improves Intellisenses’ parsing smarts).
GEngine is in Engine/Engine.h btw, something is likely already including it in your chain.
This confuses me though. I don’t believe Engine/Engine.h is included, yet VSCode is somehow finding it while VS2017 is not. I’ve went through every header and cpp in the project, but none include it. That is consistent with how VS2017 behaves. VSCode is finding it for some reason.
Apparently when UE4 generates a VSCode project it includes tons of paths. I suppose that could be the culprit:
However now I am really not sure if having access to functions and classes of not included headers is a good thing or a bad thing. What confuses me even further, as a newbie, is that GEngine runs, and works, in both IDEs, even if the header is not included.
I just realized that, effectively, we need to generate the Visual Studio Code project files in order to get almost the important autocomplete features.
VS Code Intellisense does a pretty good job of reading through any C++ headers provided in the c_cpp_properties.json file that sits in the project .vscode directory.
My default config looks like this but I have added header dirs from Eigen, glm and occasionally even a copy of gcc’s includes. I don’t know how well or if it works with linked based libraires without headers though.
{ “name”: “Win32”, “includePath”:
“C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.13.26128/include/",
“C:/Program Files (x86)/Windows Kits/10/Include/10.0.16299.0/um”,
“C:/Program Files (x86)/Windows Kits/10/Include/10.0.16299.0/ucrt”,
“C:/Program Files (x86)/Windows Kits/10/Include/10.0.16299.0/shared”,
“C:/Program Files (x86)/Windows Kits/10/Include/10.0.16299.0/winrt”,
“${workspaceRoot}”
], “defines”:
“_DEBUG”,
“UNICODE”
], “intelliSenseMode”: “msvc-x64”, “browse”: { “path”:
"C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.13.26128/include/”,
“C:/Program Files (x86)/Windows Kits/10/Include/10.0.16299.0/um”,
“C:/Program Files (x86)/Windows Kits/10/Include/10.0.16299.0/ucrt”,
“C:/Program Files (x86)/Windows Kits/10/Include/10.0.16299.0/shared”,
“C:/Program Files (x86)/Windows Kits/10/Include/10.0.16299.0/winrt”,
“${workspaceRoot}”
], “limitSymbolsToIncludedHeaders”: true, “databaseFilename”: “”
}, “cStandard”: “c11”, “cppStandard”: “c++17”
}
That’s exactly what doesnt work Vlady Vaselinov. At least for some of us. Visual Studio Code just cannot read these entries in includePath in c_cpp_setting.json, at least thats what I assume. I followed the path shown by EsteeRixx and got to best results after moving everything to tag-parser -
. Its far from perfect but fares much better than anything I had before.
For me, VSCode still does not work with UE4 no matter how hard I try. Even if I try to get defines and include paths right, it will still fail to open the right engine file when you for example crash during debugging:
It still points to non existent absolute paths.
I really do not believe it is possible to reliably use VSCode with UE4, or that the VSCode support ever was a real, finished thing.
I work using vscode and like it. UE4 support is unfinished and intellisense is crappy (it works 20% of times), but overall it’s still thousand times better than IDEs.
You don’t have to step into as deep as ActorEditor.cpp. Usually all relevant info about the crash is in project files. Go into your function in the call stack/step over UE4 symbols and debugger works greatly
I know what causes this particular crash, and in this particular case, knowing which function in the engine source file caused the crash helped me a lot when backtracking tho the source of the crash in my code. So for me this is crucial functionality. VS2019 jumps to the correct file, so there’s no justification for VSCode not beign able to, if the IDE itself has the functionality.
I have went through all the suggestions in multiple different guides, and while I was able to fix numerous intellisense and and include errors, I just can not solve this one.
“You don’t have to step into engine code” is just too much of a limitation for me justify using VSCode, despite all its benefits.
I rechecked and seems that I lied: breaking inside internal functions works for me. I don’t remember how and when I made it work, but most possibly I just created junction links to source directories that vscode tries to look into. Like that:
I am still mainly curious why does the path remain obsolete and absolute. I’ve searched contents of the files in almost the entire project, and only places where I found these absolute paths where .cs files related to build tool and automation tool.
Cluttering my drives with random folders just for the purpose of making this works feels really dirty. So does the reliance of this on even having a D: drive, which is the case for my desktop PC but not for my laptop. And creating new partitions just because of this would be an ultimate overkill. There’s certain threshold for workarounds after which the workarounds become bigger issue than the problem they are made to solve.
