Open lonegamedev opened 7 months ago
What's the actual problem you're having? "is not supported" could mean anything or nothing. Is there an error message, maybe?
It is marked as error, and when I hover I get:
Preload file "file://home/lgd/godot/multiplayer_playground/game_client/game/signaling/messages.gd" does not exist.gdscript(-1)
Thank you. That's very important information that you should have included in your original post.
This is a problem with the Godot Language Server not correctly detecting file changes on disk, and not related to this extension.
Try restarting your Godot Editor.
Sadly restarting doesn't fix it for me.
ERROR: Attempt to open script 'file://home/lgd/godot/multiplayer_playground/game_client/game/signaling/signaling.gd' resulted in error 'File not found'.
at: load_source_code (modules/gdscript/gdscript.cpp:1025)
Okay, that's a completely different type of error, caused by the actual game engine not finding the specified file. This is even less related to the extension than the first error.
I don't use preload() but it looks like you have a typo somewhere or you're specifying your relative path incorrectly.
Nah, the file is there. I'm observing something interesting. When I open file through Code, I get all the errors with relative path, plus additional problem I mentioned here: https://github.com/godotengine/godot-vscode-plugin/issues/650
However - if I enable Text Editor / External
and open the file through Godot, it magically works.
Now if I open it from Code, it is broken again (it is treated as two seperate files).
/mnt/workbench/godot/multiplayer_playground/game_client/game/signaling/signaling.gd
/home/lgd/godot/multiplayer_playground/game_client/game/signaling/signaling.gd
I'm using symlink in my home directory - so perhaps this is what breaks it...
I'm using symlink in my home directory - so perhaps this is what breaks it...
So you already know that you've done something wierd but you didn't investigate that first AND you didn't include that information in your initial report? That's a very interesting debugging strategy.
This is the first time I experienced that some LSP has problem with a symlink.
Anyway thanks for your help. Could be better if symlinks were properly resolved, but at least I can open file via Godot.
Could be better if symlinks were properly resolved
I've had problems with symlinks in VSCode in the past. Seems to be a VSCode problem.
I guess it depends on how you use them. I simply create a symlink to the whole project directory under home. This way I can have common location for mounting drives, but also convenience of organizing stuff in my home dir. Never had a single problem with this approach.
From what I see Godot is adamant on using abs paths. When I open a project launcher it shows paths via home.
Then, after I open a project, and Show in File Manager
on any file it opens parent dir via abs path.
I don't know how this should be fixed, but my initial idea would be to resolve all paths to abs, before sending to LSP, since this is what Godot expects.
For example Node can do it via realpathSync
.
Godot version
v4.2.1.stable.arch_linux
VS Code version
1.88
Godot Tools VS Code extension version
2.0.0
System information
ArchLinux
Issue description
Relative preload path is not supported. It is recognized properly inside Godot editor.
Steps to reproduce