Classic blunders when using Godot 4.2 (GDScript) with VSCode

Help
1

This is not a question, this is meant to help others if they Google the problem.

=========================

I absolutely hate Godot, and I hate GDScript even more. Everything about both of them. That’s right, deal with it. But I’m stuck with it. So the least I can do is trying to help others. <3 <3

Here is a list of classic blunders (and how to fix them) when you try to make Godot and VSCode work together.

All the tips below are for Windows.

1) Pre-requisite : Every time I say “godot-tools settings” I mean this : In VSCode, go to the “Extensions” panel, locate the “godot-tools” extension, click the little cogwheel, “extension settings”.
Then the 3 settings you’ll use the most are :

  • Editor_path
  • Gdscript_lsp_server_host
  • Gdscript_lsp_server_port

Please note : those settings exist under both “user” and “workspace” (tabs at the top of the settings panel). I seem to remember that “user” supercedes “workspace”, but just keep in mind that you don’t need to populate the value in both. Pick one and stick to it.

2) Check that you have the correct version of Godot running
If you’ve migrated to, let’s say, Godot 4.2, maybe you were running Godot 4.1 at the time you ran VSCode. Now VSCode tries to connect to a different instance or something. Check the path to Godot in the godot-tools settings. Close Godot and re-open the right one.

3) Check that you don’t have old godot settings stored in your project folder

  • Go to your Godot project folder
  • Delete hidden folder .godot
  • Close Godot and re-open your project

4) Wrong port
Godot chaged from 6008 to 6005 at some point.
In Godot : Editor Settings → Network → Language server → Remote port → 6005
In VSCode : godot-tools settings → Gdscript_lsp_server_port → 6005

5) Triple check that VSCode is properly configured in Godot
In Godot : Editor Settings → Text Editor → External
Exec Path :

  • Replace backslashes with forward slashes (because why not)
  • DO NOT surround with double quotes, even if your path contains white spaces
  • It must be the full path the the .exe file (included)
    Exec flags : Make sure it’s verbatim what you’ve been told
    {project} --goto {file}:{line}:{col}

6) Only one instance of VSCode open!
I had the following symptoms : In Godot, I double-click a GDScript file. It opens VSCode (as expected) but does not open the project folder and does not open the file.
Solution : This happens if there is any other instance of VSCode already running (even if they have a different folder/project open in them).
Close every VSCode window then try again; this time your gdscript file opens properly as well as the project that contains it.
If that still doesn’t work, maybe check if you have a zombie code.exe still running (by using the Task Manager)
You might also encounter issues when VSCode was open on a different project/folder the LAST TIME it ran. Switch to your Godot project before closing VSCode and retry opening a .gd file.

7) When debugging: Missing “http” in the url in launch.json
In VSCode, you need to create a launch.json file when you try to run your project in Debug mode drectly from VSCode (look for tutorials on how to do that).

  • Open the launch.json file
  • “address”: replace “127.0.0.1” with “http://127.0.0.1”.
    Oh and while you’re at it check that the port has the correct value.
    You will find the correct value in Godot → Editor settings → Network → debug → Remote port. It’s most likely 6007

8) Check the DEBUG ports
In Godot : Editor Settings → network–> Debug Adapter
Remote port : 6008
Sync breakpoints : TICKED
In VSCode : Open launch.json as explained before and add “debugServer” entry

    "port": 6007,
    "debugServer": 6008,
     "address": "http://127.0.0.1",
2

I have some additional points to add here if you want to use your favourite code editor instead of learning the built in one that is only good for one thing and requires a full editor version bump for bugfixes.
All of these applies to 4.0, 4.1 & 4.2

NOTE: I’m on macOS so these might not apply to other platforms

1) Godot reverts your changes, part 1
If you update your code and hit play in Godot (also applies when running using launch.json) and then notice that your fix didn’t work, Godot might have reverted your file. Switching to your code editor and hitting ctrl/cmd + z to undo the revert and save again will usually fix it.

2) Godot reverts you changes, part 2
If you add an @export value and switch to Godot to assign it, make sure the exported field stays there when you save the scene, because Godot might decide to revert it. The code is still there, Godot just decides to remove it in the editor. The only fix I know for this is to restart Godot

