Download

Has anyone ever got VSCode working with UE4? (including intellisense)

Hi,

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 where I am at currently:


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 :frowning:

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.

It does compile just fine, but they do show, which makes me nervous :slight_smile:

Now I am even more confused. Intellisense in VS 2017 doesn’t throw any errors but won’t find GEngine for example:


While VSCode throws some include errors, but at the same time finds GEngine just fine:
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 :expressionless:

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.

Thank you very much for the explanation!

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.

Works great, here, just a completely fresh install of UE4.22, followed immediately by VS2019 Community.

VSCode and VS Community are two different pieces of software though :slight_smile:

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”
}

Hey y’all, if you’d like to use VSCode you need to:

https://scontent-lht6-1.xx.fbcdn.net/v/t1.15752-9/78622636_1738387106292649_8327278658741862400_n.png?_nc_cat=104

https://scontent-lht6-1.xx.fbcdn.net/v/t1.15752-9/79316549_1001633920195102_2948016305879384064_n.png?_nc_cat=106

You’ll then have a VSCode workspace you can open that will contain the engine + your project.
You can also use the VSCode debugger without a problem!

1 Like

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.

Currently my json looks like this - { "configurations": [ { "name": "UnrealEngine", "includePa - Pastebin.com .

I think this thread might help: Intellisense not working UE4.25 - C++ Gameplay Programming - Unreal Engine Forums
The problem for me was that the defines in the c_cpp_properties.json needed to be populated. Someone in that thread posted this link: ue422-defines.txt - Google Drive which includes the required entries.

Following this video got intellisense working for me, engine 4.25.4 and vs code 1.50.1 -

Worked for me as well. Thanks for that!

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:
vscode.jpg
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

Both Epic Games and Microsoft seem to claim that errors are on the other side: see issue for news IntelliSense is unresponsive with Unreal Engine 4 · Issue #5849 · microsoft/vscode-cpptools · GitHub - some guy has posted on how to fix some of the errors

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.

VSCode always shows whole call stack, though.

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:

b5abbf2e-4534-482f-84e9-2389687fb0ea.png
For you it may be different:


mklink /J "D:\Build\++UE4\Sync\Source" "C:\Program Files\Epic Games\UE_4.25\Engine\Source"

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.