Add a plugin-specific root directory shortcut path, e.g. "pgn://"

[willnationsdev]

It would be very convenient if plugins developed for the engine could refer to a path that automatically searched relative to the plugin root directory (where the plugin.cfg file resides).

Example:

• res://
  • addons
    • <plugin_name>
      • api
        • script1.gd
        • script2.gd

Then, in code, it might be....

# script2.gd
extends "pgn://api/script1.gd"
extends "plug://api/script1.gd" # <- using NullConstant's suggested prefix (much better)

[RiverMesa]

Wouldn't a plug:// path work better, though? (it doesn't have to be 3-letters, since user:// is already a thing)
pgn sounds a bit too much like misspelled png, but that's very much a subjective thing.

(I'm for the idea itself, just for the record.)

[willnationsdev]

That works for me. In fact, that's actually more appropriate considering res:// is actually the beginning text of resource rather than it being a more jumbled abbreviation like rsrc://

[bojidar-bg]

Mentioned in #6023 (comment) as well.
Some of the replies to that comment:

@Zylann:
I kinda like the idea but the fact other addons are inaccessible might be problematic if your addon can extend/communicate another. What do you mean by "exporting them"?

@reduz:
I still think you guys are worrying too much about something that is not
really a problem. We should simply define some sort of standard naming
convention for projects and that's it

[bojidar-bg]

BTW, note that you can just use relative paths in this example:

# script2.gd
extends "script1.gd"

[willnationsdev]

Well, if I understand correctly, that Issue was more about what to actually call the "addons" directory, where to put it, if it can be optional, if plugins can be dropped directly into a location OTHER than res://, etc. This Issue therefore should be a completely new topic (which is why I put it here rather than commenting on that one).

BTW, note that you can just use relative paths in this example

Yeah, I suppose I could have mentioned that. I just gave a simple example, but my current use case is a lot more involved than that. It can get pretty irritating having to remember how many ../s I have to use just to get back up to the proper directory if I'm X levels deep in my own plugin root. Plus, then if I move something around, I have to run around and fix everything, but I don't want to start using res:// for everything in case plugin code ever does get relocated in some way.

[Zylann]

@willnationsdev you know that the task of locating assets with paths isn't just a fact about plugins, but the whole resource system in Godot? I'm not sure adding another xxx:// will solve this, especially if it's just a subset of res://, and AFAIK locating-by-path isn't going to change anytime soon. (one very good solution to make assets path-independent is to assign them GUIDs in meta files like Unity does, but as I said it won't happen in Godot without massive refactoring).
If you reference something out of res://, then it could be any path on the system, or, put into use case, a path accessible from any project. Turns out Godot has user://, which fullfills this use case (that path is also used to save editor settings).

[willnationsdev]

@Zylann it's not exactly about "solving" the problem. This issue is purely a convenience / usability enhancement. Plugins have no business needing to be aware of the full resource environment for a project (they should only care about their resources). It makes defining paths within a plugin just more of a hassle. As such, it seems silly for them to have to use a hardcoded path from res:// to get to themselves, regardless of what that path is.

[bojidar-bg]

(one very good solution to make assets path-independent is to assign them GUIDs in meta files like Unity does, but as I said it won't happen in Godot without massive refactoring).

@Zylann Funny, I remember reduz talking about this a few days ago...

@willnationsdev This solution would have to work with:

• Referring resources in scenes
• Referring resources in other resources
• Using load() to load the resource
• Even worse, using ResourceLoader.load() to load it

All of those functions would have to know which plugin/addon made the request, so they can properly resolve it.

One might work around this requirement by using something like plug_terrain://..., but then it just becomes a shortcut for res://addons/terrain/.

[willnationsdev]

Well creating a shortcut is essentially what this Issue was all about anyway. XD Although, ultimately it would be ideal if the shortcut didn't have to change based on the name of the plugin. I understand why that would be a lot simpler though. :-/

[Zylann]

@bojidar-bg yeah I know it's quite a big deal, if Reduz has a solution about this GUID stuff it would be interesting. There could be a way to have them for things assigned in editor (path resolution could look like guid://), and still have possibility to import by named path, which is typically done in scripts. Also, now resources almost all have .import files, which makes me think of meta files heheh, but maybe I'm just dreaming :p

[Calinou]

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.

The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.

If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!