3) Shaders will never respect your external editor settings
Trying to opening a .gdshader file from the editor will always open in the “Shader Editor” which is completely separate from the built in Script editor for some reason. You will have to open shader files manually in VSCode

4) The Godot LSP won’t always help you
If you want to use a function on an object and you type, for example, “my_object.set” and expect to traverse the list of available functions you will often get a very long list of “available” functions that are very much NOT available for that object. But you won’t know until you write it, save it, switch to Godot and try to play it. No fix for this one, you just have to get used to not trusting auto complete.

5) Changing function parameters/names
Another thing I encounter quite often when I add, remove or change type of a function parameter, I will keep getting an error that the parameter count is wrong and it expects something else even though everything is properly changed. Only fix I know is to restart Godot

6) When using GDScript in a team, you NEED to comment your code and set up strict rules
Not sure if the built in editor handles this better, but because GDScript does not (yet) support private/protected members, you have NO WAY of letting the code speak for itself. For example, I have a variable called “_next_unique_id” and a function that increments and returns it that is the only way the variable should be used, but the Godot LSP will just serve it up like any other public member, so if a team member doesn’t know that they are not allowed to use it you will quickly run into a lot of problems. So be prepared to write a lot of comments and hope that you team members always reads up on a function/variable before using it. Private/protected is supposed to come at some point in the future but until then, the only fix is to make sure everyone knows that even if they can use a function, they are not allowed to because it starts with an underscore.

7) Don’t use alt/opt+arrow keys to move lines of code up or down
Because GDScript doesn’t use proper encapsulation if you move a line or a bunch of lines of code up or down, you will almost always break the encapsulation and your entire project. So get used to not do that or make sure you memorise how the encapsulation looked before you started moving something. Some editors might handle this better, but VSCode does not

8) “Quick” Godot (re)start
Since you will probably have to restart Godot a LOT here’s a little trick for VS Code users:

  • Close Godot (unless it closes itself, which it tends to do quite a lot) and switch to VS Code
  • Down in the lower right it will say “Disconnected”, followed by “Connecting” and a number that slowly ticks up.
    When the number reaches 12 it will give you a notification saying “Couldn’t connect to the GDScript language server… Is the Godot editor running?” and give you a button that will open the Godot editor with the correct project (skip the project picker window)
  • You can click the “Connecting” field and it will tick up once per click so what I do is just hammer that button until it gives me the notification and then click “Open Godot Editor”
3

You should not put http:// in address anymore, the vscode godot extension has been updated a lot since Jan 13.

4

I should say that my hatred of Godot and GDScript has decreased tremendously ever since I’m using the most recent versions of both Godot and the Godot Tools extension for VSCode. Fantastic job by whoever made it and/or maintains it!
Especially, the extension’s great understanding of the code base + auto-completion + native functions’ manual integrated on hover.

5

I have been messing with my connection between Godot and VS Code for a couple days now. I have to say, one of the biggest blunders I made was installing both standard and mono. They share too many settings for them to be useful on the same machine. Best to pick one or the other. I focused on the standard copy, but there is still residual.

I am using a VS Code Profile for Godot and this works ok, but raises a whole other learning curve, and it took some time to get that working well. The trick was to use the Workspace Folder settings (pointed to a higher folder in my working area) and to not use the settings.json. I also added ‘–profile’ to my Godot Editor Exec Flags, and it seems to keep things straight. (The latter is when I split off trying to set up mono. I could not use a different VS Code Profile with each since the external editor settings are shared.) The advantage of the Profile is all my VS Code settings and extensions are contained (hopefully!)

I am glad to say I have most issues solved except one. The std output disappears into oblivion when I use VS Code for a debug run. For some reason there is a disconnect between VS Code and the Godot debugger.

I know many of my issues may stem from the fact that I was confusing the Debug Remote Port with the Debug Adapter Remote Port. (Glad the devs made those so similar~not!) I have probably corrupted my Mac, also, having had both standard and mono versions of Godot has introduce so many little issues. I am really tempted to do a full reinstall of MacOS. I made the mistake of not using Time Machine on my laptop. (Fool that I am!) I have also discovered some of the scripts I wrote (in a coding fugue before trying to make any of this work) have some odd behaviors under the debug. Some weird reaction to really large integers.

