Native classes command returns empty and CTRL+Click does not work

Vacui commented 4 months ago

Godot version

v4.2.1.stable.official [b09f793f5]

VS Code version

1.86.2

Godot Tools VS Code extension version

1.3.1

System information

Windows 10

Issue description

I installed godot-tools a couple of weeks ago, and besides the CTRL+Click not working for native classes (aka, opening the documentation like in Godot) I had no other problems. Then I wanted to try the new features and downloaded the .vsix, and after meddling a bit with them and then reinstalling the official version, most of it stopped working. The syntax highlighting is still in effect, and the extension for the Gut unit tests that needs Godot-tools works without problems;. But unfortunately, other features like the command to list all native classes of Godot presents me an empty list, and even the "go to definition" between classes I coded does not work anymore.

I tried to delete my Data folder in VS Code (since I configured it to be portable), start in a fresh unzip of the same version or a previous one that I had stored, uninstalling and reinstalling the extension as well as all the other ones, to no avail.

Steps to reproduce

I wish I knew. I know it probably comes down to something which broke somewhere, but I hoped you could give me directions on how to more effectively troubleshooting the problem.

Thank you in advance for all the help you may provide 🙏

DaelonSuzuka commented 4 months ago

You're just unlucky. I broke those features in #594 two days ago, noticed today when trying to record a gif to show off the docs, and fixed it in #596 two hours ago, and you just happened to download it right in that window.

Can you re-download the .vsix and let me know if that fixes it for you?

Vacui commented 4 months ago

Wow, just my luck 😅 But unfortunately, no, that does not solve the issue. I downloaded the .VSIX from the link in the README, if that helps.

Something changed tho:

If I press F12 on a class, it tells me no definition found for <name of class>

If I troubleshoot the keybindings, pressing F12 prints an error that was not there yesterday, since before the revealDefinition was never called due to the condition editorHasDefinitionProvider failing (I know because I tried to remove it from the when condition):

2024-02-24 11:01:30.068 [info] [KeybindingService]: + Invoking command editor.action.revealDefinition.
2024-02-24 11:01:30.070 [error] Language client is not ready yet: Error: Language client is not ready yet
at To.sendRequest (c:\LiberKey\MyApps\VSCode\data\extensions\geequlim.godot-tools-2.0.0\out\extension.js:34:47184)
at To.get_symbol_at_position (c:\LiberKey\MyApps\VSCode\data\extensions\geequlim.godot-tools-2.0.0\out\extension.js:204:421)
at Go.provideDefinition (c:\LiberKey\MyApps\VSCode\data\extensions\geequlim.godot-tools-2.0.0\out\extension.js:62:2100)
at l.provideDefinition (c:\LiberKey\MyApps\VSCode\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:150:87621)
at c:\LiberKey\MyApps\VSCode\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:150:113985
at pe.s (c:\LiberKey\MyApps\VSCode\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:150:112365)
at pe.$provideDefinition (c:\LiberKey\MyApps\VSCode\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:150:113972)
at d.S (c:\LiberKey\MyApps\VSCode\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:147:5520)
at d.Q (c:\LiberKey\MyApps\VSCode\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:147:5286)
at d.M (c:\LiberKey\MyApps\VSCode\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:147:4338)
at d.L (c:\LiberKey\MyApps\VSCode\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:147:3455)
at g.value (c:\LiberKey\MyApps\VSCode\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:147:2242)
at r.y (c:\LiberKey\MyApps\VSCode\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:80:1902)
at r.fire (c:\LiberKey\MyApps\VSCode\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:80:2119)
at n.fire (c:\LiberKey\MyApps\VSCode\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:105:14073)
at g.value (c:\LiberKey\MyApps\VSCode\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:173:8051)
at r.y (c:\LiberKey\MyApps\VSCode\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:80:1902)
at r.fire (c:\LiberKey\MyApps\VSCode\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:80:2119)
at n.fire (c:\LiberKey\MyApps\VSCode\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:105:14073)
at MessagePortMain.<anonymous> (c:\LiberKey\MyApps\VSCode\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:173:6331)
at MessagePortMain.emit (node:events:514:28)
at Object.emit (node:electron/js2c/utility_init:2:2285)

