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",
4 Likes
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 Likes
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.

2 Likes