So, in my project under .vscode, I got down to the following for launch.json:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Godot: Full Debug (Godot Editor Open)",
            "type": "godot",
            "request": "launch",
            "project": "${workspaceFolder}",
            "port": 6006,
            "address": "127.0.0.1"
        }
    ]
}

And the following for tasks.json:

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "Godot: Fast Launch (Godot Editor Closed)",
            "type": "shell",
            "command": "/Applications/Godot.app/Contents/MacOS/Godot",
            "args": [
                "--path",
                "${workspaceFolder}"
            ],
            "problemMatcher": [],
            "group": {
                "kind": "test",
                "isDefault": true
            },
            "presentation": {
                "echo": true,
                "reveal": "always",
                "focus": true,
                "panel": "shared",
                "showReuseMessage": false,
                "clear": true
            }
        }
    ]
}

The latter has been a real boon, as my prints show up in the terminal window, as it runs in the CLI, but it is no good for step debugging, especially since it ignores all breakpoints. The task does run without having Godot opened first, and the language server still runs fine.

I tried adding the debugServer setting in my launch.json, but it is both not clear which port it expects and it actually blocks the Godot Debug Window from opening, regardless of which port I use.

So…

I made a Godot project from scratch, copied my handy task over, and used the default launch.json that follows:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "GDScript: Launch Project",
            "type": "godot",
            "request": "launch",
            "project": "",
            "debug_collisions": false,
            "debug_paths": false,
            "debug_navigation": false,
            "additional_options": ""
        }
    ]
}

As you can see, most of the settings default to empty. Oddly, with a single node project, after adding a single print under _ready(), everything works as it should! at.tools will still not debug or print through VS Code, but the tools, like the export button, work fine in the Godot editor.

What it all comes down to is that everything is a compromise and it sucks! But then… you already knew this.

6

I’ve been using IDE’s for the better part of 20 years, starting with early versions of Eclipse and Netbeans, past Intellij Idea to vscode.

Worked a lot with vim and atom too.

I programmed in 7 languages professionally and another 5 odd just for hobby. From Java to lisp, from Haskell to typescript, from python to gdscript. All have their merits. Gdscript packs a lot of very powerful stuff imho.

Here’s my takeaway:

As long as you’re using strict typing, the in-engine editor does a fine job all on it’s lonesome. Try navigating the in-engine docs; fast and impressively complete. (You should try and keep up to date. Some of your annoyances may simply have been fixed by now)

Setting up vscode is just overhead to me.

I like the vscode plugin a lot, though. This is hard stuff to get right and to keep up to date with the insane pace of development of the Godot engine.

So personally I’d encourage a bit of appreciation towards the authors of all of these, because chances are, many of them are not getting paid.

Then again, I’m quite sure they don’t mind much their work being hated by the odd person out. I wouldn’t.

My advice is to you: you get more joy in life if you cultivate the gratefulness for the good and simply accept the things that you have to deal with in order to enjoy the good bits.

Just my 2 cents.

All the best to you.

7

Oh sorry! I’m talking to old posts again! Ha ha.

8

My post was new :upside_down_face: , but I am getting to the same end.

I have everything working as expected between Godot and VS Code—I found my big bug—but I just wasted most of today trying to get the Debug Console in VS Code to not display the debug output in an unchanging light gray font. It’s almost unreadable using any light theme, and none of the VS Code setting overrides appear to fix it. I am not a fan of dark themes, so I am left squinting at any debug output if I run a debug through VS Code.

No worries, though. I have decided to mainly use VS Code as a smart editor and do all my debugging natively in Godot. I am using VS Code as my editor simply because I have better AI assistance there. It really helps with the repetitive work. I do not usually rely on AI for anything important, although I do get some nice suggestions occasionally, but even with the helpful repetitive fills, I have to keep a close eye on what it gives me–the source of my big bug was from some AI assistance. I will probably end up doing a lot of work natively in Godot, anyway. Its disparate interface helps reminds me I am working with GDScript and not Python. I have considered diving into the C# possibilities but that is for another (distant) day.