I hope this new info can help

What bothers me is that even by going back to the v1.3.1 the problem is not solved 🤔

DaelonSuzuka commented 4 months ago

Dumb question, but is the extension connected to the Godot Editor when you're trying this?

edit: I just now updated to the development version linked in the README, on my laptop. When I installed it and reloaded the window, definitions were still broken. When I closed VSCode completely and reopened it, they were working again.

Vacui commented 4 months ago

Fixed! It was not the Godot executable, but the lsp.serverPort 😅. When upgrading to the latest version through the .vsix, the old setting godot_tools.gdscript_lsp_server_port was deprecated in favour of the new godotTools.lsp.serverPort, which however was populated with the default value of 6006, when I instead had configured it before with 6005. While experimenting I kept the new value assuming it was correct (since for the path to the editor it was instead correctly copied as previously configured in the old config), and that, combined with the bug you told was present at the time, broke everything. Once that was solved, I still had the issue with the ports in Godot and VS Code being different, but no error was telling me that, and so I searched anywhere else for a cause. Even using a clear installation of VS Code presented the problem because Godot was still configured with 6005 (which is the default for Godot4 I think?).

Now that I spotted the problem, I tried with both the store and master version, and they both work perfectly (nice job on the updates btw 👍). It remains only to avoid losing this configuration when the upgrade takes place, and for that let me know if you need me to test it 😁

Thank you very much for your invaluable help 🤗

DaelonSuzuka commented 4 months ago

Two comments on that: One, there already is a mechanism that's supposed to convert the old settings to the new ones. There should have been a notification about it in the bottom right corner. Two, the new version already just works correctly with the default settings if you also leave the Godot Editor on the default settings. The new extensions version automatically tries to connect to both the Godot 3 and Godot 4 LSP ports, so if you do nothing it's supposed to Just Work.

Vacui commented 4 months ago

I am sure that is the case, no doubt you have covered the basics 😅

But just a couple of things I have noticed during my experiments, and feel free to prove me wrong:

With the following value in the VS Code settings.json:
```
"godot_tools.gdscript_lsp_server_port": 6005,
"godot_tools.editor_path": "c:\\LiberKey\\MyApps\\Godot4 WIN\\v4.2.1\\Godot4_win64.exe",
```
When I manually installed the .vsix, the plugin defaulted to these: server port: 6008 editor path Godot 4: godot It indeed presented an error that the path was wrong, but no mention of the port (maybe because it can not tell wrong from right in that case without the executable?).
If I go to my remote port settings in Godot, the value 6005 is presented without a reverse icon next to it, which I believe it means it is the default
You are right, I tested leaving everything to their defaults, and indeed VSCode with the correct path to the editor is able to connect to Godot at 127.0.0.1:6008, it just confuses me how 6008 works with 6005, and why exposing these settings if they are irrelevant 😐 But I don't know enough about the argument to form an opinion

In the end it works, somehow, and outside the features being broken for a short period, the fault was mainly mine for messing up the configuration 🤷‍♂️ Feel free to close this bug if you think there is nothing else to cover, or let me know how can I help if it is necessary.

Thank you very much for your patience and hard work 👍

DaelonSuzuka commented 4 months ago

feel free to prove me wrong:

Oh I wasn't arguing, I was just describing what was supposed to happen. I think that the settings updater feature didn't trigger for you, but I'm not sure why (or how to prove it).

it just confuses me how 6008 works with 6005, and why exposing these settings if they are irrelevant 😐

It's not irrelevant, if you want to set your LSP port to 6969 on both sides you absolutely can, but the default LSP port is 6005 for one Godot version and 6008 for the other, so if your extension setting is the default value it will just attempt both because it doesn't know what Godot version you're using.

The goal was to make it work out of the box for the most number of people, in the most number of configurations. You're absolutely correct that it's a little bit non-obvious, but it was supposed to work without you ever knowing it was happening.

Regardless, I'm glad it's working for you now.

godotengine / godot-vscode-plugin