Resources linked with "uid://" scheme does not correctly link to the correct files.

[anthonyme00]

Godot version

v4.4.1.stable.official [49a5bc7b6]

VS Code version

1.98.2

Godot Tools VS Code extension version

2.5.1

System information

Windows 11

Issue description

Currently, Godot's LSP does not return the correct file path for uid:// resource scheme when the textDocument/documentLink command is called.

This results in the following error when trying to follow a reference to a uid:// resource.

This also means that the hover preview does not work for uid:// preloads.

Working

Not Working

To fix this, i have created a fork with a proof of concept fix. This currently only works for GDScripts resource type since they have an easily distinguishable accompanying *.uid file, linked below:

https://github.com/godotengine/godot-vscode-plugin/compare/master...anthonyme00:godot-vscode-plugin:uid_script_shortcut?expand=1

With the changes on this fork, hovers over uid:// strings on supported files works as expected (only for GDScript resources). ctrl+clicking uid:// strings also now works as expected.

This fix works by overriding the return from textDocument/documentLink calls and stripping target links that starts with uid://, and instead relying on the internal DocumentLinkProvider implementation instead.

Steps to reproduce

1. Open any project that contains uid:// resource references
2. Hover or attempt ctrl+click on those resources
3. Be greeted with the following error message:
   

[DaelonSuzuka]

I hate uids so much. Absolutely amateur solution to a problem that no adult actually had.

The full fix for this in the extension is that I need to build a whole-project indexer and a proper language server that actually works. I've been putting it off because it sounds very annoying. Unfortunately this is the like the third problem where the right answer is building an indexer, so I guess it's time to do it.

Thanks for the proof of concept, if you open a PR with your branch I'd be happy to clean it up and use it as a temp fix until I get the stupid indexer built.

[Calinou]

This sounds like a LSP issue that should be fixed on the Godot editor side.

[DaelonSuzuka]

It's both, the LSP is probably wrong but I also have a custom DocumentLinkProvider implementation that doesn't support uid:// links yet.

[anthonyme00]

#841

here it is

I hate uids so much. Absolutely amateur solution to a problem that no adult actually had.

The full fix for this in the extension is that I need to build a whole-project indexer and a proper language server that actually works. I've been putting it off because it sounds very annoying. Unfortunately this is the like the third problem where the right answer is building an indexer, so I guess it's time to do it.

Thanks for the proof of concept, if you open a PR with your branch I'd be happy to clean it up and use it as a temp fix until I get the stupid indexer built.

[DaelonSuzuka]

Plus now that he's made me think about it there's like 5 other special extension features that support res:// resource paths that ALL need to be updated to support uid:// links

[anthonyme00]

This sounds like a LSP issue that should be fixed on the Godot editor side.

haha yeah, sadly i'm nowhere near confident enough to touch the Godot source code. At the very least this fork should help until someone is able to fix it on Godot's side.

[anthonyme00]

i've dabbled a bit with godot's code, and apparently this should is pretty simple to fix from there, i've got a local build running that returns the correct paths for uid://s, i'll open up an issue there as well.

however this only works for .gd files. whilst the DocumentLinkProvider implementation also works for scenes, resources and such.

Edit:
here's the issue on godot's main repo
godotengine/godot#105000

[HolonProduction]

So if I read this correctly, the language server does not properly resolve custom uri schemes to file uri's in results? Could we just convert every result to file uri's, or would that break some aspect of this extension? We already do it for res so doing it for uri shouldn't cause problems. See godotengine/godot#104401