VSCode support in UE 5.2 questions❔

Hi,

I wonder if there is someone who is at least partially responsible for managing VSCode support in UE5. Every few months, I am trying VSCode as an alternative to VS, since it’s much less bloated and and has much better UX than the prehistoric designed VS. And while VSCode support is slowly improving, it’s still not usable straight out of the box. I have quite a few questions:

By default, out of the box, the VSCode generated project looks like this:
.vscode-workspace:

{
	"folders": [
		{
			"name": "PointCloudTest",
			"path": "."
		},
		{
			"name": "UE5",
			"path": "C:\\Program Files\\Epic Games\\UE_5.2"
		}
	],
	"settings": {
		"typescript.tsc.autoDetect": "off"
	},
	"extensions": {
		"recommendations": [
			"ms-vscode.cpptools",
			"ms-dotnettools.csharp"
		]
	}
}

image

1. What is the .ignore file for?


In the root of the project, it creates .ignore file. I searched a lot, and it doesn’t appear that he generic .ignore file is recognized by either VSCode, Intellisense or any known version control system. It seems to correctly attempt to ignore the folders that the VSCode workspace should not see, but none of the tools in the toolchain seem to be able to recognize and use the file.

2. Why does the workspace include whole UE5 install folder path, not just engine path?
When I compare typical VS project with VSCode project, it appears that VS .sln only includes the Engine folder, while VSCode includes one folder above, making the workspace unnecessarily messy. The screenshot below showcases analogous folders between VS solution and VSCode workspace. You can see that VSCode workspace is just much more bloated:

3. Why doesn’t the generated VSCode workspace exclude the non-source code folders?
If I global search for example for “GLTF” in VS with out of the box configuration, I get 4474 results and all fo them are source code related:
image
If I do the same in VSCode with out of the box search, I get over 11k results, because in default generated VSCode configuration, the workspace is configured to search binary folders, intermediate folders and codegen folders, so it will find tons of bloat in .rsp files and such:

I am not sure if that’s what .ignore file was supposed to do, but it’s certainly not working in any VSCode version released in this decade.

4. Why does the generated VSCode project default to externalTerminal?
By default, when UE generates VSCode project, the launch tasks in .vscode/launch.json look something like this:

{
		"name": "Launch PointCloudTestEditor (Development)",
		"request": "launch",
		"program": "C:\\Program Files\\Epic Games\\UE_5.2\\Engine\\Binaries\\Win64\\UnrealEditor.exe",
		"preLaunchTask": "PointCloudTestEditor Win64 Development Build",
		"args": [
			"D:\\Projects\\Temp_Games\\PointCloudTest\\PointCloudTest.uproject"
		],
		"cwd": "C:\\Program Files\\Epic Games\\UE_5.2",
		"stopAtEntry": false,
		"console": "externalTerminal",
		"type": "cppvsdbg",
		"visualizerFile": "C:\\Program Files\\Epic Games\\UE_5.2\\Engine\\Extras\\VisualStudioDebugging\\Unreal.natvis",
		"sourceFileMap": {
			"D:\\build\\++UE5\\Sync": "C:\\Program Files\\Epic Games\\UE_5.2"
		}
},

Notice the “console”: “externalTerminal” line. What this means that every single time you start a debug session or simply launch session, it will spawn a console window:


This window will be empty during the entire runtime of the editor. It only serves as bloat, as all the logging information is being outputted into VSCode’s integrated console. The window does literally nothing except adding bloat to desktop. Why doesn’t it default to “integratedTerminal” value?

5. I can fix it myself, but how do I prevent UE for wrecking all those fixes.
Ok, so we can fix all this to make VSCode user experience as smooth as VS solution.

  • Let’s start with .code-workspace file. I added the directory names to exclude and set the UE5 folder include path to one level deeper into the Engine folder:
{
	"folders": [
		{
			"name": "UE5",
			"path": "C:/Program Files/Epic Games/UE_5.2/Engine"
		},
		{
			"name": "PointCloudTest",
			"path": "."
		}
	],
	"settings": {
		"typescript.tsc.autoDetect": "off",
		"files.exclude": {
			"Binaries/**": true,
			"Build/**": true,
			"Intermediate/**": true,
			"Saved/**": true,
			".vscode/*/*": true,
			"Content/**": true,
			"DerivedDataCache/**": true,
			"Extras/**": true,
			"Programs/**": true,
			"SourceArt/**": true,
			"Documentation/**": true
		}
	}
}

What this gives us is a very clean, VS solution like workspace view. I also removed the recommendations to again reduce unnecessary bloat. I also reordered the folders order. This is very minor but will make it easier to compare VSCode workspace to VS solution.

These changes give us experience much close to the VS Solution:

Next, we can go to tasks.json and replace all occurrences of “externalTerminal” with “integratedTerminal”. This will prevent the useless, always empty console window from popping up when launching debug:

And lastly, we can nuke that .ignore file. Behold, our clean, VS solution like VSCode workspace:
image
Everything works, no Intellisense errors (at least in the scope of our game), and the search works (we are getting roughly the same amount of results):

BUT!
For the reasons I can not figure out, UE is seemingly randomly refreshing the VSCode project, even when I do not do it explicitly. This means that sooner or later, after about a day or two of work, UE will just straight up reset my VSCode project, causing:

  • The .vscode-workspace to reset to default, deleting all the folder and file exclusion, reordering the Folders.
  • Changing the path from UE install folder/Engine back to UE install folder.
  • Resetting integratedTerminal in tasks.json back to externalTerminal.
  • Re-adding the deleted .ignore file.

I have no clue how to stop UE destroying the fixes.

So I guess my questions in general are:

  • Why isn’t the VSCode UX out of the box closer to VS solution one, when the changes necessary are relatively small?
  • What is the .ignore file for? Is it really useful for something, or is it legacy oversight?
  • If I fix all the stuff myself, how can I ensure UE won’t reset the changes periodically?

Thanks in advance.

4 Likes

It’s been almost half a year since I created this thread. Is there actually even anyone responsible for the VSCode integration at Epic? I mean someone must have written that code, but it seems that the invidual(s) take no responsibility over their work. 5.3 has released in the meanwhile and all the issues are still there.

2 Likes

Any news on this anyone. This is still messed up as of May 2025 (on Unreal 5.2).

Well no one is specifically working on that most likely, i never saw epic recommendation about VScode nor any release notes from VScode mentioning unreal engine.

I recommend going for Rider or Visual Studio 2022 (even if microsoft is very late at fixing major bug about unreal engine that we saw from 17.9 and had to wait like half a year for 17.10 to arrived).

Rider has a dedicated team making unreal engine to work and Microsoft a very small team i guess for Visual Studio 2022.

It’s been a long while again, since anyone chimed in on this thread. I too, have made my periodic rounds of probing VSCode support, so happened across this thread…

I see A LOT of people repeatedly trying to press their personal preferences for tooling and environments. Stop that. It’s not adding actual paths forward other than jumping off the path altogether, and people probably don’t care about your opinionated non-solutions. If all you have to offer is commentary akin to “give up your tools, don’t push for improvement, use what works”, well… that’s a character thing, not a solution. Some of us want to work in mature and widely utilized tools and environments and see broken things fixed, not be met with this odd resistance fueled by external preferences.

Should we tell someone not to use Blender, because Maya doesn’t have X or Y issue? Photoshop instead of Krita because it does X or Y faster? I’m sure it happens, but we don’t see it as often as we do with programming toolsets. At any rate I’m not targeting anyone in this topic, just putting optics on something that I often see, and think we should see less of in the community.

Apart from the actual VSCode support implementation itself, the documentation could use some love as well:

VSCode is widely used and even Epic started to get support for it firmly integrated. Probably the only reason it hasn’t had wider adoption at this point, is because the maintainers of the VSCode stuff have let it collect dust for some unknown reason(s). Many of the fixes @Rawalanche pointed out still apply (at least in spirit), but the issue of UE obliterating our manual adjustments still exists, which in the development world is gross and this, at the least, should be fixed/revised.

There are other issues with the VSCode environment, such as references to incorrect paths (e.g., trying to launch a Development build, looks for “UnrealEngine.exe” instead of the project related compiled executable like it should).

It would be great if someone could get Epic eyes on this, and we could at least get some hope that updates and improvements for VSCode support are coming. Then we’d know if we needed to jump off the path and not time with the occasional revisit to our little VSCode friend.